A while ago I wrote a Windows application with Visual Studio 2008. Everything went fine when tested on the development platform (Server 2003), but when I deployed it on Windows XP, the system complained that the application needed to be reinstalled.
What?
I scratched my head. My application was simple enough that it had only one executable, required no fancy installation, and I double checked that it didn't depend on anything specific to Server 2003.
In fact it did, sort of. It was linked to a version of VC runtime that doesn't ship with Windows XP, according to
Dependency Walker.
How did that happen? Turned out that Visual Studio 2008 comes with this latest and greatest msvcr90.dll, and my application happened to use some C library functions. With the "right" compiler settings, msvcrt.lib (version 9) was linked in, and so I had no choice but needed this CRT to run a simple Windows application on XP.
What a great idea. An additional dll that's several times bigger than my application.
Or did I have a choice?
I could statically link the new CRT, thus only need to ship one executable file. Nah, that doesn't solve the size problem.
I could copy the old msvcrt.lib to tell VS that the application needs the old msvcrt.dll, which ships with XP, and thus eliminate the need of msvcr90.dll.
Or so I thought. Or so depends.exe said. What happened was, to use themed common controls, I told VS to include the proper manifest; and to avoid distributing yet another file, I told VS to embed (hide) the manifest in the executable. Little did I know that this manifest also included a dependency on Microsoft.VC90.CRT...
Now I could use
Resource Hacker to edit that out. It would have been easier if VS allowed me to choose the version of CRT to begin with.
Of course, in the end, I started from
this article and dropped the C runtime functions altogether.
. Some open source projects come to rescue, and the key GUID has been discovered.
