William Shakespeare, genius that he was, penned the immortal lines. quite unfortunately, the converse also holds: a nettle by any other name is still going to sting just as well. this is the weird beginning to todays post on the many wonders of developing on Windows, specifically DLL hell - or at least a problem much like it.
for the uninformed, DLL hell comes about from the process of installing and uninstalling programs, usually resulting in an important shared library (DLL) being replaced with a version that causes other programs to fail. see this Wikipedia article for more information.
my problem isn't quite DLL hell, but it is related somehow. now, for unmanaged C++ (that is, C++ native code, or code not managed by the .NET Framework, hence the name), you'll most likely require some sort of runtime, as defined by your compiler vendor/settings. with Visual C++ 6.0, you needed
msvcp60.dll for the runtime of non-debug C and C++ runtimes respectively, and for Visual C++ 8.0 (including VC++ 2005 Express, which i use), you have
msvcp80.dll - or something like that. where DLL hell comes in is that if you have the required DLLs for a program to run installed, some program may replace/remove such when you install/uninstall it, breaking other programs needing it. in my case, i've been writing code that had a dependency on
msvcp80.dll, and didn't have a problem until i uninstalled something. suddenly previously perfectly working programs i wrote stopped doing so. now Microsoft has these redistributable packages that allow you run programs with that particular runtime dependency. so i got a copy of the Visual C++ 2005 Redistributable package (download page here) and installed it. twice (two different copies, that is). no dice. i finally had to rebuild the application framework library (wxWidgets) so i could statically link in the C/C++ runtime for each application. ah well. i did at least know enough to get round my problem without reinstalling my compiler and its service pack. sayonara!