A few weeks ago I had decided to finally make the switch to Microsoft's latest and greatest (and most of all free) C++ compiler: Microsoft Visual Studio 2008 Express. Transition of the projects required for D2X-XL went smooth ... so I thought.

Reality caught up quickly with me. I started to receive bug reports about D2X-XL quitting immediately after having been launched, with Windows displaying an error message that 'The application couldn't be initialized properly'. I began to dig around in the internet and after having read a very authoritative discussion thread about the issue came to the conclusion that D2X-XL users with that problem only needed to install the Microsoft Visual C++ 2008 Redistributable Package, and maybe the Microsoft .NET 2.0 Framework to be happy with the program again.

Not so.

A D2X-XL user drew my attention to the manifest files the Visual C compilers embed in executables and DLLs, telling the OS which additional libraries were required. According to these, the debug run time libraries were needed to run D2X-XL. I was baffled. Had I not compiled the program and every DLL from the package as release code? Yes I had. Did any of these components still contain debug information? No, they didn't.

So I was back to the internet, and I finally found an explanation so esoteric that I reckon it a miracle I found it at all. According to that source, Visual C++ links with an oldnames.lib library whenever it finds deprecated identifiers in a program, and in that case also links with the debug CRT library - even for release builds. The solution to this is to explicitly prohibit linking of msvcrtd.lib in the affected projects' linker options. Now I don't know whether this actually might be good for something, but if you ask me it looks pretty idiotic.

The most aggravating thing about the entire issue is that the 'deprecated' symbols were calls to functions like strlwr(), which Microsoft (for good, i.e. security reasons) would like to see replaced by calls to their safer counterparts checking the size of the buffer they're operating on. Still, strlwr() and the like are good old C standard, and who does Microsoft believe they are to simply give them the boot? Well, "Microsoft and standards", you may feel urged to say here ... Do I need to say that the way Microsoft offers to get around deprecation (using _CRT_SECURE_NO_WARNINGS) doesn't seem to work for DLLs, not to mention I couldn't find any detailled documentation about it, only a hint issued by the compiler when encountering such symbols?

I think I really should give Eclipse and gcc on Windows another shot, once MinGW will start to use gcc version 4.

...

As I am on it, a word about the 16 bit version of D2X-XL. That program version does not contain 16 bit code. It only lacks all references to 32 bit Windows DLLs and therefore can run on 16 bit Windows versions. So you don't need to worry that D2X-XL will only run at half speed when using that version.