本文深入解析动态链接库DLL的原理、功能、调用方式以及与进程、线程之间的关系，通过使用工具Depends进行DLL的详细分析，揭示DLL中的秘密，并介绍DLL引起的故障解决方法。
最近需要分析WINDOWS组件下各DLL的调用，进而提高测试覆盖率，不得不逐一分析各DLL及其用途，企图在界面上触碰到它们。弄得头晕脑胀之际，看了许多DLL方面的文章，受益匪浅，特转载过来，学习之：
转自：http://www.cnblogs.com/choi/archive/2006/08/11/474139.html
在Windows世界中，有无数块活动的大陆，它们都有一个共同的名字——动态链接库。现在就让我们走进这些神奇的活动大陆，找出它们隐藏已久的秘密吧！
初窥门径:Windows的基石
随便打开一个系统目录，一眼望去就能看到很多扩展名DLL的文件，这些就是经常说的“动态链接库”，DLL是Dynamic Link Library(即“动态链接库”)的缩写。从Microsoft公司推出首个版本的Windows以来，动态链接库就一直是这个操作系统的基础。
1.看看DLL里有什么
与其用晦涩的专业术语来解决DLL是什么，不如先来看看DLL里有什么。DLL和EXE文件一样，其中包含的也是程序的二进制执行代码和程序所需的资源(比如图标、对话框、字符串等)，可是为什么要把代码放在DLL里面，而不是做成EXE呢？其实DLL中的代码是以API函数形式出现的，通俗地说，DLL中包含的程序代码都被做成了一个个小模块，应用程序通过按下所需DLL中特定的按钮，来调用DLL中这个按钮所代表的功能。在使用“记事本”等程序时，如果要保存文件或打开文件，就会弹出通用文件对话框，让我们选择文件位置。你可知道，这就是调用了系统底层DLL中的通用对话框界面。
2.系统中几个重要的DLL
Windows中有3个非常重要的底层DLL:Kernel32.dll、User32.dll、GDI32.dll。其中Kernel32.dll顾名思义就是内核相关的功能，主要包含用于管理内存、进程和线程的函数;而User32.dll中包含的则是用于执行用户界面任务的函数，比如把用户的鼠标点击操作传递给窗口，以便窗口根据用户的点击来执行预定的事件;GDI32.dll的名称用了缩写，全称是Graphical Device Interface(图形设备接口)，包含用于画图和显示文本的函数，比如要显示一个程序窗口，就调用了其中的函数来画这个窗口。
3.为什么要用DLL
刚才在谈到这个问题的时候，我们只是解释了DLL将程序代码封装成函数的原理。为什么封装成函数，就能成为系统中大量使用DLL的理由呢？
①扩展应用程序
由于DLL能被应用程序动态载入内存。所以，应用程序可以在需要时才将DLL载入到内存中，这让程序的可维护性变得很高。比如QQ的视频功能需要升级，那么负责编写QQ的程序员不必将QQ所有代码都重写，只需将视频功能相关的DLL文件重写即可。
②便于程序员合作
这个和我们最终用户关系不大，仅供了解。我们都知道编程工具有很多，比如VB、VC、Delphi等，如果好几个人合作来编写一个大的程序，那么可能有的人用VB，有的人用VC，每人负责的部分所使用的编程语言都不同，究竟放在哪个编译器中进行编译呢？这就好比一群来自各个国家的人在共同编写一篇文章，如果他们所使用的语言都不同，写出来的文章怎么可能凑到一起呢？而有了DLL后，可以让VC程序员写一个DLL，然后VB程序员在程序中调用，无需为怎么将它们都编译为一个单独的EXE而发愁了。
③节省内存
如果多个应用程序调用的是同一个动态链接库，那么这个DLL文件不会被重复多次装入内存中，而是由这些应用程序共享同一个已载入内存的DLL。就好比一个办公室中，很少会为每一个员工配置一台饮水机的，而是在一个公共位置放上一个饮水机，所有需要喝水的职员都可以共用这台饮水机，降低了成本又节约了空间。
④共享程序资源
包括刚才提到过的通用文件对话框在内，DLL文件提供了应用程序间共享资源的可能。资源可以是程序对话框、字符串、图标，或者声音文件等。
⑤解决应用程序本地化问题
在下载了某个程序的汉化包后，打开汉化说明，经常可以看到用下载包中的DLL文件覆盖掉程序原来的DLL，汉化就完成了。这些程序都是将执行代码和应用程序界面分开编写了，所以汉化者只需简单地将其中和程序界面相关的DLL汉化并发布即可。
求知若渴:探究DLL的真相
谁知道DLL里究竟有多少函数，又有谁知道EXE调用了哪个DLL的哪些函数？其实，这个问题并不难解决。还记不记得本刊2004年第6期的《无间盗IV——盗亦有盗》中介绍的分析EXE文件的工具Dependency Walker(以下简称Depends，下载地址:http://www.newhua.com/cfan/200517/depends.zip)今天我们要用它当探险工具，把DLL真相探个通通透透。
1.看看DLL里有多少函数
第一步:下载并解压Depends，运行其中的depends.exe，然后选择菜单“File→Open”(文件→打开)，在文件选择框中选中需要分析的DLL文件并打开，此处选择QQ目录下的QQZip.dll。
第二步:在程序左侧的树状栏中就列出了这个DLL使用了哪些其他DLL的功能函数(原来DLL中还可以调用其他DLL^O^)，而右侧的两个分栏列表分别显示了函数输入及输出表，函数输出表即为该DLL提供给其他EXE或者DLL调用的函数的总列表。
第三步:函数输出表的Function栏中即为输出函数的名称（见图1），在QQZip.dll中共发现了2个函数:Unzip、Zip。因此可以判断该DLL在QQ程序中负责压缩和解压缩的任务。
2.审审EXE究竟用了哪个DLL
还是拿QQ来作为例子，在Depends中打开QQ.exe，这时界面左侧的树状列表中显示的就是QQ.exe调用的DLL列表（见图2），如果展开这些DLL分支，还会发现其他的DLL，这就说明QQ调用的这些DLL文件还有可能(几乎是肯定)再调用别的DLL。这就好比买了一台新的DVD机，可能其中用的机芯是SONY的，而这个机芯里的一个小电容又有可能是别的公司的，这是同样的道理。
3.用DLL看穿EXE真面目
刚才得到了QQ.exe所使用的DLL列表，其实通过这个列表，还能分析出很多别的信息。比如其中包含MFC42.dll，所以可以判断QQ.exe是采用VC(即Visual C++)编写的，而包含WSOCK32.dll则说明这个程序带有网络通讯功能(废话！QQ如果不能网络通讯还有什么用……)。以下是一个简表，大家在分析别的EXE时可以根据其所使用的DLL来对其功能进行初步判断。
DLL文件名 可以判断出的EXE信息
MFC42.dll 使用VC5.0/6.0编写。
VBRun*.dll “*”代表数字版本号，使用VB3.0/4.0编写。
MSVBVM50.dll 使用VB5.0编写，在Windows 98(SE)上自带该DLL。
MSVBVM60.dll 使用VB6.0编写，在Windows Me/2000/XP等系统上自带该DLL。
ADVAPI32.dll 可能会进行注册表操作。
WSOCK32.dll 具备网络通讯功能。
WS2_32.dll 具备网络通讯功能。
WININET.dll 具备HTTP浏览、下载等功能，典型的例子是浏览器、下载工具。
WINMM.dll 具备多媒体播放能力。
DDRAW.dll 游戏、高级图像处理工具。
D3D*.dll 3D游戏，或者动画处理工具。
4.DLL是个大宝库
除供应用程序调用函数的DLL外，还有另一种用来保存资源的DLL，比如QQ目录下的QQRes.dll，用Depends打开后发现没有任何输出函数，难道是一个鸡肋DLL？可是改用资源工具Resource Hacker(下载地址:http://www.onlinedown.net/soft/12420.htm)打开这个DLL后，就发现原来其中保存了这么多QQ的资源，包括图标、音乐、图片、字符串、对话框……（见图3）
刨根问底:DLL的寓言
DLL引起的故障是很常见的，为什么会引起故障？遇到故障怎么解决？嘘～偷听一下DLL的对话，你就会明白了。
1.从搬运工谈接口兼容性
在Windows工地上，有一个名叫EXE的包工头，他手下有很多称为DLL的建筑工人。其中有一个专门负责搬运的DLL(暂且称为“搬运工A”)，每次需要搬运水泥时，包工头EXE都只要对他喊一声:“来！搬。”
过了一段时间，搬运工A觉得自己的效率太低，于是从原来的每次搬1袋水泥改成了每次搬3袋水泥。改进了搬运方法后，EXE包工头仍然每次只是喊一声:“来！搬。”却不知搬运工A已经改变了搬运的方法。
但又过了一段时间，包工头EXE把搬运工A给辞退了，从别的工地上找来了另一个DLL(暂且称为“搬运工B”)。这个搬运工在别的工地的时候，搬运东西特别快，所以包工头EXE决定把搬运工作给“升级”一下。但真正开始工作时，包工头才发现出了问题……现在不管叫几遍“来！搬。”这个新来的搬运工B都不知道究竟应该搬什么。
上面的例子中，搬运工A改进搬运方法，但EXE调用它的方法仍不变，这就是DLL升级的原理，改进了内部的实现方法，但调用接口不变，这样EXE文件不用跟着升级，就能调用新版本的DLL了。而搬运工B的故事告诉我们，不管新版本的DLL效率多高，如果接口(可以理解为DLL中输出的函数名)与原来的不一致，那么EXE就不知道也无法调用它了。
2.登记身份证的DLL
在系统故障中，有很多都是由于DLL文件没有注册造成的，比如Windows XP的压缩文件夹功能出现故障就很有可能是系统目录中的zipfldr.dll没有注册造成的，这类故障的解决方法也大多是运行如下命令:
regsvr32 DLL文件名
很多人不理解为什么要这么做，是不是所有的DLL都能这样做呢？
其实系统中有两种DLL，一种是不需注册即可使用的，另一种则是必须经过系统登录(即注册)才能使用的。就好像一个临时工，和一个记录在员工名单上的长期合同工的区别一样。如何才能区分这两种DLL呢？方法很简单，用刚才的Depends打开这个DLL，同样是看函数输出表，如果其中包含以下两个函数(前者是注册DLL，后者是反注册DLL)，那么就一定是需要注册才能使用的DLL了。
DllRegisterServer
DllUnregisterServer
而regsvr32这个命令，实际上就是调用DLL中的这两个函数(“regsvr32 /u DLL文件名”调用的即为DllUnregisterServer反注册函数)。
3.插件DLL的秘密
Winamp、Foobar 2000等很多软件都具有插件功能，从网上下载一个DLL放在插件目录下就能让程序支持新的功能，这是怎么做到的呢？就拿时下流行的播放软件“千千静听”来举例吧。
“千千静听”的插件目录在该软件安装目录下的Addin子目录下，程序的插件目录一般都会以“Plugins”、“Addin”来命名。在“千千静听”的插件目录中有许多DLL文件，比如tt_asf.dll、tt_rm.dll等，从文件名中就能看出这些DLL是用来让这个播放器支持各种不同类型的音频文件的。同样，用Depends打开这些文件，你就会发现这些文件的输出函数表中都包括一个同样的函数:ttpGetSoundAddIn（见图4）。
这就是插件的秘密，各种支持插件功能的程序在发布时，都会同时发布一份插件协议，协议中规定了该程序将要调用的插件DLL中必须包含的函数名称及相关的参数规则，然后第三方的插件程序员在编写这个程序的插件时就根据这个插件的标准来编写DLL的输出函数。
①对于插件tt_asf.dll
ttplayer.exe(“千千静听”主程序)对tt_asf.dll说:“我要调用你的ttpGetSoundAddIn函数！”
tt_asf.dll回答:“OK。”
②如果把不相关的DLL放进AddIn目录
ttplayer.exe对未知DLL说:“我要调用你的ttpGetSoundAddIn函数！”
tt_asf.dll回答:“那是什么函数？从来没听说过！”
转自：http://www.51testing.com/?uid-169949-action-viewspace-itemid-97730
dll与使用它地进程在用一个进程空间 ，dll有自己的数据段 (什么意思？)但没有自己的堆栈，所以它利用 使用它的进程地堆栈。如果有一个dll被多个进程使用，则dll重的全局变量在这些进程中都有各自的 实例。
1、dll与进程、线程之间的关系
DLL模块被映射到调用它的进程的虚拟地址空间。
DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。
DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。
DLL使用调用进程的栈。
2、关于共享数据段
DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread Local Strorage)。
在程序里加入预编译指令，或在开发环境的项目设置里也可以达到设置数据段属性的目的.必须给这些变量赋初值,否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。
//////////////////////////////////////////////
DLL(Dynamic Link Libraries)：
比较大的应用程序都由很多模块组成，这些模块分别完成相对独立的功能，它们彼此协作来完成整个软件系统的工作。可能存在一些模块的功能较为通用，在构造其它软件系统时仍会被使用。在构造软件系统时，如果将所有模块的源代码都静态编译到整个应用程序EXE文件中，会产生一些问题：一个缺点是增加了应用程序的大小，它会占用更多的磁盘空间，程序运行时也会消耗较大的内存空间，造成系统资源的浪费；另一个缺点是，在编写大的EXE程序时，在每次修改重建时都必须调整编译所有源代码，增加了编译过程的复杂性，也不利于阶段性的单元测试。
Windows系统平台上提供了一种完全不同的较有效的编程和运行环境，你可以将独立的程序模块创建为较小的DLL(Dynamic Linkable Library)文件，并可对它们单独编译和测试。在运行时，只有当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：
a、Non-MFC DLL:指的是不用MFC的类库结构，直接用C语言写的DLL，其输出的函数一般用的是标准C接口，并能被非MFC或MFC编写的应用程序所调用。
b、Regular DLL:和下述的Extension Dlls一样，是用MFC类库编写的。明显的特点是在源文件里有一个继承CWinApp的类。其又可细分成静态连接到MFC和动态连接到MFC上的。
静态连接到MFC的动态连接库只被VC的专业般和企业版所支持。该类DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。输入函数有如下形式：
extern "C" EXPORT YourExportedFunction( );
如果没有extern “C”修饰，输出函数仅仅能从C++代码中调用。
DLL应用程序从CWinApp派生，但没有消息循环。
动态链接到MFC的规则DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。但是，所有从DLL输出的函数应该以如下语句开始：
AFX_MANAGE_STATE(AfxGetStaticModuleState( ))
此语句用来正确地切换MFC模块状态。
Regular DLL能够被所有支持DLL技术的语言所编写的应用程序所调用。在这种动态连接库中，它必须有一个从CWinApp继承下来的类，DllMain函数被MFC所提供，不用自己显式的写出来。
c、Extension DLL:用来实现从MFC所继承下来的类的重新利用，也就是说，用这种类型的动态连接库，可以用来输出一个从MFC所继承下来的类。它输出的函数仅可以被使用MFC且动态链接到MFC的应用程序使用。可以从MFC继承你所想要的、更适于你自己用的类，并把它提供给你的应用程序。你也可随意的给你的应用程序提供MFC或MFC继承类的对象指针。Extension DLL使用MFC的动态连接版本所创建的，并且它只被用MFC类库所编写的应用程序所调用。Extension DLLs 和Regular DLLs不一样，它没有一个从CWinApp继承而来的类的对象，所以，你必须为自己DllMain函数添加初始化代码和结束代码。
和规则DLL相比，有以下不同：
1、它没有一个从CWinApp派生的对象；
2、它必须有一个DllMain函数；
3、DllMain调用AfxInitExtensionModule函数，必须检查该函数的返回值，如果返回0，DllMmain也返回0；
4、如果它希望输出CRuntimeClass类型的对象或者资源(Resources)，则需要提供一个初始化函数来创建一个CDynLinkLibrary对象。并且，有必要把初始化函数输出；
5、使用扩展DLL的MFC应用程序必须有一个从CWinApp派生的类，而且，一般在InitInstance里调用扩展DLL的初始化函数。
三、dll入口函数：
1、每一个DLL必须有一个入口点，DllMain是一个缺省的入口函数。DllMain负责初始化(Initialization)和结束(Termination)工作，每当一个新的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调用DllMain。但是，使用TerminateProcess或TerminateThread结束进程或者线程，不会调用DllMain。
DllMain的函数原型：
BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved)
{
switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
.......
case DLL_THREAD_ATTACH:
.......
case DLL_THREAD_DETACH:
.......
case DLL_PROCESS_DETACH:
.......
return TRUE;
}
}
参数：
hMoudle：是动态库被调用时所传递来的一个指向自己的句柄(实际上，它是指向_DGROUP段的一个选择符)；
ul_reason_for_call：是一个说明动态库被调原因的标志。当进程或线程装入或卸载动态连接库的时候，操作系统调用入口函数，并说明动态连接库被调用的原因。它所有的可能值为：
DLL_PROCESS_ATTACH: 进程被调用；
DLL_THREAD_ATTACH: 线程被调用；
DLL_PROCESS_DETACH: 进程被停止；
DLL_THREAD_DETACH: 线程被停止；
lpReserved：是一个被系统所保留的参数。
2、_DllMainCRTStartup
为了使用“C”运行库(CRT，C Run time Library)的DLL版本（多线程），一个DLL应用程序必须指定_DllMainCRTStartup为入口函数，DLL的初始化函数必须是DllMain。
_DllMainCRTStartup完成以下任务：当进程或线程捆绑(Attach)到DLL时为“C”运行时的数据(C Runtime Data)分配空间和初始化并且构造全局“C++”对象，当进程或者线程终止使用DLL(Detach)时，清理C Runtime Data并且销毁全局“C++”对象。它还调用DllMain和RawDllMain函数。
RawDllMain在DLL应用程序动态链接到MFC DLL时被需要，但它是静态的链接到DLL应用程序的。在讲述状态管理时解释其原因。
四、关于约定：
动态库输出函数的约定有两种：调用约定和名字修饰约定。
1)调用约定(Calling convention)：决定函数参数传送时入栈和出栈的顺序，由调用者还是被调用者把参数弹出栈，以及编译器用来识别函数名字的修饰约定。
函数调用约定有多种，这里简单说一下：
1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC++5.0中PASCAL调用约定不再被支持（实际上它已被定义为__stdcall。除了__pascal外，__fortran和__syscall也不被支持），取而代之的是__stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。
_stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。
2、C调用约定（即用__cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。
_cdecl是C和C＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。
3、__fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。
_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。
4、thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。
5、naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。
关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的Setting...\C/C++ \Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd，即__cdecl。
要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。
2)名字修饰约定
1、修饰名(Decoration name)
“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--unsigned char，
F--short，
H--int，
I--unsigned int，
J--long，
K--unsigned long，
M--float，
N--double，
_N--bool，
....
PA--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以“0”代替，一个“0”代表一次重复；
4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前；
5、参数表后以“@Z”标识整个名字的结束，如果该函数无参数，则以“Z”标识结束。
其格式为“?functionname@@YG*****@Z”或“?functionname@@YG*XZ”，例如
int Test1（char *var1,unsigned long）-----“?Test1@@YGHPADK@Z”
void Test2（） -----“?Test2@@YGXXZ”
__cdecl调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YA”。
__fastcall调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YI”。
VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用.
五、关于DLL的函数：
动态链接库中定义有两种函数：导出函数(export function)和内部函数(internal function)。导出函数可以被其它模块调用，内部函数在定义它们的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) __cdecl Test(int var);}
其输出函数名为：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)。如：
class AFX_EXT_CLASS CTextDoc : public CDocument
{
…
}
extern "C" AFX_EXT_API void WINAPI InitMYDLL();
这几种方法中，最好采用第三种，方便好用；其次是第一种，如果按顺序号输出，调用效率会高些；最次是第二种。
六、模块定义文件(.DEF)
模块定义文件(.DEF)是一个或多个用于描述DLL属性的模块语句组成的文本文件，每个DEF文件至少必须包含以下模块定义语句：
* 第一个语句必须是LIBRARY语句，指出DLL的名字；
* EXPORTS语句列出被导出函数的名字；将要输出的函数修饰名罗列在EXPORTS之下，这个名字必须与定义函数的名字完全一致，如此就得到一个没有任何修饰的函数名了。
* 可以使用DEscrīptION语句描述DLL的用途(此句可选)；
* ";"对一行进行注释(可选)。
七、DLL程序和调用其输出函数的程序的关系
1、dll与进程、线程之间的关系
DLL模块被映射到调用它的进程的虚拟地址空间。
DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。
DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。
DLL使用调用进程的栈。
2、关于共享数据段
DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread Local Strorage)。
在程序里加入预编译指令，或在开发环境的项目设置里也可以达到设置数据段属性的目的.必须给这些变量赋初值,否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。
转自：http://www.cnblogs.com/choi/archive/2006/08/11/474139.html
在Windows世界中，有无数块活动的大陆，它们都有一个共同的名字——动态链接库。现在就让我们走进这些神奇的活动大陆，找出它们隐藏已久的秘密吧！
初窥门径:Windows的基石
随便打开一个系统目录，一眼望去就能看到很多扩展名DLL的文件，这些就是经常说的“动态链接库”，DLL是Dynamic Link Library(即“动态链接库”)的缩写。从Microsoft公司推出首个版本的Windows以来，动态链接库就一直是这个操作系统的基础。
1.看看DLL里有什么
与其用晦涩的专业术语来解决DLL是什么，不如先来看看DLL里有什么。DLL和EXE文件一样，其中包含的也是程序的二进制执行代码和程序所需的资源(比如图标、对话框、字符串等)，可是为什么要把代码放在DLL里面，而不是做成EXE呢？其实DLL中的代码是以API函数形式出现的，通俗地说，DLL中包含的程序代码都被做成了一个个小模块，应用程序通过按下所需DLL中特定的按钮，来调用DLL中这个按钮所代表的功能。在使用“记事本”等程序时，如果要保存文件或打开文件，就会弹出通用文件对话框，让我们选择文件位置。你可知道，这就是调用了系统底层DLL中的通用对话框界面。
2.系统中几个重要的DLL
Windows中有3个非常重要的底层DLL:Kernel32.dll、User32.dll、GDI32.dll。其中Kernel32.dll顾名思义就是内核相关的功能，主要包含用于管理内存、进程和线程的函数;而User32.dll中包含的则是用于执行用户界面任务的函数，比如把用户的鼠标点击操作传递给窗口，以便窗口根据用户的点击来执行预定的事件;GDI32.dll的名称用了缩写，全称是Graphical Device Interface(图形设备接口)，包含用于画图和显示文本的函数，比如要显示一个程序窗口，就调用了其中的函数来画这个窗口。
3.为什么要用DLL
刚才在谈到这个问题的时候，我们只是解释了DLL将程序代码封装成函数的原理。为什么封装成函数，就能成为系统中大量使用DLL的理由呢？
①扩展应用程序
由于DLL能被应用程序动态载入内存。所以，应用程序可以在需要时才将DLL载入到内存中，这让程序的可维护性变得很高。比如QQ的视频功能需要升级，那么负责编写QQ的程序员不必将QQ所有代码都重写，只需将视频功能相关的DLL文件重写即可。
②便于程序员合作
这个和我们最终用户关系不大，仅供了解。我们都知道编程工具有很多，比如VB、VC、Delphi等，如果好几个人合作来编写一个大的程序，那么可能有的人用VB，有的人用VC，每人负责的部分所使用的编程语言都不同，究竟放在哪个编译器中进行编译呢？这就好比一群来自各个国家的人在共同编写一篇文章，如果他们所使用的语言都不同，写出来的文章怎么可能凑到一起呢？而有了DLL后，可以让VC程序员写一个DLL，然后VB程序员在程序中调用，无需为怎么将它们都编译为一个单独的EXE而发愁了。
③节省内存
如果多个应用程序调用的是同一个动态链接库，那么这个DLL文件不会被重复多次装入内存中，而是由这些应用程序共享同一个已载入内存的DLL。就好比一个办公室中，很少会为每一个员工配置一台饮水机的，而是在一个公共位置放上一个饮水机，所有需要喝水的职员都可以共用这台饮水机，降低了成本又节约了空间。
④共享程序资源
包括刚才提到过的通用文件对话框在内，DLL文件提供了应用程序间共享资源的可能。资源可以是程序对话框、字符串、图标，或者声音文件等。
⑤解决应用程序本地化问题
在下载了某个程序的汉化包后，打开汉化说明，经常可以看到用下载包中的DLL文件覆盖掉程序原来的DLL，汉化就完成了。这些程序都是将执行代码和应用程序界面分开编写了，所以汉化者只需简单地将其中和程序界面相关的DLL汉化并发布即可。
求知若渴:探究DLL的真相
谁知道DLL里究竟有多少函数，又有谁知道EXE调用了哪个DLL的哪些函数？其实，这个问题并不难解决。还记不记得本刊2004年第6期的《无间盗IV——盗亦有盗》中介绍的分析EXE文件的工具Dependency Walker(以下简称Depends，下载地址:http://www.newhua.com/cfan/200517/depends.zip)今天我们要用它当探险工具，把DLL真相探个通通透透。
1.看看DLL里有多少函数
第一步:下载并解压Depends，运行其中的depends.exe，然后选择菜单“File→Open”(文件→打开)，在文件选择框中选中需要分析的DLL文件并打开，此处选择QQ目录下的QQZip.dll。
第二步:在程序左侧的树状栏中就列出了这个DLL使用了哪些其他DLL的功能函数(原来DLL中还可以调用其他DLL^O^)，而右侧的两个分栏列表分别显示了函数输入及输出表，函数输出表即为该DLL提供给其他EXE或者DLL调用的函数的总列表。
第三步:函数输出表的Function栏中即为输出函数的名称（见图1），在QQZip.dll中共发现了2个函数:Unzip、Zip。因此可以判断该DLL在QQ程序中负责压缩和解压缩的任务。
2.审审EXE究竟用了哪个DLL
还是拿QQ来作为例子，在Depends中打开QQ.exe，这时界面左侧的树状列表中显示的就是QQ.exe调用的DLL列表（见图2），如果展开这些DLL分支，还会发现其他的DLL，这就说明QQ调用的这些DLL文件还有可能(几乎是肯定)再调用别的DLL。这就好比买了一台新的DVD机，可能其中用的机芯是SONY的，而这个机芯里的一个小电容又有可能是别的公司的，这是同样的道理。
3.用DLL看穿EXE真面目
刚才得到了QQ.exe所使用的DLL列表，其实通过这个列表，还能分析出很多别的信息。比如其中包含MFC42.dll，所以可以判断QQ.exe是采用VC(即Visual C++)编写的，而包含WSOCK32.dll则说明这个程序带有网络通讯功能(废话！QQ如果不能网络通讯还有什么用……)。以下是一个简表，大家在分析别的EXE时可以根据其所使用的DLL来对其功能进行初步判断。
DLL文件名 可以判断出的EXE信息
MFC42.dll 使用VC5.0/6.0编写。
VBRun*.dll “*”代表数字版本号，使用VB3.0/4.0编写。
MSVBVM50.dll 使用VB5.0编写，在Windows 98(SE)上自带该DLL。
MSVBVM60.dll 使用VB6.0编写，在Windows Me/2000/XP等系统上自带该DLL。
ADVAPI32.dll 可能会进行注册表操作。
WSOCK32.dll 具备网络通讯功能。
WS2_32.dll 具备网络通讯功能。
WININET.dll 具备HTTP浏览、下载等功能，典型的例子是浏览器、下载工具。
WINMM.dll 具备多媒体播放能力。
DDRAW.dll 游戏、高级图像处理工具。
D3D*.dll 3D游戏，或者动画处理工具。
4.DLL是个大宝库
除供应用程序调用函数的DLL外，还有另一种用来保存资源的DLL，比如QQ目录下的QQRes.dll，用Depends打开后发现没有任何输出函数，难道是一个鸡肋DLL？可是改用资源工具Resource Hacker(下载地址:http://www.onlinedown.net/soft/12420.htm)打开这个DLL后，就发现原来其中保存了这么多QQ的资源，包括图标、音乐、图片、字符串、对话框……（见图3）
刨根问底:DLL的寓言
DLL引起的故障是很常见的，为什么会引起故障？遇到故障怎么解决？嘘～偷听一下DLL的对话，你就会明白了。
1.从搬运工谈接口兼容性
在Windows工地上，有一个名叫EXE的包工头，他手下有很多称为DLL的建筑工人。其中有一个专门负责搬运的DLL(暂且称为“搬运工A”)，每次需要搬运水泥时，包工头EXE都只要对他喊一声:“来！搬。”
过了一段时间，搬运工A觉得自己的效率太低，于是从原来的每次搬1袋水泥改成了每次搬3袋水泥。改进了搬运方法后，EXE包工头仍然每次只是喊一声:“来！搬。”却不知搬运工A已经改变了搬运的方法。
但又过了一段时间，包工头EXE把搬运工A给辞退了，从别的工地上找来了另一个DLL(暂且称为“搬运工B”)。这个搬运工在别的工地的时候，搬运东西特别快，所以包工头EXE决定把搬运工作给“升级”一下。但真正开始工作时，包工头才发现出了问题……现在不管叫几遍“来！搬。”这个新来的搬运工B都不知道究竟应该搬什么。
上面的例子中，搬运工A改进搬运方法，但EXE调用它的方法仍不变，这就是DLL升级的原理，改进了内部的实现方法，但调用接口不变，这样EXE文件不用跟着升级，就能调用新版本的DLL了。而搬运工B的故事告诉我们，不管新版本的DLL效率多高，如果接口(可以理解为DLL中输出的函数名)与原来的不一致，那么EXE就不知道也无法调用它了。
2.登记身份证的DLL
在系统故障中，有很多都是由于DLL文件没有注册造成的，比如Windows XP的压缩文件夹功能出现故障就很有可能是系统目录中的zipfldr.dll没有注册造成的，这类故障的解决方法也大多是运行如下命令:
regsvr32 DLL文件名
很多人不理解为什么要这么做，是不是所有的DLL都能这样做呢？
其实系统中有两种DLL，一种是不需注册即可使用的，另一种则是必须经过系统登录(即注册)才能使用的。就好像一个临时工，和一个记录在员工名单上的长期合同工的区别一样。如何才能区分这两种DLL呢？方法很简单，用刚才的Depends打开这个DLL，同样是看函数输出表，如果其中包含以下两个函数(前者是注册DLL，后者是反注册DLL)，那么就一定是需要注册才能使用的DLL了。
DllRegisterServer
DllUnregisterServer
而regsvr32这个命令，实际上就是调用DLL中的这两个函数(“regsvr32 /u DLL文件名”调用的即为DllUnregisterServer反注册函数)。
3.插件DLL的秘密
Winamp、Foobar 2000等很多软件都具有插件功能，从网上下载一个DLL放在插件目录下就能让程序支持新的功能，这是怎么做到的呢？就拿时下流行的播放软件“千千静听”来举例吧。
“千千静听”的插件目录在该软件安装目录下的Addin子目录下，程序的插件目录一般都会以“Plugins”、“Addin”来命名。在“千千静听”的插件目录中有许多DLL文件，比如tt_asf.dll、tt_rm.dll等，从文件名中就能看出这些DLL是用来让这个播放器支持各种不同类型的音频文件的。同样，用Depends打开这些文件，你就会发现这些文件的输出函数表中都包括一个同样的函数:ttpGetSoundAddIn（见图4）。
这就是插件的秘密，各种支持插件功能的程序在发布时，都会同时发布一份插件协议，协议中规定了该程序将要调用的插件DLL中必须包含的函数名称及相关的参数规则，然后第三方的插件程序员在编写这个程序的插件时就根据这个插件的标准来编写DLL的输出函数。
①对于插件tt_asf.dll
ttplayer.exe(“千千静听”主程序)对tt_asf.dll说:“我要调用你的ttpGetSoundAddIn函数！”
tt_asf.dll回答:“OK。”
②如果把不相关的DLL放进AddIn目录
ttplayer.exe对未知DLL说:“我要调用你的ttpGetSoundAddIn函数！”
tt_asf.dll回答:“那是什么函数？从来没听说过！”
转自：http://www.51testing.com/?uid-169949-action-viewspace-itemid-97730
dll与使用它地进程在用一个进程空间 ，dll有自己的数据段 (什么意思？)但没有自己的堆栈，所以它利用 使用它的进程地堆栈。如果有一个dll被多个进程使用，则dll重的全局变量在这些进程中都有各自的 实例。
1、dll与进程、线程之间的关系
DLL模块被映射到调用它的进程的虚拟地址空间。
DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。
DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。
DLL使用调用进程的栈。
2、关于共享数据段
DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread Local Strorage)。
在程序里加入预编译指令，或在开发环境的项目设置里也可以达到设置数据段属性的目的.必须给这些变量赋初值,否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。
//////////////////////////////////////////////
DLL(Dynamic Link Libraries)：
比较大的应用程序都由很多模块组成，这些模块分别完成相对独立的功能，它们彼此协作来完成整个软件系统的工作。可能存在一些模块的功能较为通用，在构造其它软件系统时仍会被使用。在构造软件系统时，如果将所有模块的源代码都静态编译到整个应用程序EXE文件中，会产生一些问题：一个缺点是增加了应用程序的大小，它会占用更多的磁盘空间，程序运行时也会消耗较大的内存空间，造成系统资源的浪费；另一个缺点是，在编写大的EXE程序时，在每次修改重建时都必须调整编译所有源代码，增加了编译过程的复杂性，也不利于阶段性的单元测试。
Windows系统平台上提供了一种完全不同的较有效的编程和运行环境，你可以将独立的程序模块创建为较小的DLL(Dynamic Linkable Library)文件，并可对它们单独编译和测试。在运行时，只有当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：
a、Non-MFC DLL:指的是不用MFC的类库结构，直接用C语言写的DLL，其输出的函数一般用的是标准C接口，并能被非MFC或MFC编写的应用程序所调用。
b、Regular DLL:和下述的Extension Dlls一样，是用MFC类库编写的。明显的特点是在源文件里有一个继承CWinApp的类。其又可细分成静态连接到MFC和动态连接到MFC上的。
静态连接到MFC的动态连接库只被VC的专业般和企业版所支持。该类DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。输入函数有如下形式：
extern "C" EXPORT YourExportedFunction( );
如果没有extern “C”修饰，输出函数仅仅能从C++代码中调用。
DLL应用程序从CWinApp派生，但没有消息循环。
动态链接到MFC的规则DLL应用程序里头的输出函数可以被任意Win32程序使用，包括使用MFC的应用程序。但是，所有从DLL输出的函数应该以如下语句开始：
AFX_MANAGE_STATE(AfxGetStaticModuleState( ))
此语句用来正确地切换MFC模块状态。
Regular DLL能够被所有支持DLL技术的语言所编写的应用程序所调用。在这种动态连接库中，它必须有一个从CWinApp继承下来的类，DllMain函数被MFC所提供，不用自己显式的写出来。
c、Extension DLL:用来实现从MFC所继承下来的类的重新利用，也就是说，用这种类型的动态连接库，可以用来输出一个从MFC所继承下来的类。它输出的函数仅可以被使用MFC且动态链接到MFC的应用程序使用。可以从MFC继承你所想要的、更适于你自己用的类，并把它提供给你的应用程序。你也可随意的给你的应用程序提供MFC或MFC继承类的对象指针。Extension DLL使用MFC的动态连接版本所创建的，并且它只被用MFC类库所编写的应用程序所调用。Extension DLLs 和Regular DLLs不一样，它没有一个从CWinApp继承而来的类的对象，所以，你必须为自己DllMain函数添加初始化代码和结束代码。
和规则DLL相比，有以下不同：
1、它没有一个从CWinApp派生的对象；
2、它必须有一个DllMain函数；
3、DllMain调用AfxInitExtensionModule函数，必须检查该函数的返回值，如果返回0，DllMmain也返回0；
4、如果它希望输出CRuntimeClass类型的对象或者资源(Resources)，则需要提供一个初始化函数来创建一个CDynLinkLibrary对象。并且，有必要把初始化函数输出；
5、使用扩展DLL的MFC应用程序必须有一个从CWinApp派生的类，而且，一般在InitInstance里调用扩展DLL的初始化函数。
三、dll入口函数：
1、每一个DLL必须有一个入口点，DllMain是一个缺省的入口函数。DllMain负责初始化(Initialization)和结束(Termination)工作，每当一个新的进程或者该进程的新的线程访问DLL时，或者访问DLL的每一个进程或者线程不再使用DLL或者结束时，都会调用DllMain。但是，使用TerminateProcess或TerminateThread结束进程或者线程，不会调用DllMain。
DllMain的函数原型：
BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved)
{
switch(ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
.......
case DLL_THREAD_ATTACH:
.......
case DLL_THREAD_DETACH:
.......
case DLL_PROCESS_DETACH:
.......
return TRUE;
}
}
参数：
hMoudle：是动态库被调用时所传递来的一个指向自己的句柄(实际上，它是指向_DGROUP段的一个选择符)；
ul_reason_for_call：是一个说明动态库被调原因的标志。当进程或线程装入或卸载动态连接库的时候，操作系统调用入口函数，并说明动态连接库被调用的原因。它所有的可能值为：
DLL_PROCESS_ATTACH: 进程被调用；
DLL_THREAD_ATTACH: 线程被调用；
DLL_PROCESS_DETACH: 进程被停止；
DLL_THREAD_DETACH: 线程被停止；
lpReserved：是一个被系统所保留的参数。
2、_DllMainCRTStartup
为了使用“C”运行库(CRT，C Run time Library)的DLL版本（多线程），一个DLL应用程序必须指定_DllMainCRTStartup为入口函数，DLL的初始化函数必须是DllMain。
_DllMainCRTStartup完成以下任务：当进程或线程捆绑(Attach)到DLL时为“C”运行时的数据(C Runtime Data)分配空间和初始化并且构造全局“C++”对象，当进程或者线程终止使用DLL(Detach)时，清理C Runtime Data并且销毁全局“C++”对象。它还调用DllMain和RawDllMain函数。
RawDllMain在DLL应用程序动态链接到MFC DLL时被需要，但它是静态的链接到DLL应用程序的。在讲述状态管理时解释其原因。
四、关于约定：
动态库输出函数的约定有两种：调用约定和名字修饰约定。
1)调用约定(Calling convention)：决定函数参数传送时入栈和出栈的顺序，由调用者还是被调用者把参数弹出栈，以及编译器用来识别函数名字的修饰约定。
函数调用约定有多种，这里简单说一下：
1、__stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC++5.0中PASCAL调用约定不再被支持（实际上它已被定义为__stdcall。除了__pascal外，__fortran和__syscall也不被支持），取而代之的是__stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。
_stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上"@"和参数的字节数。
2、C调用约定（即用__cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。
_cdecl是C和C＋＋程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。
3、__fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。
_fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上"@"前缀，在函数名后加上"@"和参数的字节数。
4、thiscall仅仅应用于“C++”成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。
5、naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。
关键字 __stdcall、__cdecl和__fastcall可以直接加在要输出的函数前，也可以在编译环境的Setting...\C/C++ \Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd，即__cdecl。
要完全模仿PASCAL调用约定首先必须使用__stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为__stdcall。使用WINAPI宏可以创建自己的APIs。
2)名字修饰约定
1、修饰名(Decoration name)
“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--unsigned char，
F--short，
H--int，
I--unsigned int，
J--long，
K--unsigned long，
M--float，
N--double，
_N--bool，
....
PA--表示指针，后面的代号表明指针类型，如果相同类型的指针连续出现，以“0”代替，一个“0”代表一次重复；
4、参数表的第一项为该函数的返回值类型，其后依次为参数的数据类型,指针标识在其所指数据类型前；
5、参数表后以“@Z”标识整个名字的结束，如果该函数无参数，则以“Z”标识结束。
其格式为“?functionname@@YG*****@Z”或“?functionname@@YG*XZ”，例如
int Test1（char *var1,unsigned long）-----“?Test1@@YGHPADK@Z”
void Test2（） -----“?Test2@@YGXXZ”
__cdecl调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YA”。
__fastcall调用约定：
规则同上面的_stdcall调用约定，只是参数表的开始标识由上面的“@@YG”变为“@@YI”。
VC++对函数的省缺声明是"__cedcl",将只能被C/C++调用.
五、关于DLL的函数：
动态链接库中定义有两种函数：导出函数(export function)和内部函数(internal function)。导出函数可以被其它模块调用，内部函数在定义它们的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) __cdecl Test(int var);}
其输出函数名为：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)。如：
class AFX_EXT_CLASS CTextDoc : public CDocument
{
…
}
extern "C" AFX_EXT_API void WINAPI InitMYDLL();
这几种方法中，最好采用第三种，方便好用；其次是第一种，如果按顺序号输出，调用效率会高些；最次是第二种。
六、模块定义文件(.DEF)
模块定义文件(.DEF)是一个或多个用于描述DLL属性的模块语句组成的文本文件，每个DEF文件至少必须包含以下模块定义语句：
* 第一个语句必须是LIBRARY语句，指出DLL的名字；
* EXPORTS语句列出被导出函数的名字；将要输出的函数修饰名罗列在EXPORTS之下，这个名字必须与定义函数的名字完全一致，如此就得到一个没有任何修饰的函数名了。
* 可以使用DEscrīptION语句描述DLL的用途(此句可选)；
* ";"对一行进行注释(可选)。
七、DLL程序和调用其输出函数的程序的关系
1、dll与进程、线程之间的关系
DLL模块被映射到调用它的进程的虚拟地址空间。
DLL使用的内存从调用进程的虚拟地址空间分配，只能被该进程的线程所访问。
DLL的句柄可以被调用进程使用；调用进程的句柄可以被DLL使用。
DLL使用调用进程的栈。
2、关于共享数据段
DLL定义的全局变量可以被调用进程访问；DLL可以访问调用进程的全局数据。使用同一DLL的每一个进程都有自己的DLL全局变量实例。如果多个线程并发访问同一变量，则需要使用同步机制；对一个DLL的变量，如果希望每个使用DLL的线程都有自己的值，则应该使用线程局部存储(TLS，Thread Local Strorage)。
在程序里加入预编译指令，或在开发环境的项目设置里也可以达到设置数据段属性的目的.必须给这些变量赋初值,否则编译器会把没有赋初始值的变量放在一个叫未被初始化的数据段中。
扫一扫
1522
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
