VC++动态链接库创建和调用全过程详解.docx
《VC++动态链接库创建和调用全过程详解.docx》由会员分享,可在线阅读,更多相关《VC++动态链接库创建和调用全过程详解.docx(25页珍藏版)》请在冰豆网上搜索。
![VC++动态链接库创建和调用全过程详解.docx](https://file1.bdocx.com/fileroot1/2023-5/29/f31ea2eb-1ac0-4f8d-9d56-49f2b820f5ad/f31ea2eb-1ac0-4f8d-9d56-49f2b820f5ad1.gif)
VC++动态链接库创建和调用全过程详解
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(待续...)
上节给大家介绍了静态链接库与库的调试与查看(动态链接库(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调用约定仅在输出函数名前面加下划线,形如_functionname。
Windows编程中常见的几种函数类型声明宏都是与__stdcall和__cdecl有关的(节选自windef.h):
#defineCALLBACK__stdcall//这就是传说中的回调函数
#defineWINAPI__stdcall//这就是传说中的WINAPI
#defineWINAPIV__cdecl
#defineAPIENTRYWINAPI//DllMain的入口就在这里
#defineAPIPRIVATE__stdcall
#definePASCAL__stdcall
在lib.h中,应这样声明add函数:
int__stdcalladd(intx,inty);
在应用工程中函数指针类型应定义为:
typedefint(__stdcall*lpAddFun)(int,int);
若在lib.h中将函数声明为__stdcall调用,而应用工程中仍使用typedefint(*lpAddFun)(int,int),运行时将发生错误(因为类型不匹配,在应用工程中仍然是缺省的__cdecl调用),弹出如图