Win32下动态链接库DLL编程原理.docx

Win32下动态链接库DLL编程原理.docx

《Win32下动态链接库DLL编程原理.docx》由会员分享，可在线阅读，更多相关《Win32下动态链接库DLL编程原理.docx（9页珍藏版）》请在冰豆网上搜索。

Win32下动态链接库DLL编程原理

主题：

DLL是Windows最重要的组成要素，Windows中的许多新功能、新特性都是通过DLL来

实现的，因此掌握它、应用它是非常重要的。

动态链接库不仅可以作为一个运行模块，包括函数代码，而且可以包含程序以外的任何数据

或资源（位图、图标等等）。

动态链接库就是给应用程序提供函数或者资源。

DLL是一种磁盘文件（通常带有DLL扩展名），它由全局数据、服务函数和资源组成，

在运行时被系统加载到进程的虚拟空间中，成为调用进程的一部分。

在运行时，只有当EXE

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

每个进程都复

制了自己的读/写全局变量。

如果想要与其它进程共享内存，必须使用内存映射文件或者声

明一个共享数据段。

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

DLL文件中包含一个导出函数表。

这些导出函数由它们的符号名和称为标识号的整数与外界联系起来。

导入导出函数：

在DLL代码中，必须像下面这样明确声明导出函数：

__declspec（dllexport）intMyFunction（intn）;

但也可以在模块定义（DEF）文件中列出导出函数，不过这样做常常引起更多的麻烦。

在应用程序方面，要

求像下面这样明确声明相应的输入函数：

__declspec（dllimport）intMyFuncition（intn）;（这是隐式链接dll）

仅有导入和导出声明并不能使应用程序内部的函数调用链接到相应的DLL文件上。

应用程序的项目必须为

链接程序指定所需的输入库（LIB文件）。

而且应用程序事实上必须至少包含一个对DLL函数的调用。

隐式链接和显式链接dll

显式：

typedefdouble（SQRTPROC）（double）;

HINSTANCEhInstance;//设置全局变量用于存储DLL句柄

SQRTPROC*pFunction;第二个变量ShowMe是指向DLL,库中函数的指针

VERIFY（hInstance=:

:

LoadLibrary（"c:

//winnt//system32//mydll.dll"））;

VERIFY（pFunction=（SQRTPROC*）:

:

GetProcAddress（hInstance,"SquareRoot"））;

doubled=（*pFunction）（81.0）;//调用该DLL函数

隐式：

程序员通过静态链接方式编译生成应用程序时，应用程序中的调用函数与LIB文件中导出符号相

匹配，这些符号或标识号进入到生成的EXE文件中.

隐式链接和显式链接dll的区别：

在隐式链接方式中，所有被应用程序调用的DLL文件都会在应用程序EXE文件加载时被加载在到内存中；但

如果采用显式链接方式，程序员可以决定DLL文件何时加载或不加载。

DLLMAIN函数:

当Windows加载DLL模块时调用这一函数。

系统首先调用全局对象的构造函数，然后调用全局函数DLLMain。

DLLMain函数不仅在将DLL链接加载到进程时被调用，在DLL模块与进程分离时（以及其它时候）也被调用。

进程中的每个DLL模块被全局唯一的32字节的HINSTANCE句柄标识。

进程自己还有一个HINSTANCE句柄。

所

有这些模块句柄都只有在特定的进程内部有效，它们代表了DLL或EXE模块在进程虚拟空间中的起始地址。

寻找DLL的路径：

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

1．包含EXE文件的目录，

2．进程的当前工作目录，

3．Windows系统目录，

4．Windows目录，

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

要点：

一：

DLL文件的省缺名称是与工程名一致的（也是在.DEF文件中LIBRARY之后的名字）,不要试图在制作完毕之后通

过简单的修改.DLL文件的文件名来改变它,这会导致使用该DLL的应用程序错误.

DLL中定义有两种函数:

导出函数（exportfunction）:

可以被其他模块调用

内部函数（internalfunction）:

只能在DLL内部使用

基于MFC的DLL不适用与制作读取二进制文件的DLL（不易移植,无法正确读取与DOS应用程序共享的二进制文件）

基于API的DLL可以正确读取在DOS环境中创建的二进制文件.

纯标准函数dll可以在很多平台使用！

（移植性最强）

为了让其它语言使用：

除非你绝对需要使用C++编码，否则我还是推荐使用C来写DLL。

VC下的DLL类型：

Non-MFCDLL:

指的是不用MFC的类库结构，直接用C语言写的DLL，其输出的函数一

般用的是标准C接口，并能被非MFC或MFC编写的应用程序所调用。

LL，

RegularDLL:

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

明显的特点是

在源文件里有一个继承CWinApp的类。

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

的。

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

ExtensionDLL:

用来实现从MFC所继承下来的类的重新利用，也就是说，用这种类

型的动态连接库，可以用来输出一个从MFC所继承下来的类。

ExtensionDLL使用MFC的

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

用来实现从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类型的对象或者资源（Resources），则需要提供一个初始化函数来创建一个CDynLinkLibrary对象。

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

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

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

AFX_MANAGE_STATE（AfxGetStaticModuleState（））

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

在制作DLL时,VC++对函数的省缺声明是"__cedcl",也就是说,如果你在声明你的函数时不作特殊声明的话,你

制作的DLL将只能被C/C++调用,如果你想用其他开发语言（比如VB5.0）调用它就会报错,即使调用方法完全正确.

二：

声明类型详解：

三：

制DLL所要的文件：

模块定义文件（.DEF）是由一个或者多个用于描述DLL属性的模块语句组成

的文本文件,每个.DEF文件至少必须包含以下模块定义语句:

第一个语句必须是LIBRARY语句,指出DLL的名字。

EXPORTS语句列出被导出函数的名字。

可以使用DESCRIPTION语句描述DLL的用途（此句可选）。

";"对一行进行注释（可选）

实现文件（.cpp文件为例）

实现入口表函数的.cpp文件中,包含DLL入口点处理的API函数和导出函数的代码。

四：

介绍Non-MFCDLLs的编写方法:

如果用VC的向导那就很方便了！

写法：

BOOLAPIENTRYDllMain（HANDLEhModule,DWORDul_reason_for_call,

LPVOIDlpReserved）

{

switch（ul_reason_for_call）{

caseDLL_PROCESS_ATTACH:

.......

caseDLL_THREAD_ATTACH:

.......

caseDLL_THREAD_DETACH:

.......

caseDLL_PROCESS_DETACH:

.......

}

returnTRUE;

}

每一个DLL必须有一个入口点，这就象我们用C编写的应用程序一样，

必须有一个WINMAIN函数一样。

在这个示例中，DllMain是一个缺省的入口函数，你不需要编写自己

的DLL入口函数，并用linker的命令行的参数开关/ENTRY声明。

用这个缺

省的入口函数就能使动态连接库被调用时得到正确的初始化，当然了，你

不要在初始化的时候填写使系统崩溃的代码了。

参数中，hMoudle是动态库被调用时所传递来的一个指向自己的句柄

（实际上，它是指向_DGROUP段的一个选择符）

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

当进程或线程

装入或卸载动态连接库的时候，操作系统调用入口函数，并说明动态连接库

被调用的原因。

它所有的可能值为：

DLL_PROCESS_ATTACH:

进程被调用

DLL_THREAD_ATTACH:

线程被调用

DLL_PROCESS_DETACH:

进程被停止

DLL_THREAD_DETACH:

线程被停止

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

入口函数已经写了，余下的也不难，你可以在文件中加入你所想要输

出的函数或变量或c++类等

五：

纯资源DLL的编写

纯资源的DLL就是只包含资源的DLL，例如：

图标，位图，字符串，声音，

视频，对话框等。

使用纯资源DLL可以节约可执行文件的大小，可以被所有的应

用程序所共享，从而提高系统性能。

纯资源DLL的编写比普通的DLL要简单的多，

首先创建一个WIN32DLL工程，不是MFC的DLL，然后创建一个资源文件*.RC，添

加到资源DLL的工程中去。

然后添加一个初始化DLL的原文件。

#include

extern"C"

BOOLWINAPIDllMain（HINSTANCEhInstance,DWORDdwReason,LPVOID）

{

   return1;

}

这是纯资源DLL所必须需的代码，保存这个文件为*.CPP。

编译这个资源DLL。

在应用程序显示的调用这个DLL，使用LoadLibrary函数装入资源DLL，

FindResource和LoadResource来装入各种资源，或者使用下列的特定的资源装入函数：

FormatMessage

LoadAccelerators

LoadBitmap

LoadCursor

LoadIcon

LoadMenu

LoadString

当资源使用结束，你的应用程序须调用FreeLibrary函数来释放资源。

下面就讲一下如何调用编写好的资源DLL

首先在应用程序中声明一个DLL的句柄，HINSTANCEm_hLibrary;在OnCreate（）函数

中调用LoadLirbrary（）,在OnDestory（）中调用FreeLibrary（）。

下载一个工程文件看一看，就什么都搞定了。

关于约定：

六、关于约定：

（此要点六zzrivershan（原作））

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

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

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++调用.

   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_APIvoidWINAPIInitMYDLL（）;

 这几种方法中，最好采用第三种，方便好用；其次是第一种，如果按顺序号输出，调用效率会高些；最次是第二种。