An alternative fix for DirectPlay issues on Windows 10

TheNamelessOne

Warlord
Joined
Dec 18, 2013
Messages
227
I've noticed that some people are running into issues with DirectPlay, which is now deprecated in the latest version of Windows 10. This should still be easy to enable, but this might change in the future. So I've removed all references to DirectPlay from the civ2 networking library (XDaemon.dll), completely avoiding the issue.

This should not affect anything, since the DirectPlay functions are only used in modem & serial connections (which nobody uses anymore). I've played a quick multiplayer game (TCP on LAN), and everything seemed ok, game state was exchanged normally, players could communicate fine etc.

This should work for both MGE and ToT, they use the same version of XDaemon.dll (although I've only tested ToT). I'd still recommend enabling DirectPlay in Windows 10, but you can use this as a backup if that doesn't work for some reason.

Instructions: Just extract the contents of the zip file into the MGE/ToT directory, overwriting XDaemon.dll (it might be prudent to backup the old file just in case).
 

Attachments

  • XDaemon.zip
    44.7 KB · Views: 475
Hi, TheNamelessOne!

That is a very cool idea! Never thought of DPLAYX-dependence as of something really unnecessary.
Nevertheless, I would like to add that even though the XDaemon.dll files for ToT and MGE have the same size and version, they still are not binary identical. They have some memory addressing differences. Although they seem to be interchangeable. But when it comes to memory patching with launchers like TOTPP or my CIV2UIA it brings problems (if you are lazy to calculate correct addresses from import table).
The real problem for Windows 8/10 users playing multiplayer is that with new OS the default size of socket buffers were increased so they don't fit in 2-bytes variable. I already written about this and made a fix for MGE.
Finally about socket buffers in multiplayer. All network part of the game resides in a separate library XDaemon.dll. That library uses Windows Sockets API (wsock32.dll) for organizing multiplayer game. Socket is endpoint for sending/receiving data. Socket has a lot of options and two of them are SO_RCVBUF and SO_SNDBUF. That is as MS online help states "The total per-socket buffer space reserved for receives/sends."
When opening socket with socket function all its options are initialized with defaults. It seems that for many years default values for SO_RCVBUF and SO_SNDBUF were no more than 0x2000 bytes. So programmers of XDaemon.dll didn't bothered about setting those options explicitly with setsockopt function hoping that it would be always the same. Also later in code they used getsockopt function to read SO_RCVBUF option and store it in 2-bytes variable for using later in data-receive loops.
But in Windows 8 and 10 the default value became 0x10000. And it doesn't fit in 2-bytes variable causing it to be zero and no data received at some point.
What I did is just added explicit call of setsockopt function for setting correct buffer sizes right after opening socket. I choose value of 0x2000 as it seems like game is somehow bound to this value.
Information on the buffer sizes can be observed in XDaemon.log.
I picked up your idea and made same fix for MGE-version of XDaemon.dll so it could be used with my launcher.
 

Attachments

  • XDaemon no-DPLAYX for MGE.zip
    45.6 KB · Views: 288
Last edited:
Interesting, thanks for your analysis. I don't own a copy of either Windows 8 or 10, so I wasn't hit by this issue. Here's a new version that calls setsockopt as well.
 

Attachments

  • XDaemon.zip
    44.7 KB · Views: 234
Top Bottom