VC++动态链接库DLL编程.docx

VC++动态链接库DLL编程.docx

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

VC++动态链接库DLL编程

VC++动态链接库（DLL）编程

VC++ 动态链接库 （DLL） 编程

（一）

――理解库

作者：

 宋宝华   e-mail:

 21cnbao @ 

1. 概论

先来阐述一下 DLL（DynamicLinkableLibrary） 的概念，你可以简单的把 DLL 看成一种仓库，它提供给你一些可以直接拿来用的变量、函数或类。

在仓库的发展史上经历了“无库－静态链接库－动态链接库”的时代。

静态链接库与动态链接库都是共享代码的方式，如果采用静态链接库，则无论你愿不愿意， lib 中的指令都被直接包含在最终生成的 EXE 文件中了。

但是若使用 DLL ，该 DLL 不必被包含在最终 EXE 文件中， EXE 文件执行时可以“动态”地引用和卸载这个与 EXE 独立的 DLL 文件。

静态链接库和动态链接库的另外一个区别在于静态链接库中不能再包含其他的动态链接库或者静态库，而在动态链接库中还可以再包含其他的动态或静态链接库。

对动态链接库，我们还需建立如下概念：

（ 1 ） DLL 的编制与具体的编程语言及编译器无关

  只要遵循约定的 DLL 接口规范和调用方式，用各种语言编写的 DLL 都可以相互调用。

譬如 Windows 提供的系统 DLL （其中包括了 Windows 的 API ），在任何开发环境中都能被调用，不在乎其是 VisualBasic 、 VisualC++ 还是 Delphi 。

（ 2 ）动态链接库随处可见

我们在 Windows 目录下的 system32 文件夹中会看到 kernel32.dll 、 user32.dll 和gdi32.dll ， windows 的大多数 API 都包含在这些 DLL 中。

 kernel32.dll 中的函数主要处理内存管理和进程调度； user32.dll 中的函数主要控制用户界面； gdi32.dll 中的函数则负责图形方面的操作。

一般的程序员都用过类似 MessageBox 的函数，其实它就包含在 user32.dll 这个动态链接库中。

由此可见 DLL 对我们来说其实并不陌生。

（3）VC 动态链接库的分类

VisualC++ 支持三种 DLL ，它们分别是 Non-MFCDLL （非 MFC 动态库）、MFCRegularDLL （ MFC 规则 DLL ）、 MFCExtensionDLL （ MFC 扩展 DLL）。

非 MFC 动态库不采用 MFC 类库结构，其导出函数为标准的 C 接口，能被非MFC 或 MFC 编写的应用程序所调用； MFC 规则 DLL 包含一个继承自 CWinApp的类，但其无消息循环； MFC 扩展 DLL 采用 MFC 的动态链接版本创建，它只能被用 MFC 类库所编写的应用程序所调用。

由于本文篇幅较长，内容较多，势必需要先对阅读本文的有关事项进行说明，下面以问答形式给出。

问：

 本文主要讲解什么内容？

答：

 本文详细介绍了 DLL 编程的方方面面，努力学完本文应可以对 DLL 有较全面的掌握，并能编写大多数 DLL 程序。

问：

 如何看本文？

答：

 本文每一个主题的讲解都附带了源代码例程，可以随文下载（每个工程都经 WINRAR 压缩）。

所有这些例程都由笔者编写并在 VC++6.0 中调试通过。

当然看懂本文不是读者的最终目的，读者应亲自动手实践才能真正掌握 DLL的奥妙。

问：

 学习本文需要什么样的基础知识？

答：

 如果你掌握了 C ，并大致掌握了 C++ ，了解一点 MFC 的知识，就可以轻松地看懂本文。

2. 静态链接库

对静态链接库的讲解不是本文的重点，但是在具体讲解 DLL 之前，通过一个静态链接库的例子可以快速地帮助我们建立“库”的概念。

图 1 建立一个静态链接库

如图 1 ，在 VC++6.0 中 new 一个名称为 libTest 的 staticlibrary 工程（ 单击此处下载本工程 ），并新建 lib.h 和 lib.cpp 两个文件， lib.h 和 lib.cpp 的源代码如下：

// 文件：

 lib.h

#ifndefLIB_H

#defineLIB_H

extern"C"intadd（intx,inty）; 　　　 // 声明为 C 编译、连接方式的外部函数

#endif

// 文件：

 lib.cpp

#include"lib.h"

intadd（intx,inty）

{

       returnx+y;

}

编译这个工程就得到了一个 .lib 文件，这个文件就是一个函数库，它提供了 add 的功能。

将头文件和 .lib 文件提交给用户后，用户就可以直接使用其中的 add 函数了。

标准 TurboC2.0 中的 C 库函数（我们用来的 scanf 、 printf 、 memcpy 、 strcpy 等）就来自这种静态库。

下面来看看怎么使用这个库，在 libTest 工程所在的工作区内 new 一个 libCall工程。

 libCall 工程仅包含一个 main.cpp 文件，它演示了静态链接库的调用方法，其源代码如下：

#include

#include"..\lib.h"

#pragmacomment（lib,"..\\debug\\libTest.lib"） 　 // 指定与静态库一起连接

intmain（intargc,char*argv[]）

{

   printf（"2+3=%d",add（2,3））;

}

静态链接库的调用就是这么简单，或许我们每天都在用，可是我们没有明白这个概念。

代码中 #pragmacomment（lib,"..\\debug\\libTest.lib"） 的意思是指本文件生成的 .obj 文件应与 libTest.lib 一起连接。

如果不用 #pragmacomment 指定，则可以直接在 VC++ 中设置，如图 2 ，依次选择 tools 、 options 、 directories 、 libraryfiles菜单或选项，填入库文件路径。

图 2 中加红圈的部分为我们添加的 libTest.lib 文件的路径。

图 2 在 VC 中设置库文件路径

这个静态链接库的例子至少让我们明白了库函数是怎么回事，它们是哪来的。

我们现在有下列模糊认识了：

（ 1 ）库不是个怪物，编写库的程序和编写一般的程序区别不大，只是库不能单独执行；

（ 2 ）库提供一些可以给别的程序调用的东东，别的程序要调用它必须以某种方式指明它要调用之。

以上从静态链接库分析而得到的对库的懵懂概念可以直接引申到动态链接库中，动态链接库与静态链接库在编写和调用上的不同体现在库的外部接口定义及调用方式略有差异。

3. 库的调试与查看

在具体进入各类 DLL 的详细阐述之前，有必要对库文件的调试与查看方法进行一下介绍，因为从下一节开始我们将面对大量的例子工程。

由于库文件不能单独执行，因而在按下 F5 （开始 debug 模式执行）或 CTRL+F5 （运行）执行时，其弹出如图 3 所示的对话框，要求用户输入可执行文件的路径来启动库函数的执行。

这个时候我们输入要调用该库的 EXE 文件的路径就可以对库进行调试了，其调试技巧与一般应用工程的调试一样。

图 3 库的调试与“运行”

通常有比上述做法更好的调试途径，那就是将库工程和应用工程（调用库的工程）放置在同一 VC 工作区，只对应用工程进行调试，在应用工程调用库中函数的语句处设置断点，执行后按下 F11 ，这样就单步进入了库中的函数。

第 2 节中的 libTest 和 libCall 工程就放在了同一工作区，其工程结构如图 4 所示。

图 4 　把库工程和调用库的工程放入同一工作区进行调试

上述调试方法对静态链接库和动态链接库而言是一致的。

所以本文提供下载的所有源代码中都包含了库工程和调用库的工程，这二者都被包含在一个工作区内，这是笔者提供这种打包下载的用意所在。

动态链接库中的导出接口可以使用 VisualC++ 的 Depends 工具进行查看，让我们用 Depends 打开系统目录中的 user32.dll ，看到了吧？

红圈内的就是几个版本的MessageBox 了！

原来它真的在这里啊，原来它就在这里啊！

图 5 　用 Depends 查看 DLL

当然 Depends 工具也可以显示 DLL 的层次结构，若用它打开一个可执行文件则可以看出这个可执行文件调用了哪些 DLL 。

好，让我们正式进入动态链接库的世界，先来看看最一般的 DLL ，即非 MFCDLL 。

VC++动态链接库（DLL）编程

（二）－－非MFCDLL

4.非MFCDLL

4.1一个简单的DLL

　　第2节给出了以静态链接库方式提供add函数接口的方法，接下来我们来看看怎样用动态链接库实现一个同样功能的add函数。

　　如图6，在VC++中new一个Win32Dynamic-LinkLibrary工程dllTest（单击此处下载本工程附件）。

注意不要选择MFCAppWizard（dll），因为用MFCAppWizard（dll）建立的将是第5、6节要讲述的MFC动态链接库。

图6建立一个非MFCDLL

　　在建立的工程中添加lib.h及lib.cpp文件，源代码如下：

/*文件名：

lib.h　*/

#ifndefLIB_H

#defineLIB_H

extern"C"int__declspec（dllexport）add（intx,inty）;

#endif

/*文件名：

lib.cpp　*/

#include"lib.h"

intadd（intx,inty）

{

returnx+y;

}

与第2节对静态链接库的调用相似，我们也建立一个与DLL工程处于同一工作区的应用工程dllCall，它调用DLL中的函数add，其源代码如下：

#include

#include

typedefint（*lpAddFun）（int,int）;//宏定义函数指针类型

intmain（intargc,char*argv[]）

{

HINSTANCEhDll;//DLL句柄 

lpAddFunaddFun;//函数指针

hDll=LoadLibrary（"..\\Debug\\dllTest.dll"）;

if（hDll!

=NULL）

{

addFun=（lpAddFun）GetProcAddress（hDll,"add"）;

if（addFun!

=NULL）

{

intresult=addFun（2,3）;

printf（"%d",result）;

}

FreeLibrary（hDll）;

}

return0;

}

　　分析上述代码，dllTest工程中的lib.cpp文件与第2节静态链接库版本完全相同，不同在于lib.h对函数add的声明前面添加了__declspec（dllexport）语句。

这个语句的含义是声明函数add为DLL的导出函数。

DLL内的函数分为两种：

（1）DLL导出函数，可供应用程序调用；

（2）DLL内部函数，只能在DLL程序使用，应用程序无法调用它们。

　　而应用程序对本DLL的调用和对第2节静态链接库的调用却有较大差异，下面我们来逐一分析。

　　首先，语句typedefint（*lpAddFun）（int,int）定义了一个与add函数接受参数类型和返回值均相同的函数指针类型。

随后，在main函数中定义了lpAddFun的实例addFun；

　　其次，在函数main中定义了一个DLLHINSTANCE句柄实例hDll，通过Win32Api函数LoadLibrary动态加载了DLL模块并将DLL模块句柄赋给了hDll；

　　再次，在函数main中通过Win32Api函数GetProcAddress得到了所加载DLL模块中函数add的地址并赋给了addFun。

经由函数指针addFun进行了对DLL中add函数的调用；

　　最后，应用工程使用完DLL后，在函数main中通过Win32Api函数FreeLibrary释放了已经加载的DLL模块。

　　通过这个简单的例子，我们获知DLL定义和调用的一般概念：

（1）DLL中需以某种特定的方式声明导出函数（或变量、类）；

（2）应用工程需以某种特定的方式调用DLL的导出函数（或变量、类）。

　　下面我们来对“特定的方式进行”阐述。

4.2声明导出函数

　　DLL中导出函数的声明有两种方式：

一种为4.1节例子中给出的在函数声明中加上__declspec（dllexport），这里不再举例说明；另外一种方式是采用模块定义（.def）文件声明，.def文件为链接器提供了有关被链接程序的导出、属性及其他方面的信息。

　　下面的代码演示了怎样同.def文件将函数add声明为DLL导出函数（需在dllTest工程中添加lib.def文件）：

;lib.def:

导出DLL函数

LIBRARYdllTest

EXPORTS

add@1

.def文件的规则为：

（1）LIBRARY语句说明.def文件相应的DLL；

（2）EXPORTS语句后列出要导出函数的名称。

可以在.def文件中的导出函数名后加@n，表示要导出函数的序号为n（在进行函数调用时，这个序号将发挥其作用）；

　　（3）.def文件中的注释由每个注释行开始处的分号（;）指定，且注释不能与语句共享一行。

　　由此可以看出，例子中lib.def文件的含义为生成名为“dllTest”的动态链接库，导出其中的add函数，并指定add函数的序号为1。

4.3DLL的调用方式

　　在4.1节的例子中我们看到了由“LoadLibrary-GetProcAddress-FreeLibrary”系统Api提供的三位一体“DLL加载-DLL函数地址获取-DLL释放”方式，这种调用方式称为DLL的动态调用。

　　动态调用方式的特点是完全由编程者用API函数加载和卸载DLL，程序员可以决定DLL文件何时加载或不加载，显式链接在运行时决定加载哪个DLL文件。

　　与动态调用方式相对应的就是静态调用方式，“有动必有静”，这来源于物质世界的对立统一。

“动与静”，其对立与统一竟无数次在技术领域里得到验证，譬如静态IP与DHCP、静态路由与动态路由等。

从前文我们已经知道，库也分为静态库与动态库DLL，而想不到，深入到DLL内部，其调用方式也分为静态与动态。

“动与静”，无处不在。

《周易》已认识到有动必有静的动静平衡观，《易．系辞》曰：

“动静有常，刚柔断矣”。

哲学意味着一种普遍的真理，因此，我们经常可以在枯燥的技术领域看到哲学的影子。

　　静态调用方式的特点是由编译系统完成对DLL的加载和应用程序结束时DLL的卸载。

当调用某DLL的应用程序结束时，若系统中还有其它程序使用该DLL，则Windows对DLL的应用记录减1，直到所有使用该DLL的程序都结束时才释放它。

静态调用方式简单实用，但不如动态调用方式灵活。

　　下面我们来看看静态调用的例子（单击此处下载本工程附件），将编译dllTest工程所生成的.lib和.dll文件拷入dllCall工程所在的路径，dllCall执行下列代码：

#pragmacomment（lib,"dllTest.lib"） 

//.lib文件中仅仅是关于其对应DLL文件中函数的重定位信息

extern"C"__declspec（dllimport）add（intx,inty）; 

intmain（intargc,char*argv[]）

{

intresult=add（2,3）; 

printf（"%d",result）;

return0;

}

　　由上述代码可以看出，静态调用方式的顺利进行需要完成两个动作：

（1）告诉编译器与DLL相对应的.lib文件所在的路径及文件名，#pragmacomment（lib,"dllTest.lib"）就是起这个作用。

　　程序员在建立一个DLL文件时，连接器会自动为其生成一个对应的.lib文件，该文件包含了DLL导出函数的符号名及序号（并不含有实际的代码）。

在应用程序里，.lib文件将作为DLL的替代文件参与编译。

（2）声明导入函数，extern"C"__declspec（dllimport）add（intx,inty）语句中的__declspec（dllimport）发挥这个作用。

　　静态调用方式不再需要使用系统API来加载、卸载DLL以及获取DLL中导出函数的地址。

这是因为，当程序员通过静态链接方式编译生成应用程序时，应用程序中调用的与.lib文件中导出符号相匹配的函数符号将进入到生成的EXE文件中，.lib文件中所包含的与之对应的DLL文件的文件名也被编译器存储在EXE文件内部。

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

这样，EXE将能直接通过函数名调用DLL的输出函数，就象调用程序内部的其他函数一样。

4.4DllMain函数

　　Windows在加载DLL的时候，需要一个入口函数，就如同控制台或DOS程序需要main函数、WIN32程序需要WinMain函数一样。

在前面的例子中，DLL并没有提供DllMain函数，应用工程也能成功引用DLL，这是因为Windows在找不到DllMain的时候，系统会从其它运行库中引入一个不做任何操作的缺省DllMain函数版本，并不意味着DLL可以放弃DllMain函数。

　　根据编写规范，Windows必须查找并执行DLL里的DllMain函数作为加载DLL的依据，它使得DLL得以保留在内存里。

这个函数并不属于导出函数，而是DLL的内部函数。

这意味着不能直接在应用工程中引用DllMain函数，DllMain是自动被调用的。

　　我们来看一个DllMain函数的例子（单击此处下载本工程附件）。

BOOLAPIENTRYDllMain（HANDLEhModule, 

DWORDul_reason_for_call, 

LPVOIDlpReserved

）

{

switch（ul_reason_for_call）

{

caseDLL_PROCESS_ATTACH:

printf（"\nprocessattachofdll"）;

break;

caseDLL_THREAD_ATTACH:

printf（"\nthreadattachofdll"）;

break;

caseDLL_THREAD_DETACH:

printf（"\nthreaddetachofdll"）;

break;

caseDLL_PROCESS_DETACH:

printf（"\nprocessdetachofdll"）;

break;

}

returnTRUE;

}

　　DllMain函数在DLL被加载和卸载时被调用，在单个线程启动和终止时，DLLMain函数也被调用，ul_reason_for_call指明了被调用的原因。

原因共有4种，即PROCESS_ATTACH、PROCESS_DETACH、THREAD_ATTACH和THREAD_DETACH，以switch语句列出。

来仔细解读一下DllMain的函数头BOOLAPIENTRYDllMain（HANDLEhModule,WORDul_reason_for_call,LPVOIDlpReserved）。

　　APIENTRY被定义为__stdcall，它意味着这个函数以标准Pascal的方式进行调用，也就是WINAPI方式；

　　进程中的每个DLL模块被全局唯一的32字节的HINSTANCE句柄标识，只有在特定的进程内部有效，句柄代表了DLL模块在进程虚拟空间中的起始地址。

在Win32中，HINSTANCE和HMODULE的值是相同的，这两种类型可以替换使用，这就是函数参数hModule的来历。

　　执行下列代码：

hDll=LoadLibrary（"..\\Debug\\dllTest.dll"）;

if（hDll!

=NULL）

{

addFun=（lpAddFun）GetProcAddress（hDll,MAKEINTRESOURCE

（1））;

//MAKEINTRESOURCE直接使用导出文件中的序号

if（addFun!

=NULL）

{

intresult=addFun（2,3）;

printf（"\ncalladdindll:

%d",result）;

}

FreeLibrary（hDll）;

}

　　我们看到输出顺序为：

　　processattachofdll

　　calladdindll:

5

　　processdetachofdll

　　这一输出顺序验证了DllMain被调用的时机。

　　代码中的GetProcAddress（hDll,MAKEINTRESOURCE

（1））值得留意，它直接通过.def文件中为add函数指定的顺序号访问add函数，具体体现在MAKEINTRESOURCE

（1），MAKEINTRESOURCE是一个通过序号获取函数名的宏，定义为（节选自winuser.h）：

#defineMAKEINTRESOURCEA（i）（LPSTR）（（DWORD）（（WORD）（i）））

#defineMAKEINTRESOURCEW（i）（LPWSTR）（（DWORD）（（WORD）（i）））

#ifdefUNICODE

#defineMAKEINTRESOURCEMAKEINTRESOURCEW

#else

#defineMAKEINTRESOURCEMAKEINTRESOURCEA

4.5__stdcall约定

　　如果通过VC++编写的DLL欲被其他语言编写的程序调用，应将函数的调用方式声明为__stdcall方式，WINAPI都采用这种方式，而C/C++缺省的调用方式却为__cdecl。

__stdcall方式与__cdecl对函数名最终生成符号的方式不同。

若采用C编译方式（在C++中需将函数声明为extern"C"），__stdcall调用约定在输出函数名前面加下划线，后面加“@”符号和参数的字节数，形如_functionname@number；而__cdecl调用约定仅在输出函数名前面加下划线