Recommendations for using Visual Studio 2008, Runtime Libraries

I need some information about runtime libraries for Visual Studio 2008. Most specifically, when to consider DLL versions and when to consider static versions.

Visual Studio documentation describes technical differences regarding DLL dependencies and related libraries. But I do not understand why I should use one over the other. More importantly, why should I use a multi-threaded runtime DLL when this explicitly causes my application to become dependent on the DLL, while a static runtime does not have this requirement on my application user machine.

+4
source share
4 answers

Larry Osterman believes that you should always use a multi-threaded DLL for programming applications. Summarizing:

  • Your application will be smaller
  • Your application will load faster
  • Your application will support multiple threads without changing the library dependency.
  • Your application can be easily divided into several DLLs (since only one instance of the loaded library will be loaded)
  • Your application will automatically update with security patches sent by Microsoft.

Read his entire blog post for full details.

In the opposite direction, you need to redistribute the runtime library, but this is usually done, and you can find out how to include it in your installer.

+3
source

Linking dynamically to runtime libraries is a little difficult to deploy due to the DLL dependency, but it also allows your application to use updates (bug fixes or higher performance improvements) for MS runtime libraries without recompiling.

Static binding simplifies deployment, but means your application must be recompiled for newer versions of the runtime in order to use them.

+5
source

Dynamically linking the runtime library can give you faster program startup times and less system memory usage, since the dll can be shared between processes and will not need to be loaded again if it is already in use by another process.

+1
source

I think the main difference is how the exceptions will be handled. Microsoft does not recommend linking statically to CRTs in a DLL, unless the consequences are particularly desirable and understandable:

For example, if you call _set_se_translator in an executable file that loads the DLL associated with its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by the code in the main executable file will be detected.

+1
source

All Articles