DLLDynamic Link Libraries全面剖析.docx

DLLDynamic Link Libraries全面剖析.docx

《DLLDynamic Link Libraries全面剖析.docx》由会员分享，可在线阅读，更多相关《DLLDynamic Link Libraries全面剖析.docx（13页珍藏版）》请在冰点文库上搜索。

DLLDynamicLinkLibraries全面剖析

DLL（DynamicLinkLibraries）全面剖析

　　引言

　　比较大的应用程序都由很多模块组成，这些模块分别完成相对独立的功能，它们彼此协作来完成整个软件系统的工作。

可能存在一些模块的功能较为通用，在构造其它软件系统时仍会被使用。

在构造软件系统时，如果将所有模块的源代码都静态编译到整个应用程序EXE文件中，会产生一些问题：

一个缺点是增加了应用程序的大小，它会占用更多的磁盘空间，程序运行时也会消耗较大的内存空间，造成系统资源的浪费；另一个缺点是，在编写大的EXE程序时，在每次修改重建时都必须调整编译所有源代码，增加了编译过程的复杂性，也不利于阶段性的单元测试。

Windows系统平台上提供了一种完全不同的较有效的编程和运行环境，你可以将独立的程序模块创建为较小的DLL（DynamicLinkableLibrary）文件，并可对它们单独编译和测试。

在运行时，只有当EXE程序确实要调用这些DLL模块的情况下，系统才会将它们装载到内存空间中。

这种方式不仅减少了EXE文件的大小和对内存空间的需求，而且使这些DLL模块可以同时被多个应用程序使用。

Windows自己就将一些主要的系统功能以DLL模块的形式实现。

　　一般来说，DLL是一种磁盘文件，以.dll、.DRV、.FON、.SYS和许多以.EXE为扩展名的系统文件都可以是DLL。

它由全局数据、服务函数和资源组成，在运行时被系统加载到调用进程的虚拟空间中，成为调用进程的一部分。

如果与其它DLL之间没有冲突，该文件通常映射到进程虚拟空间的同一地址上。

DLL模块中包含各种导出函数，用于向外界提供服务。

DLL可以有自己的数据段，但没有自己的堆栈，使用与调用它的应用程序相同的堆栈模式；一个DLL在内存中只有一个实例；DLL实现了代码封装性；DLL的编制与具体的编程语言及编译器无关。

　　在Win32环境中，每个进程都复制了自己的读/写全局变量。

如果想要与其它进程共享内存，必须使用内存映射文件或者声明一个共享数据段。

DLL模块需要的堆栈内存都是从运行进程的堆栈中分配出来的。

Windows在加载DLL模块时将进程函数调用与DLL文件的导出函数相匹配。

Windows操作系统对DLL的操作仅仅是把DLL映射到需要它的进程的虚拟地址空间里去。

DLL函数中的代码所创建的任何对象（包括变量）都归调用它的线程或进程所有。

调用方式

　　1、静态调用方式：

由编译系统完成对DLL的加载和应用程序结束时DLL卸载的编码（如还有其它程序使用该DLL，则Windows对DLL的应用记录减1，直到所有相关程序都结束对该DLL的使用时才释放它，简单实用，但不够灵活，只能满足一般要求。

　　隐式的调用：

需要把产生动态连接库时产生的.LIB文件加入到应用程序的工程中，想使用DLL中的函数时，只须说明一下。

隐式调用不需要调用LoadLibrary（）和FreeLibrary（）。

程序员在建立一个DLL文件时，链接程序会自动生成一个与之对应的LIB导入文件。

该文件包含了每一个DLL导出函数的符号名和可选的标识号，但是并不含有实际的代码。

LIB文件作为DLL的替代文件被编译到应用程序项目中。

　　当程序员通过静态链接方式编译生成应用程序时，应用程序中的调用函数与LIB文件中导出符号相匹配，这些符号或标识号进入到生成的EXE文件中。

LIB文件中也包含了对应的DLL文件名（但不是完全的路径名），链接程序将其存储在EXE文件内部。

　　当应用程序运行过程中需要加载DLL文件时，Windows根据这些信息发现并加载DLL，然后通过符号名或标识号实现对DLL函数的动态链接。

所有被应用程序调用的DLL文件都会在应用程序EXE　文件加载时被加载在到内存中。

可执行程序链接到一个包含DLL输出函数信息的输入库文件（.LIB文件）。

操作系统在加载使用可执行程序时加载DLL。

可执行程序直接通过函数名调用DLL的输出函数，调用方法和程序内部其它的函数是一样的。

　　2、动态调用方式：

是由编程者用API函数加载和卸载DLL来达到调用DLL的目的，使用上较复杂，但能更加有效地使用内存，是编制大型应用程序时的重要方式。

　　显式的调用：

是指在应用程序中用LoadLibrary或MFC提供的AfxLoadLibrary显式的将自己所做的动态连接库调进来，动态连接库的文件名即是上面两个函数的参数，再用GetProcAddress（）获取想要引入的函数。

自此，你就可以象使用如同本应用程序自定义的函数一样来调用此引入函数了。

在应用程序退出之前，应该用FreeLibrary或MFC提供的AfxFreeLibrary释放动态连接库。

直接调用Win32的LoadLibary函数，并指定DLL的路径作为参数。

LoadLibary返回HINSTANCE参数，应用程序在调用GetProcAddress函数时使用这一参数。

GetProcAddress函数将符号名或标识号转换为DLL内部的地址。

程序员可以决定DLL文件何时加载或不加载，显式链接在运行时决定加载哪个DLL文件。

使用DLL的程序在使用之前必须加载（LoadLibrary）加载DLL从而得到一个DLL模块的句柄，然后调用GetProcAddress函数得到输出函数的指针，在退出之前必须卸载DLL（FreeLibrary）。

　　Windows将遵循下面的搜索顺序来定位DLL：

1.包含EXE文件的目录

2.进程的当前工作目录

3.Windows系统目录

4.Windows目录

5.列在Path环境变量中的一系列目录

　　MFC中的DLL

∙Non-MFCDLL：

指的是不用MFC的类库结构，直接用C语言写的DLL，其输出的函数一般用的是标准C接口，并能被非MFC或MFC编写的应用程序所调用。

∙RegularDLL：

和下述的ExtensionDLLs一样，是用MFC类库编写的。

明显的特点是在源文件里有一个继承CWinApp的类。

其又可细分成静态连接到MFC和动态连接到MFC上的。

　　静态连接到MFC的动态连接库只被VC的专业版和企业版所支持。

该类DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。

输入函数有如下形式：

　　extern"C"EXPORTYourExportedFunction（）;

　　如果没有extern"C"修饰，输出函数仅仅能从C++代码中调用。

　　DLL应用程序从CWinApp派生，但没有消息循环。

　　动态链接到MFC的规则DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。

但是，所有从DLL输出的函数应该以如下语句开始：

AFX_MANAGE_STATE（AfxGetStaticModuleState（））

　　此语句用来正确地切换MFC模块状态。

　　RegularDLL能够被所有支持DLL技术的语言所编写的应用程序所调用。

在这种动态连接库中，它必须有一个从CWinApp继承下来的类，DLLMain函数被MFC所提供，不用自己显式的写出来。

　　ExtensionDLL：

用来实现从MFC所继承下来的类的重新利用，也就是说，用这种类型的动态连接库，可以用来输出一个从MFC所继承下来的类。

它输出的函数仅可以被使用MFC且动态链接到MFC的应用程序使用。

可以从MFC继承你所想要的、更适于你自己用的类，并把它提供给你的应用程序。

你也可随意的给你的应用程序提供MFC或MFC继承类的对象指针。

ExtensionDLL使用MFC的动态连接版本所创建的，并且它只被用MFC类库所编写的应用程序所调用。

ExtensionDLLs和RegularDLLs不一样，它没有从CWinApp继承而来的类的对象，所以，你必须为自己DLLMain函数添加初始化代码和结束代码。

　　和规则DLL相比，有以下不同：

　　1、它没有从CWinApp派生的对象；

　　2、它必须有一个DLLMain函数；

　　3、DLLMain调用AfxInitExtensionModule函数，必须检查该函数的返回值，如果返回0，DLLMmain也返回0；

　　4、如果它希望输出CRuntimeClass类型的对象或者资源，则需要提供一个初始化函数来创建一个CDynLinkLibrary对象。

并且，有必要把初始化函数输出；

　　5、使用扩展DLL的MFC应用程序必须有一个从CWinApp派生的类，而且，一般在InitInstance里调用扩展DLL的初始化函数。

DLL入口函数

　　1、每一个DLL必须有一个入口点，DLLMain是一个缺省的入口函数。

DLLMain负责初始化和结束工作，每当一个新的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调用DLLMain。

但是，使用TerminateProcess或TerminateThread结束进程或者线程，不会调用DLLMain。

　　DLLMain的函数原型：

BOOLAPIENTRYDLLMain（HANDLEhModule,DWORDul_reason_for_call,LPVOID

lpReserved）

{

　　switch（ul_reason_for_call）

　　{

　　caseDLL_PROCESS_ATTACH:

　　.......

　　caseDLL_THREAD_ATTACH:

　　.......

　　caseDLL_THREAD_DETACH:

　　.......

　　caseDLL_PROCESS_DETACH:

　　.......

　　returnTRUE;

　　}

}

　　参数：

　　hMoudle：

是动态库被调用时所传递来的一个指向自己的句柄（实际上，它是指向_DGROUP段的一个选择符）；

　　ul_reason_for_call：

是一个说明动态库被调原因的标志。

当进程或线程装入或卸载动态连接库的时候，操作系统调用入口函数，并说明动态连接库被调用的原因。

它所有的可能值为：

　　DLL_PROCESS_ATTACH:

进程被调用；

　　DLL_THREAD_ATTACH:

线程被调用；

　　DLL_PROCESS_DETACH:

进程被停止；

　　DLL_THREAD_DETACH:

线程被停止；

　　lpReserved：

是一个被系统所保留的参数；

　　2、_DLLMainCRTStartup

　　为了使用"C"运行库（CRT，CRuntimeLibrary）的DLL版本（多线程），一个DLL应用程序必须指定_DLLMainCRTStartup为入口函数，DLL的初始化函数必须是DLLMain。

　　_DLLMainCRTStartup完成以下任务：

当进程或线程捆绑（Attach）到DLL时为"C"运行时的数据（CRuntimeData）分配空间和初始化并且构造全局"C++"对象，当进程或者线程终止使用DLL（Detach）时，清理CRuntimeData并且销毁全局"C++"对象。

它还调用DLLMain和RawDLLMain函数。

　　RawDLLMain在DLL应用程序动态链接到MFCDLL时被需要，但它是静态链接到DLL应用程序的。

在讲述状态管理时解释其原因。

　　关于调用约定

　　动态库输出函数的约定有两种：

调用约定和名字修饰约定。

　　1）调用约定（Callingconvention）：

决定函数参数传送时入栈和出栈的顺序，由调用者还是被调用者把参数弹出栈，以及编译器用来识别函数名字的修饰约定。

　　函数调用约定有多种，这里简单说一下：

　　1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。

在32位的VC++5.0中PASCAL调用约定不再被支持（实际上它已被定义为__stdcall。

除了__pascal外，__fortran和__syscall也不被支持），取而代之的是__stdcall调用约定。

两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。

　　_stdcall是Pascal程序的缺省调用方式，通常用于Win32API中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。

VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。

　　2、C调用约定（即用__cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。

对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。

另外，在函数名修饰约定方面也有所不同。

　　_cdecl是C和C++程序缺省的调用方式。

每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。

函数采用从右到左的压栈方式。

VC将函数编译后会在函数名前面加上下划线前缀。

它是MFC缺省调用约定。

　　3、__fastcall调用约定是"人"如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。

　　_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。

　　4、thiscall仅仅应用于"C++"成员函数。

this指针存放于CX寄存器，参数从右到左压。

thiscall不是关键词，因此不能被程序员指定。

　　5、nakedcall采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。

　　nakedcall不产生这样的代码。

nakedcall不是类型修饰符，故必须和_declspec共同使用。

　　关键字__stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的Setting...\C/C++\CodeGeneration项选择。

当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。

它们对应的命令行参数分别为/Gz、/Gd和/Gr。

缺省状态为/Gd，即__cdecl。

　　要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。

还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为__stdcall。

使用WINAPI宏可以创建自己的APIs。

　　2）名字修饰约定

　　1、修饰名（Decorationname）

　　"C"或者"C++"函数在内部（编译和链接）通过修饰名识别。

修饰名是编译器在编译函数定义或者原型时生成的字符串。

有些情况下使用函数的修饰名是必要的，如在模块定义文件里头指定输出"C++"重载函数、构造函数、析构函数，又如在汇编代码里调用"C""或"C++"函数等。

　　修饰名由函数名、类名、调用约定、返回类型、参数等共同决定。

　　2、名字修饰约定随调用约定和编译种类（C或C++）的不同而变化。

函数名修饰约定随编译种类和调用约定的不同而不同，下面分别说明。

　　a、C编译时函数名修饰约定规则：

　　__stdcall调用约定在输出函数名前加上一个下划线前缀，后面加上一个"@"符号和其参数的字节数，格式为_functionname@number。

　　__cdecl调用约定仅在输出函数名前加上一个下划线前缀，格式为_functionname。

　　__fastcall调用约定在输出函数名前加上一个"@"符号，后面也是一个"@"符号和其参数的字节数，格式为@functionname@number。

　　它们均不改变输出函数名中的字符大小写，这和PASCAL调用约定不同，PASCAL约定输出的函数名无任何修饰且全部大写。

　　b、C++编译时函数名修饰约定规则：

　　__stdcall调用约定：

　　1、以"?

"标识函数名的开始，后跟函数名；

　　2、函数名后面以"@@YG"标识参数表的开始，后跟参数表；

　　3、参数表以代号表示：

　　X——void，

　　D——char，

　　E——unsignedchar，

　　F——short，

　　H——int，

　　I——unsignedint，

　　J——long，

　　K——unsignedlong，

　　M——float，

　　N——double，

　　_N——bool，

　　....

　　PA——表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以"0"代替，一个"0"代表一次重复；

　　4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前；

　　5、参数表后以"@Z"标识整个名字的结束，如果该函数无参数，则以"Z"标识结束。

　　其格式为"?

functionname@@YG*****@Z"或"?

functionname@@YG*XZ"，

　　例如

intTest1（char*var1,unsignedlong）-----“?

Test1@@YGHPADK@Z”

　　　　　voidTest2（）　　　　　　　　　　　-----“?

Test2@@YGXXZ”

　　__cdecl调用约定：

　　规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YA"。

　　__fastcall调用约定：

　　规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的"@@YG"变为"@@YI"。

　　VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用。

　　关于DLL的函数

　　动态链接库中定义有两种函数：

导出函数（exportfunction）和内部函数（internalfunction）。

导出函数可以被其它模块调用，内部函数在定义它们的DLL程序内部使用。

　　输出函数的方法有以下几种：

　　1、传统的方法

　　在模块定义文件的EXPORT部分指定要输入的函数或者变量。

语法格式如下：

entryname[=internalname][@ordinal[NONAME]][DATA][PRIVATE]

　　其中：

　　entryname是输出的函数或者数据被引用的名称；

　　internalname同entryname;

　　@ordinal表示在输出表中的顺序号（index）；

　　NONAME仅仅在按顺序号输出时被使用（不使用entryname）；

　　DATA表示输出的是数据项，使用DLL输出数据的程序必须声明该数据项为_declspec（DLLimport）。

　　上述各项中，只有entryname项是必须的，其他可以省略。

　　对于"C"函数来说，entryname可以等同于函数名；但是对"C++"函数（成员函数、非成员函数）来说，entryname是修饰名。

可以从.map映像文件中得到要输出函数的修饰名，或者使用DUMPBIN/SYMBOLS得到，然后把它们写在.def文件的输出模块。

DUMPBIN是VC提供的一个工具。

　　如果要输出一个"C++"类，则把要输出的数据和成员的修饰名都写入.def模块定义文件。

　　2、在命令行输出

对链接程序LINK指定/EXPORT命令行参数，输出有关函数。

　　3、使用MFC提供的修饰符号_declspec（DLLexport）

　　在要输出的函数、类、数据的声明前加上_declspec（DLLexport）修饰符表示输出。

__declspec（DLLexport）在C调用约定、C编译情况下可以去掉输出函数名的下划线前缀。

extern"C"使得在C++中使用C编译方式成为可能。

在"C++"下定义"C"函数需要加extern"C"关键词。

用extern"C"来指明该函数使用C编译方式。

输出的"C"函数可以从"C"代码里调用。

　　例如，在一个C++文件中，有如下函数：

extern"C"{void　__declspec（DLLexport）__cdeclTest（intvar）;}

　　其输出函数名为：

Test

　　MFC提供了一些宏，就有这样的作用。

AFX_CLASS_IMPORT：

__declspec（DLLexport）

AFX_API_IMPORT：

__declspec（DLLexport）

AFX_DATA_IMPORT：

__declspec（DLLexport）

AFX_CLASS_EXPORT：

__declspec（DLLexport）

AFX_API_EXPORT：

__declspec（DLLexport）

AFX_DATA_EXPORT：

__declspec（DLLexport）

AFX_EXT_CLASS：

#ifdef_AFXEXT

　　　　　　AFX_CLASS_EXPORT

　　　　　#else

　　　　　　AFX_CLASS_IMPORT

AFX_EXT_API：

#ifdef_AFXEXT

　　　　　　AFX_API_EXPORT

　　　　#else

　　　　　　AFX_API_IMPORT

AFX_EXT_DATA：

#ifdef_AFXEXT

　　　　　　　AFX_DATA_EXPORT

　　　　#else

　　　　　　　AFX_DATA_IMPORT

　　像AFX_EXT_CLASS这样的宏，如果用于DLL应用程序的实现中，则表示输出（因为_AFX_EXT被定义，通常是在编译器的标识参数中指定该选项/D_AFX_EXT）；如果用于使用DLL的应用程序中，则表示输入（_AFX_EXT没有定义）。

　　要输出整个的类，对类使用_declspec（_DLLexpot）；要输出类的成员函数，则对该函数使用_declspec（_DLLexport）。

如：

classAFX_EXT_CLASSCTextDoc:

publicCDocument

{

　　…

}

extern"C"AFX_EXT_APIvoid