Yes. But have a look at ipx.cpp since not all functions are emulated.

Awsome, thanks again.

I think there's a problem with the way DosBox handles event service routines, though (or I'm missing something obvious).

Somewhere between my ESR returning to the IPX service and the IPX service returning control to my application, something is causing my app to resume a dozen or so instructions ahead of where it should be. Everything functions correctly when the ESR pointer is set to 0 (don't use ESR), and when it is set, I'm certain the ESR is being called (it correctly sets a global variable). According to the DosBox source ESR is supported, but is seems that here's a near/far call/return mixup somewhere. I've tried my best but can't find it. I've attempted putting "asm retf" and "asm ret" in my ESR, but it causes a lockup in both cases. I don't have the resources to try it on regular DOS either.

It's still possible to use IPX by polling the event control block's in-use flag and completion code variables. Perhaps those programs which don't work in DosBox use ESRs, and those that do work don't? Or, again, maybe I'm missing something obvious.

The following are the relevent portion of my app; it's 16bit, real mode source compiled using Borland C++ 3.1 (DOS).

uint8 far esrcalled=0;
void far esr(void){
esrcalled=1;
}
.
.
struct ecb{
uint32 link;
uint32 esrptr;
.
.
}myecb;
.
.
myecb.esrptr = (uint32)&esr;
uint16 ecbptr = (uint16)&myecb;
asm{
mov bx, 0x0003 /* Transmit Packet */
mov ax, ds
mov es, ax
mov si, [ecbptr] /* ES:SI = -> ecb */
int 0x7A /* NetWare */
}
// while((!esrcalled)&&(!kbhit()){}
while(1){} // <- should resume here (ESR is called during the loop)
. // <- skipped instructions
. // <- actually resumes here

Are you using 0.63? If so I suggest you use CVS, it has some fixes especially concerning the ESR routine. I also have a patch where I try to make as many games work wit IPX as possible.
Native IPX support

Yeah, I'm using the 0.63 Windows binary. Forgive my ignorance, as I've never been involved in an open source project; by CVS, do you mean compiled from the source found here? I doubt I could compile that; the most recent Windows compiler I have is Borland C++ 4.5, and it likes to complain about missing components like its assembler. I am however using the source distribution to trace the problem.

Attached is the full listing of the above source, albeit slightly modified, and the resulting executables. Where it was previously skipping instructions, it now randomly does anything from working properly to crashing DosBox. The most minor of changes in the source (like adding a NOP) causes it to behave in a completely new way. IPXBAD is the version with ESR's, IPXOK without.

Here is an explanation of CVS and also links to compiled binaries.
DOSBox SVN Builds

Your ipxbad worked for me without crashing in CVS. (esrcalled:2)
In 0.63 you need to save some CPU registers in your ESR routine (tose that are not already saved). But that might not be the only problem.

The CVS works for me too. Only now the modem's broke. :)

I was fiddling around with the Hayes control codes and noticed that the modem wasn't responding, so I reinstalled 0.63 in a seperate directory and tried using it - and it worked. So apparently the modem isn't working in CVS. Both versions have an identical dosbox.conf, with ipx disabled and modem=true on port 2.

well you need a new dosbox.conf
modem control in the configuration file is different (and disabled if you use an 0.63 dosbox.conf)

Alright, my dosbox.conf is now:

[serial]
serial1=dummy
serial2=modem listenport:77
serial3=disabled
serial4=disabled

The status window is registering the AT commands now ("Command sent to modem: ->ATZ<-, Modem response: OK), but mterm still isn't picking up anything on COM2.

You must switch RTS on.

Aha, that did the trick. So the default port setup is different between the versions; my fault for assuming it would be in a given state.

Thanks again for your help. This is a one awesome emulator; the bite of "progress" isn't as painful as it use to be.