What are some reasons not to statically link to the VC CRT?

Question

I'm finding that with dynamic linking, even with SxS, Windows Update will come along and stomp on a version of the VC8 CRT (for example it has a security flaw) and then my app will fail to run with older versions.

What are some of the important reasons to stay with the dynamic linking with VC CRT, other than increasing the size of your binaries?

Answer 1

When your program is using something from the CRT that is one of the 'security leaks' that you mention. If you link statically your users won't know that they are subject to a security flaw, and are maybe in danger of a virus. On the other hand if your program doesn't work because it is dynamically linked they will be forced to update to the new safe version.

Answer 2

1. Staying up to date on security fixes is a good reason. Otherwise, you're responsible for rebuilding your application with a fixed CRT and deploying it to your customers.
2. Using a shared CRT should result in lower memory footprint for the system, since most of the DLL's pages can be shared between processes.

Answer 3

See http://people.redhat.com/drepper/no%5Fstatic%5Flinking.html

It's about linux, but some of the ideas apply.

Answer 4

You're lucky out there in Windows. And Linux literally consists of libraries, and you have such issues with all of them. :-)

As far as I understand, library vendors always retain backward compatibility, especially if it's Microsoft. So, the possible solution is to build your application on an old machine, keeping in mind that Microsoft develops CRT library in the way that your app will run on all further versions.

Answer 5

I prefer static linking. Security is not a really big issue since hackers target applications that many users have installed on their system. So unless your application has over 1 million users, I wouldn't worry about it being exploited by hackers.

I don't like dynamic linking. It just feels too fragile to me.

EDIT: And if you want to make sure that your users have an up-to-date version of your application then also write an updater application that is automatically installed along with your main app. On Windows this could be implemented as a Service.

Answer 6

If done right there should be absolutely no problem with dynamic linking and the application should not fail to run. The only hard part is to switch to building your installer from whatever method you use now to the way supported by Microsoft (redistributable merge modules - MSM, MSI, dynamic linking). See this link for extremely precious advice right from the source. Some interesting quotes from the blog:

• In order to redistribute the Visual C++ libraries, all you need to do is include the appropriate .MSM file and its accompanying policy .MSM to distribute the library you need.
• Again, just to emphasize – do not use VCRedist*.exe unless you are using Click Once to deploy your application.
• However, I can think of no scenarios in which this (my note: static linking) is actually the right thing to do when shipping your product to customers.

I do agree that you might need to do non-trivial work to implement this (maybe you're not using MSI right now etc.) but I think that if resources allow you should try to switch to the recommended methods described above.

And if you don't do it the way described above your application will indeed stop working at some point. And developers blame Microsoft while they were really not following the supported way described above. Maybe Microsoft is to blame because it doesn't link to the blog above more often on MSDN to spread the word but that's about it.