C Run-Time Libraries (CRT) from msdn

Document directory

• C Run-Time Libraries (CRT)
• Standard C ++ Library
• What is the difference between msvcrt. dll and msvcr90.dll?
• What problems exist if an application uses both msvcrt. dll and msvcr90.dll?

This topic discusses the various. lib files that comprise the C run-time libraries as well as their associated compiler options and preprocessor directives.

This topic discusses various. lib files that comprise the C Runtime Library, as well as compiler options and pre-processor indicators related to them.

 

C Run-Time Libraries (CRT)

The following libraries contain the C run-time library functions.

The following library contains the C Runtime library functions.

 

CRuntime Library (No iostream and C ++ standard library)	Related DLL	Features	Option	Preprocessor indicator
Libcmt. lib	None, static link.	Multi-thread, static Link	/MT	_ MT
Msvcrt. lib	Msvcr90.dll	Multi-thread, Dynamic Link (import and export of MSVCR90.DLL ). Note: If the C ++ standard library is used, MSVCP90.DLL is required for program running.	/MD	_ MT, _ DLL
Libcmtd. dll	None, static link.	Multi-thread, static Link (debugging)	/MTd	_ DEBUG, _ MT
Msvcrtd. lib	Msvcr90d. dll	Multi-thread, Dynamic Link (MSVCR90D. DLL) (debugging)	/MDd	_ DEBUG, _ MT, _ DLL
Msvcmrt. lib	Msvcm90.dll	C import database during runtime. Used for hosting/native hybrid code.	/Clr
Msvcurt. lib	Msvcm90.dll	Compile the C Runtime import library as 100% pure MSIL code. All code is compiled using the ecma urt standard of MSIL.	/Clr: pure

 

The single-threaded CRT (libc. lib, libcd. lib) (formerly the/ML or/MLd options) is no longer available. instead, use the multithreaded CRT. see Multithreaded Libraries Performance.

Single-threaded CRT (libc. lib, libcd. lib) (Previous/ML or/MLd options) is no longer available. Instead, use multi-threaded CRT.

 

If you link your program from the command line without a compiler option that specifies a C run-time library, the linker will use LIBCMT. LIB. this is different from previous versions of Visual C ++ which used LIBC. LIB, the single-threaded library, instead.

If the program is linked from the command line without the compiler option of the specified C Runtime Library, the linker uses LIBCMT. LIB. This is different from the previous version of Visual Studio, which uses LIBC. LIB and a single-threaded library.

 

Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT. for example, if you use strtok, _ strtok_l, wcstok, _ wc1__l, _ mbstok, _ mb1__l when using a statically linked CRT, the position of the strtok parser is unrelated to the strtok state used in code in the same process (but in a different DLL or EXE) that is linked to another instance of the static CRT. in contrast, the dynamically linked CRT shares state for all code within a process that is dynamically linked to the CRT. this concern does not apply if you use the new more secure versions of these functions; for example, strtok_s does not have this problem.

 

Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. for example, if you call _ set_se_translator in an executable that loads the DLL linked to 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 code in the main executable will be caught.

Because the DLL linked to the static CRT will have its own CRT state, it is not recommended to statically link to the CRT in the DLL unless you do need and understand the consequences of doing so. For example, if _ set_se_translator is called in a program that loads a DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, however, hardware exceptions caused by the main executable program code will be captured.

 

Standard C ++ Library

C ++ standard library	Features	Option	Preprocessor indicator
Libcpmt. lib	Multi-thread, static Link	/MT	_ MT
Msvcprt. lib	Multi-thread, Dynamic Link (import/export of MSVCP90.DLL)	/MD	_ MT, _ DLL
Libcpmtd. lib	Multi-thread, static Link (debugging)	/MTd	_ DEBUG, _ MT
Msvcprtd. lib	Multi-thread, Dynamic Link (MSVCR90D. DLL) (debugging)	/MDd	_ DEBUG, _ MT, _ DLL

 

NoteStarting in Visual C ++ 2005, LIBCP. LIB and LIBCPD. LIB (via the old/ML and/MLd options) have been removed. use LIBCPMT. LIB and LIBCPMTD. LIB instead via the/MT and/MTd options.

Note that libcp. lib and libcpd. lib (old/ML and/MLd options) have been removed from Visual C ++ 2005. Use/MT and/MTd to replace libcpmt. lib and libcpmtd. lib.

 

When you build a release version of your project, one of the basic C run-time libraries (LIBCMT. LIB, MSVCMRT. LIB, MSVCRT. LIB) is linked by default, depending on the compiler option you choose (multithreaded, DLL,/clr ). if you include one of the Header Files in your code, a Standard C ++ Library will be linked in automatically by Visual C ++ at compile time. for example:

When building the project's release version, one of the basic C Runtime libraries (libcmt. lib, msvcmrt. lib, msvcrt. lib) is linked by default, depending on the compiler options you choose (multithreading, DLL,/clr ). If the Code contains one of the C ++ standard library header files (http://msdn.microsoft.com/en-us/library/a7tkse1h (VS.80). aspx), Visual C ++ automatically links the C ++ standard library during compilation. For example:

# Include <ios>

 

What is the difference between msvcrt. dll and msvcr90.dll?

The msvcrt. dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.

 

What problems exist if an application uses both msvcrt. dll and msvcr90.dll?

If you have. lib or. obj file that needs to link to msvcrt. lib, then you shoshould not have to recompile it to work with the new msvcrt. lib in Visual C ++ 2008. the. lib or. obj file may rely on the sizes, field offsets, or member function names of varous CRT classes or variables, and those shoshould all still exist in a compatible way. when you relink against msvcrt. lib, your final EXE and DLL image will now have a dependency on msvcr90.dll instead of msvcrt. dll.

If you have more than one DLL or EXE, then you may have more than one CRT, whether or not you are using different versions of Visual C ++. for example, statically linking the CRT into multiple DLLs can present the same problem. developers encountering this problem with static CRTs have been extends ucted to compile with/MD to use the crt dll. now that the crt dll has been renamed to msvcr90.dll, applications may have some components linked to msvcrt. dll and others to msvcr90.dll. if your DLLs pass CRT resources within ss the msvcrt. dll and msvcr90.dll boundary, you will encounter issues with mismatched CRTs and need to recompile your project with Visual C ++ 2008.

If your program is using more than one version of the CRT, some care is needed when passing certain CRT objects (such as file handles, locales and environment variables) using ss dll boundaries. for more information on the issues involved and how to resolve them, see Potential Errors Passing CRT Objects using ss dll Boundaries.