I spent a good part of Sunday recompiling many popular open source libraries (i.e. iconv, libxml, libxslt, xmlsec, openssl, zlib, etc.) as Win32 static multithreaded libraries without C runtime DLL name dependency (/MT) so I can use them in VC7.1 projects.  All because some guy at Microsoft decided to change the C runtime DLL name from fixed MSVCRT.DLL to version-based names like MSVCR70.DLL.

When that happend, popular open source tools and libraries got stuck with Visual C++ 6.  Binaries of Python and all the libraries I mentioned above, for example, are built with VC6 and links to C runtime library dynamically (meaning they require MSVCRT.DLL).  This means Win32 Python extensions couldn't be built with later versions of VC++ without walking into a lot of headaches.  Same problem stopped me from using prebuilt binaries of those libraries so I had to rebuild them myself.

I bent a few things and had to guess at a few places, but nothing seems to be broken.  Only trouble is that I am using WinInet to fetch XML files from Internet and it ain't behaving too well.  WinHTTP is supposed to be better but I think I'll opt for cURL instead.  Of course, that means I'll have more compiling to do next weekend.  Urgh.

Update:

Heh.  I didn't realize the weekend wasn't over yet until my wife informed me that today was the Labor Day.  To celebrate, I labored some more after a mini-vacation at the neighborhood pool with my wife and son.  cURL had Win32 project files so it was a cinch to build.  I did have to turn on OpenSSL and ZLib though to get HTTPS and gzip compression working (define USE_OPENSSL, HAVE_ZLIB, and HAVE_ZLIB_H flags).  Now I can reliably pull compressed RSS feeds over HTTPS from a Win32 client.

BTW, all these chores wouldn't have been necessary if I wrote it in Java or .NET because both platforms have most of these libraries built in.  So why am I humping the sidewalk?  Well, there are still things one can do with C++ that you can't do with Java or .NET…