Microsoft's Concept of APIs is Appalling

Our UDP sockets broke on Windows 98... again... today. So let me tell you exactly what makes Microsoft such a pain in the ass to deal with.

Microsoft stole its networking stack from BSD ages ago and so the WinSock APIs are supposed to be Berkely Socket compatible (BSD sockets). This means that I should be able to write code that works on Windows, Linux and OS X without having to change a thing. Well... it comes close. The only problem is that Microsoft chose to leave some APIs out until WinSock 2.0 (and some APIs are still not there such as IPC sockets). But sadly, this isn't my main gripe. My main gripe was that they claimed the upgrade path from WinSock 1.0 to WinSock 2.0 was transparent. You just link against a different library and away you go. THEY LIED!!

What the problem basically boils down to is the fact that in WinSock 1, you link against a certain library and use certain constant values when calling getsockopt or setsockopt. (You use these calls to do things like join/leave multicast groups, set the TTL, etc). But with WinSock 2, you link against another library (no big whoop there) but the constant values are DIFFERENT. Not just different, but rearranged! So when 4 used to mean IP_TTL (to set the time to live) in WinSock 1, it now means IP_MULTICAST_LOOP (setting the loopback property for multicast packets)!!

When you are just straight-up linking against the libraries, then things aren't too bad since you're using constants and it's a drop-in replacement. But if you're doing stuff like we're doing and dynamically loading the APIs, this totally messes things up in a very fast way. So when our UDP sockets break, it's because someone included windows.h in a place I wasn't expecting them to, so all the constants get messed up (because windows.h includes WinSock.h and that's WinSock 1 not WinSock 2) and I end up spending a few hours fixing the problem.

So I finally got pissed off enough today to just fix it for once and all. I made my own set of constants and dynamically set them at runtime to a local variable when trying to set the socket options. This way it doesn't matter who includes what -- I am just using my own logic not relying on header inclusion order. :: sighs :: It just annoys me when MS screws with things like this and they tend to do it in very fragile ways. Once you step even remotely off the beaten path, you're up a creek wondering where you paddle went.