第一篇 如何使用C Run-Time Library

一 C Run-Time Libraries的三种可用形式

Win32 SDK提供了三种C Run-time library 的可用形式

    LIBC.LIB: 单线程程序静态链接到运行时库

    LIBCMT.LIB: 多线程程序静态链接到运行时库

    CRTDLL.LIB: CRTDLL.DLL的导入库，支持多线程程序的链接。CTRDLL.DLL 本身是Windows NT的一部分。

    ms vc++32位 版本同时包含了这三种运行时库，不过CRT 动态库被命名为 MSVCRT.LIB。 这个动态链接库是可重新发布的。它的名字取决于vc++的版本（MSVCRT10.DLL 或者 MSVCRT20.DLL）。注意，win32不载支持MSVCRT10.DLL,但是支持CRTDLL.LIB；MSVCRT20.DLL有两个版本， 一个是windowsnt版，另一个是win32版。

 

二 当生成一个DLL时使用CRT Libraries

    在生成一个DLL时，无论使用了哪个C Run-time libraries库，都要保证所使用的CRT被正确的初始化。可以使用下面任何一种方法：

    1 初始化函数必须被命名为：DllMain() 并且 入库点必须在连接器选项中必须指定入口点位： _DllMainCrtStartup@12 -或者-。

    2 在附加进程和分离进程的过程中，这个DLL的入库点必须显式调用CRT_INIT()。　

   

    这样当一个进程或者线程连接到这个DLL时，C 运行时库可以正确的分配和初始化数据，并且当进程或者线程离开DLl时候可以正确的清理掉运行时库，　ＤＬＬ中的全局C++对象(global C++ objects)也可以正确的构造和解构。　下面的Win32 SDK例子程序都使用了第一种方法。请参考　win32 programmer's reference for DllentryPoint() and the Vc++ documentation for DllMain().　注意函数DllMainCRTStartup()调用了 CRT_INIT() ，　而CRT_INIT()在退出前将调用你的程序的DllMain()。如果你希望使用第二种方法来在自己调用CRT初始化代码，而不使用DllMainCRTStartup() 和 DllMain()函数，你可以使用两种技术：

　　1 如果没有入口函数来执行初始化代码，只需要指定CRT_INIT()作为该DLL的入口点。假设你已经包含了文件 NTWIN#@.MAK, 这个文件定义 DLLENTRY 为"@12", 加入以下选项到DLL的链接选项命令行：

      -entry:_CRT_INIT$(DLLENTRY)

      - or -

      2 如果你确实想拥有自己的DLL入口点， 在入口点做如下的事情：

       a 使用CRT_INIT()的原形:

          BOOL WINAPI _CRT_INIT(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) ;

          关于CRT_INIT()的返回值，可以看 documentation DllEntryPoint，它返回了相同的返回值。

       b 在DLL_PROCESS_ATTACH 和 DLL_THREAD_ATTACH块中， 在调用任何C 运行时库函数和对任何浮点指针操作前首先调用CRT_INIT()。

       c 调用自己的进程/线程 初始/结束 代码。

       d 在DLL_PROCESS_DETACH 和DLL_THREAD_DETACH 中，在所有的C运行时库函数被调用，并且所有浮点指针操作完成以后，最后一次调用CRT_INIT()。

        要确保向CRT_INIT()传递了入口点的所有参数。 CRT_INIT()需要这些这些参数。如果参数没有全部传递过去，可能不能稳定运行（尤其需要 fdwReason参数来确定进程的初始化或者结束）。下边实例关于如何在入口点调用CRT_INIT()。

       BOOL WINAPI DllEntryPoint(HINSTANCE hinstDll, DWORD fdwReason, LPVOID lpReserved)

      {

      if (fdwReason == DLL_PROCESS_ATTACH || fdwReason == DLL_THREAD_ATTACH)

         if (!_CRT_INIT(hinstDll, fdwReason, lpReserved))

            return (FALSE) ;

      if (fdwReason==DLL_PROCESS_DETACH || fdwReason ==DLL_THREAD_DETACH)

         if (!_CRT_INIT(hinstDLL, fdwReason, lpReserved))

            return (FALSE) ;

      return (TRUE) ;

      }

      当然，如果使用DLLMain() 并且设置了链接选项：-entry:_DllMainCRTStartup@12 ，则上述代码就不需要了。

 

三 使用NTWIN32.MAK来简化生成过程

在NTWIN32.MAK中的宏定义可以帮助你简化makefiles，并且可以确保正确的生成而避免冲突产生。因此，ms强烈推荐使用NTWIN32.MAK以及它所包含的宏。

      编译使用： $(cvarsdll)   for apps/DLLs using CRT in a DLL

      链接使用下列行中的一个：

      $(conlibstdll)   for console apps/DLLs using CRT in a DLL

      $(guilibsdll)     for GUI apps using CRT in a DLL

 

四 当使用Multiple CRT 库是可能遇到的问题

     如果一个使用了C运行时调用的应用程序，链接到另一个也使用了了C运行时调用的DLL, 注意如果他们都连接到了一个C运行时的静态库(LIBC.LIB 或者 LIBCMT.LIB)， 这个EXE 和DLL将各自拥有C运行时的单独的拷贝和全局变量。这意味着C运行时数据不能被这个.EXE和.DLL所共享。当进行以下操作时会产生问题：

    1 从.EXE 或者.DLL传递缓冲流句柄(bufferd stream handles)到另一个模块

    2 使用C 运行时库在一个模块中分配一块内存，而在另外一个模块中对这个内存进行重分配操作或者是房内存操作(alloc realloc)。

    3 在.EXE或者.DLL模块中检查或者设置一个全局错误号变量(global errno variable)的值，而期望在另外的模块中会获得同样的值。另外一个相关的错误操作是：在未产生错误的模块中调用perror()函数。 （perror()会使用错误号）

 

为了避免这些问题，应该把.EXE和.DLL都连接上 CRTDLL.LIB 或者 MSVCRT.LIB。这样允许.EXE 和.DLL都是使用在 动态CRT中包含的公共函数集和数据， 并且C运行时数据，例如 流句柄，可以被.EXE和.DLL所共享。

 

五 混合库类型的装入问题（不懂，待译。有懂得人请指教）

You can link your DLL with CRTDLL.LIB/MSVCRT.LIB regardless of what your .EXE is linked with if you avoid mixing CRT data structures and passing CRT file handles or CRT FILE* pointers to other modules.

When mixing library types adhere to the following:

•	CRT file handles may only be operated on by the CRT module that created them.
•	CRT FILE* pointers may only be operated on by the CRT module that created them.
•	Memory allocated with the CRT function malloc() may only be freed or reallocated by the CRT module that allocated it.

To illustrate this, consider the following example:

   - .EXE is linked with MSVCRT.LIB
   - DLL A is linked with LIBCMT.LIB
   - DLL B is linked with CRTDLL.LIB
				

If the .EXE creates a CRT file handle using _create() or _open(), this file handle may only be passed to _lseek(), _read(), _write(), _close(), etc. in the .EXE file. Do not pass this CRT file handle to either DLL. Do not pass a CRT file handle obtained from either DLL to the other DLL or to the .EXE.

If DLL A allocates a block of memory with malloc(), only DLL A may call free(), _expand(), or realloc() to operate on that block. You cannot call malloc() from DLL A and try to free that block from the .EXE or from DLL B.

NOTE: If all three modules were linked with CRTDLL.LIB or all three were linked with MSVCRT.LIb, these restrictions would not apply.

When linking DLLs with LIBC.LIB, be aware that if there is a possibility that such a DLL will be called by a multithreaded program, the DLL will not support multiple threads running in the DLL at the same time, which can cause major problems. If there is a possibility that the DLL will be called by multithreaded programs, be sure to link it with one of the libraries that support multithreaded programs (LIBCMT.LIB, CRTDLL.LIB or MSVCRT.LIB).

 

 

 五 附加英文原文

Section 1: Three Forms of C Run-Time (CRT) Libraries Are Available

There are three forms of the C Run-time library provided with the Win32 SDK:

•	LIBC.LIB is a statically linked library for single-threaded programs.
•	LIBCMT.LIB is a statically linked library that supports multithreaded programs.
•	CRTDLL.LIB is an import library for CRTDLL.DLL that also supports multithreaded programs. CRTDLL.DLL itself is part of Windows NT.

Microsoft Visual C++ 32-bit edition contains these three forms as well, however, the CRT in a DLL is named MSVCRT.LIB. The DLL is redistributable. Its name depends on the version of VC++ (ie MSVCRT10.DLL or MSVCRT20.DLL). Note however, that MSVCRT10.DLL is not supported on Win32s, while CRTDLL.LIB is supported on Win32s. MSVCRT20.DLL comes in two versions: one for Windows NT and the other for Win32s.

Section 2: Using the CRT Libraries When Building a DLL

When building a DLL which uses any of the C Run-time libraries, in order to ensure that the CRT is properly initialized, either

1.	the initialization function must be named DllMain() and the entry point must be specified with the linker option -entry:_DllMainCRTStartup@12 - or -
2.	the DLL's entry point must explicitly call CRT_INIT() on process attach and process detach

This permits the C Run-time libraries to properly allocate and initialize C Run-time data when a process or thread is attaching to the DLL, to properly clean up C Run-time data when a process is detaching from the DLL, and for global C++ objects in the DLL to be properly constructed and destructed.

The Win32 SDK samples all use the first method. Use them as an example. Also refer to the Win32 Programmer's Reference for DllEntryPoint() and the Visual C++ documentation for DllMain(). Note that DllMainCRTStartup() calls CRT_INIT() and CRT_INIT() will call your application's DllMain(), if it exists.

If you wish to use the second method and call the CRT initialization code yourself, instead of using DllMainCRTStartup() and DllMain(), there are two techniques:

1.

if there is no entry function which performs initialization code, simply specify CRT_INIT() as the entry point of the DLL. Assuming that you've included NTWIN32.MAK, which defines DLLENTRY as "@12", add the following option to the DLL's link line: -entry:_CRT_INIT$(DLLENTRY) - or -

2.

if you *do* have your own DLL entry point, do the following in the entry point: a. Use this prototype for CRT_INIT(): BOOL WINAPI _CRT_INIT(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved); For information on CRT_INIT() return values, see the documentation DllEntryPoint; the same values are returned. b. On DLL_PROCESS_ATTACH and DLL_THREAD_ATTACH (see "DllEntryPoint" in the Win32 API reference for more information on these flags), call CRT_INIT(), first, before any C Run-time functions are called or any floating-point operations are performed. c. Call your own process/thread initialization/termination code. d. On DLL_PROCESS_DETACH and DLL_THREAD_DETACH, call CRT_INIT() last, after all C Run-time functions have been called and all floating- point operations are completed. Be sure to pass on to CRT_INIT() all of the parameters of the entry point; CRT_INIT() expects those parameters, so things may not work reliably if they are omitted (in particular, fdwReason is required to determine whether process initialization or termination is needed). Below is a skeleton sample entry point function that shows when and how to make these calls to CRT_INIT() in the DLL entry point: BOOL WINAPI DllEntryPoint(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) { if (fdwReason == DLL_PROCESS_ATTACH || fdwReason == DLL_THREAD_ATTACH) if (!_CRT_INIT(hinstDLL, fdwReason, lpReserved)) return(FALSE); if (fdwReason == DLL_PROCESS_DETACH || fdwReason == DLL_THREAD_DETACH) if (!_CRT_INIT(hinstDLL, fdwReason, lpReserved)) return(FALSE); return(TRUE); } NOTE that this is *not* necessary if you are using DllMain() and -entry:_DllMainCRTStartup@12.

 

Section 3: Using NTWIN32.MAK to Simplify the Build Process

There are macros defined in NTWIN32.MAK that can be used to simplify your makefiles and to ensure that they are properly built to avoid conflicts. For this reason, Microsoft highly recommends using NTWIN32.MAK and the macros therein.

For compilation, use:

   $(cvarsdll)          for apps/DLLs using CRT in a DLL
				

For linking, use one of the following:

   $(conlibsdll)        for console apps/DLLs using CRT in a DLL
   $(guilibsdll)        for GUI apps using CRT in a DLL

Section 4: Problems Encountered When Using Multiple CRT Libraries

If an application that makes C Run-time calls links to a DLL that also makes C Run-time calls, be aware that if they are both linked with one of the statically-linked C Run-time libraries (LIBC.LIB or LIBCMT.LIB), the .EXE and DLL will have separate copies of all C Run-time functions and global variables. This means that C Run-time data cannot be shared between the .EXE and the DLL. Some of the problems that can occur as a result are:

•	Passing buffered stream handles from the .EXE/DLL to the other module
•	Allocating memory with a C Run-time call in the .EXE/DLL and reallocating or freeing it in the other module
•	Checking or setting the value of the global errno variable in the .EXE/DLL and expecting it to be the same in the other module. A related problem is calling perror() in the opposite module from where the C Run- time error occurred, since perror() uses errno.

To avoid these problems, link both the .EXE and DLL with CRTDLL.LIB or MSVCRT.LIB, which allows both the .EXE and DLL to use the common set of functions and data contained within CRT in a DLL, and C Run-time data such as stream handles can then be shared by both the .EXE and DLL.

Section 5: Mixing Library Types

You can link your DLL with CRTDLL.LIB/MSVCRT.LIB regardless of what your .EXE is linked with if you avoid mixing CRT data structures and passing CRT file handles or CRT FILE* pointers to other modules.

When mixing library types adhere to the following:

•	CRT file handles may only be operated on by the CRT module that created them.
•	CRT FILE* pointers may only be operated on by the CRT module that created them.
•	Memory allocated with the CRT function malloc() may only be freed or reallocated by the CRT module that allocated it.

To illustrate this, consider the following example:

   - .EXE is linked with MSVCRT.LIB
   - DLL A is linked with LIBCMT.LIB
   - DLL B is linked with CRTDLL.LIB
				

If the .EXE creates a CRT file handle using _create() or _open(), this file handle may only be passed to _lseek(), _read(), _write(), _close(), etc. in the .EXE file. Do not pass this CRT file handle to either DLL. Do not pass a CRT file handle obtained from either DLL to the other DLL or to the .EXE.

If DLL A allocates a block of memory with malloc(), only DLL A may call free(), _expand(), or realloc() to operate on that block. You cannot call malloc() from DLL A and try to free that block from the .EXE or from DLL B.

NOTE: If all three modules were linked with CRTDLL.LIB or all three were linked with MSVCRT.LIb, these restrictions would not apply.

When linking DLLs with LIBC.LIB, be aware that if there is a possibility that such a DLL will be called by a multithreaded program, the DLL will not support multiple threads running in the DLL at the same time, which can cause major problems. If there is a possibility that the DLL will be called by multithreaded programs, be sure to link it with one of the libraries that support multithreaded programs (LIBCMT.LIB, CRTDLL.LIB or MSVCRT.LIB).