What are some reasons not to statically reference the VC CRT?
I find that with dynamic linking, even with SxS, Windows Update will pop up and stomp on the VC8 CRT version (for example, it has a security flaw), and then my application won't be able to work with older versions.
Aside from increasing the size of your binaries, what are some of the important reasons to stay dynamic linking with the VC CRT?
source to share
-
Keeping an eye on security fixes is a good reason. Otherwise, you are responsible for rebuilding the fixed CRT application and deploying it to your customers.
-
Using a shared CRT should result in lower memory footprint for the system, since most DLL pages can be shared between processes.
source to share
I prefer static linking. Security is not a big issue since hackers target applications that many users have installed on their system. So if your application doesn't have more than 1 million users, I wouldn't worry about it being used by hackers.
I don't like dynamic linking. It seems too fragile to me.
EDIT. And if you want to make sure your users have an updated version of your app, then also write an updater app that will be automatically installed along with your main app. On Windows, this can be implemented as a Service.
source to share
See http://people.redhat.com/drepper/no_static_linking.html
This is about Linux, but some of them are applicable.
source to share
Done correctly , there should be no dynamic linking issues and the application should not start. The only tricky thing is to switch to building your installer from whatever method you use before it is supported by Microsoft (Merge Redistributables - MSM, MSI, Dynamic Link). See this link for extremely valuable advice straight from the source. Some interesting quotes from the blog:
- To redistribute Visual C ++ libraries, you have to do everything : include the corresponding .MSM file and the accompanying .MSM policy to distribute the library you need.
- Again, just to emphasize - don't use VCRedist * .exe unless you are using Click Once to deploy your application.
- However, I can think of no scenarios where this (my note: static linking) is actually the right thing to do when shipping your product to customers.
I agree that you may need to do some non-trivial work (you may not be using MSI right now, etc.), but I think if the resources allow you to try and follow the recommended methods above.
And if you do not do as described above, your application will indeed stop working at some point. And the developers blame Microsoft until they actually followed the supported way outlined above. Perhaps Microsoft is to blame because it no longer links to the blog above on MSDN to spread the word, but that's about it.
source to share
When your program uses something from a CRT, that is one of the "security leaks" you mention. If you link statically, your users will not know that they are exposed to a security vulnerability and could be at risk of a virus. On the other hand, if your program does not work because it is dynamically linked, it will be forced to update to a new safe version.
source to share
You're in luck on Windows. And Linux is literally made up of libraries and you have problems like this with all of them. :-)
As far as I understand, library vendors are always backward compatible, especially if it's Microsoft. Thus, a possible solution is to build the application on an old machine, keeping in mind that Microsoft is developing the CRT library in such a way that your application will work in all future versions.
source to share