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.
We don't need any memory reserved for writing out packet headers, but
DirectPlay seems to corrupt itself internally and do funky things if this goes
below a certain threshold. Value taken from the DX5 service provider.
Initialise the discovery socket when SP_CreatePlayer() is called with the
CREATEPLAYER_NS flag and do nothing in SP_Open, as per the DX5 implementation.
This will correctly handle the name server moving between nodes in a session.
Hold the lock while reading to ensure the socket isn't closed during the
recvfrom() call, allow either socket to be closed and close either socket if
the recvfrom() call fails.
When there are more than two players in a session (including the host), the
message that triggers SP_CreatePlayer() may not be from the host that actually
has that player on it, copy the behaviour of the DX5 SP and make each player be
responsible for sharing their own address via the shared data.
Implementing this method isn't mandatory and the Microsoft implementation
doesn't provide it. It doesn't appear to get used either, so ditching it to
reduce the number of things that can go wrong.
WIP: SP_Send cleanup
Various fixups to build under win-builds.org toolchain rather than MinGW. No
longer builds under MinGW as I have removed headers/definitions that it lacks.
