It appears that some of the mswsock.dll functions get called on
Windows 98 in a context where calling any of the printf functions
provided by the CRT causes subtle memory corruption which doesn't
manifest until the process exits, triggering a page fault in
KERNEL32.DLL and making the system unusable.
1990s Windows makes me miss the sophistication of 1970s UNIX.
This introduces "packet coalescing" for the DOSBox transport - when an
application is sending an absurd number of tiny IPX packets in rapid
succession we try to batch them up into a container packet to be sent
through the DOSBox server.
This will hopefully improve how certain games behave when using the
DOSBox transport option, but will break compatibility with anything not
specifically supporting this special message framing.
When there are no packets waiting, ioctlsocket() should return success
and set *argp to zero.
When there are multiple packets waiting, ioctlsocket() should set *argp
to the accumulated size of all received payloads.
As far as I can tell, there's no way to inspect beyond the first packet
queued on a socket, so we must receive and queue all packets from the
socket to be able to know how much is available.
The recv pipeline has been reworked to queue packets in this manner,
and select() will try to emulate the normal behaviour we previously got
for free by passing the socket fd straight through in readfds.
I don't *think* WSAAsyncSelect() needs any changes since the socket
will still raise window messages as appropriate before we have any
opportunity to shunt the packet into the receive queue.
Normally calls like bind() will immediately succeed or fail depending
on what address was requested and what addresses are assigned to the
machine, but when using a DOSBox IPX server we don't know our address
until it gets assigned to us, so block functions impacted by that to
avoid spurious errors when starting up.
If the server is down or slow then the calls will fail after a few
seconds rather than hanging indefinitely.
Subtle crashes are fun. I found this to cause a deadlock, but only
after adding lots of extra debug logging to diagnose a DIFFERENT bug
and only when running it on a particular machine.
But once both of those criteria are met? It crashes pretty reliably.
