动态链接库

title: 背景.
content: DLL的最初目的是节约应用程序所需的磁盘和内存空间。在一个传统的非共享函式库中,一部分代码简单地附加到调用的程序上。如果两个程序调用同一个子程序,就会出现两份那段代码。相反,许多应用共享的代码能够切分到一个DLL中,在硬盘上存为一个文件,在内存中使用一个实例(instance)。DLL的广泛应用使得早期的视窗能够在紧张的内存条件下运行。  DLL提供了如模块化这样的共享函式库的普通好处。模块化允许仅仅更改几个应用程序共享使用的一个DLL中的代码和数据而不需要更改应用程序自身。这种模块化的基本形式允许如Microsoft Office、Microsoft Visual Studio、甚至Microsoft Windows自身这样大的应用程序使用较为紧凑的补丁和服务包。  模块化的另外一个好处是插件的通用接口使用。单个的接口允许旧的模块与新的模块一样能够与以前的应用程序运行时无缝地集成到一起,而不需要对应用程序本身作任何更改。这种动态扩展的思想在ActiveX中发挥到了极致。  尽管有这么多的优点,使用DLL也有一个缺点:DLL地狱,也就是几个应用程序在使用同一个共享DLL函式库发生版本冲突。这样的冲突可以通过将不同版本的问题DLL放到应用程序所在的文件夹而不是放到系统文件夹来解决;但是,这样将抵消共享DLL节约的空间。目前,Microsoft.NET将解决DLL hell问题当作自己的目标,它允许同一个共享函式库的不同版本并列共存。由于现代的计算机有足够的磁盘空间和内存,这也可以作为一个合理的实现方法。
title: 技术.
title: 内存管理.
content: 在Win32中,DLL文件按照片段(sections)进行组织。每个片段有它自己的属性,如可写或是只读、可执行(代码)或者不可执行(数据)等等。这些section可分为两种,一个是与绝对地址寻址无关的,所以能被多进程公用;另一个是与绝对地址寻址有关的,这个就必须由每个进程有自己的副本专用。sections的这种二分类,在编译DLL时就已经由编译器、链接器给标注好了。所以在装入DLL时,装入器知道哪些sections在内存物理地址空间只需要有一份,供多个进程共享(映射到各个进程的内存逻辑地址空间,所以逻辑地址可以不同); 哪些sections必须是进程使用自己的专用副本。  也可在程序编译时通过编译选项/section 的S (Shared)属性,显式指定哪个节是跨进程共享的。默认情况下,DLL的数据节都是写时复制(COW)。  具体说,DLL装入时需考虑下述情形:  DLL代码段通常被使用这个DLL的所有进程所共享。如果代码段所占据的物理内存被收回,它的内容就会被放弃,后面如果需要的话就直接从DLL文件重新加载。  与代码段不同,DLL的数据段通常是私有的;也就是说,每个使用DLL的进程都有自己的DLL数据副本。作为选择,数据段可以设置为共享,允许通过这个共享内存区域进行进程间通信。但是,因为用户权限不能应用到这个共享DLL内存,这将产生一个安全漏洞;也就是一个进程能够破坏共享数据,这将导致其它的共享进程异常。例如,一个使用访客账号的进程将可能通过这种方式破坏其它运行在特权账号的进程。这是在DLL中避免使用共享片段的一个重要原因。  当DLL被如UPX这样一个可执行的packer压缩时,它的所有代码段都标记为可以读写并且是非共享的。可以读写的代码段,类似于私有数据段,是每个进程私有的并且被页面文件备份。这样,压缩DLL将同时增加内存和磁盘空间消耗,所以共享DLL应当避免使用压缩DLL。
title: 符号解析和绑定.
content: DLL输出的每个函数都由一个数字序号唯一标识,也可以由可选的名字标识。同样,DLL引入的函数也可以由序号或者名字标识。对于内部函数来说,只输出序号的情形很常见。对于大多数视窗API函数来说名字是不同视窗版本之间保留不变的;序号有可能会发生变化。这样,我们不能根据序号引用视窗API函数。  按照序号引用函数并不一定比按照名字引用函数性能更好:DLL输出表是按照名字排列的,所以对半查找可以用来在在这个表中根据名字查找这个函数。另外一方面,只有线性查找才可以用于根据序号查找函数。  将一个可执行文件绑定到一个特定版本的DLL也是可能的,这也就是说,可以在编译时解析输入函数(imported functions)的地址。对于绑定的输入函数,连结工具保存了输入函数绑定的DLL的时间戳和校验和。在运行时Windows检查是否正在使用同样版本的函式库,如果是的话,Windows将绕过处理输入函数;否则如果函式库与绑定的函式库不同,Windows将按照正常的方式处理输入函数。  绑定的可执行文件如果运行在与它们编译所用的环境一样,函数调用将会较快,如果是在一个不同的环境它们就等同于正常的调用,所以绑定输入函数没有任何的缺点。例如,所有的标准Windows应用程序都绑定到它们各自的Windows发布版本的系统DLL。将一个应用程序输入函数绑定到它的目的环境的好机会是在应用程序安装的过程。
title: 运行时通知DLL进程/线程加载.
content: 进程/线程加载时,可以通过DllMain函数通知DLL相关信息,提供对应处理的机会。
title: 动态链接库搜索顺序.
content: 对于Windows,加载动态链接库时:  Windows Desktop应用程序的DLL标准搜索序: 如果SafeDllSearchMode被禁止,则当前目录成为第二个被搜索的目录。  Windows Desktop应用程序的DLL替代搜索序。 这包括两种情况: 当所有DLL都完成搜索,要开始执行DLL的初始化时,替代搜索序结束,恢复标准搜索序。
title: 运行时显式链接.
content: 对于一个进程,每个被加载的DLL在进程的PEB中有一个引用计数器,在当前进程中每多一次加载该计数器便加一。codice_7 与 codice_8 指令影响每一个行程内含的计数器;动态连结则不影响。因此借由呼叫 codice_8 而从内存卸载一 DLL 是很重要的。一个行程可以从它自己的 VAS 注销此计数器。该计数器变为0时,这个DLL从当前进程中卸载,但并不意味着会从物理内存中卸载,因为其它进程可能使用这个DLL。  DLL 文件能够在运行时使用 codice_7(或者 codice_11)API 函数进行显式调用,这个的过程微软简单地称为运行时动态调用。如果在上述API的参数中指明了库文件的全路径,则不再搜索这个库文件。API 函数codice_12 查找具有某名称的输出函数、codice_8卸载 DLL(实际上是引用计数器减一)。这些函数类似于 POSIX 标准 API 中的 codice_14、codice_15、和 codice_16。  注意微软简单称为“运行时动态链接”的运行时隐式链接,如果不能找到链接的 DLL 文件,Windows 将提示一个错误消息并且调用应用程序失败(准确地说是不能创建进程)。应用程序开发人员不能通过编译链接来处理这种缺少 DLL 文件的隐式链接问题,而且在更改了实现后还必须重新编译链接整个程序——默认的增量链接模式会一直保留着那条缺少的函数引用,只有重新编译链接才能去掉。相反,虽然显式链接的代码量增多了,但开发人员有机会提供一个完善的出错处理机制。  运行时显式链接的过程在所有语言中都是相同的,因为它依赖于 Windows API 而不是语言结构。只要一种语言能够调用上述的 codice_7 等函数,就能执行运行时显示链接。
title: Win16下的DLL.
content: 16位Windows,所有进程共享同一个内存地址空间。如果一个DLL被多个进程使用,它只被加载到内存中一次,只有一份数据节(data segment)。也就是说,DLL是系统全局而不是进程内的;进程不能得到DLL的一份独立的拷贝。每个DLL在内存中只有一份实例(instance)。  如果一个EXE文件同时执行多次,那么在内存中只有该EXE的一套只读拷贝(如代码或资源),但这个EXE的每个进程都有自己的一套数据段,即有多份实例(instance)。实际上,进程的实例句柄就是data segment(存放进程的全局变量)的内存起始地址。  模块(module)是指一个硬盘文件,可被加载到内存中。模块句柄是一个数据结构,表示这个硬盘文件的各部分(section)出自哪里,是否已经加载到内存中。  所以进程只能用实例句柄标识,而不能用模块句柄标识。  Win32的进程使用自己专用的逻辑内存空间。进程的全局变量不再是跨进程边界可见的。实例句柄与模块句柄相同,都是指向模块加载后的内存基地址。这样规定实际上也兼容了Win16时实例句柄与模块句柄的含义。
title: 资源加载.
content: EXE和DLL都有其自己的资源(如对话框资源),而且这些资源的ID可能重复,默认使用EXE的资源。 如果需要加载、使用DLL中的资源,需要通过DLL加载后的实例句柄(HINSTANCE)来找到DLL的资源。  应用程序进程本身及其调用的每个DLL模块都具有一个全局唯一的HINSTANCE句柄,它们代表了EXE或DLL模块在进程逻辑地址空间中的起始地址。进程本身的模块句柄一般为0x400000,而DLL模块默认加载地址为0x10000000。如果程序同时加载了多个DLL,则每个DLL模块都会有不同的HINSTANCE。  几种可行的办法:  方法1:  AFX_MANAGE_STATE(AfxGetStaticModuleState());必须作为接口函数的第一条语句。功能是在栈上创建一个AFX_MAINTAIN_STATE2类的实例,利用其构造函数和析构函数对_afxThreadState.GetData()所指向内存存储块的模块状态(AFX_MODULE_STATE类型)设置现场(AfxGetModuleState函数返回的值)及恢复现场。 方法2: 方法3:
title: 编译器和语言考虑.
title: Delphi.
content: 在源文件的开头使用关键词codice_18而不是codice_19,在文件的末尾输出函数使用codice_20排列。  Delphi不需要codice_21文件以从DLL中输入函数。为了链接一个DLL,在函数声明中使用关键词codice_22。
title: 微软 Visual Basic 及.Net 框架.
content: 在Visual Basic(VB)中只支持运行时链接;但是除了使用codice_7和codice_12这两个API函数之外,允许使用输入函数的声明来引入DLL函数,如果找不到codice_25文件,VB将产生一个运行时异常。开发人员可以捕获该异常并且进行适当的处理。  Visual Basic 6这样的较老的语言,只能调用codice_26调用约定修饰的函数,并需要在声明DLL的输出函数时使用Alias,否则就会出现在DLL中找不到函数入口点的错误。例如:  也可以用def文件来定义dll输出函数的名字。。另外需要注意,VB6调用的dll,如果还依赖其他的dll,那么这些间接依赖的dll必须在VB6程序的dll搜索路径上,否则会报无法找到(被直接依赖的)dll的错误。  为了兼容,codice_27 的方式一直沿用到 VB.net。不过在.net 中,平台调用提供了一种新的声明DLL中的输出函数方式,通过 codice_28 提供。例如:  在同为.net 语言的 C# 中,这是仅有的处理方式。当然托管 C/C++ 就不必受此限制,见下节。
title: C和C++.
content: 微软Visual C++(MSVC)提供了许多标准C++的扩展,它允许直接在C++代码中将函数(类、数据变量)声明为输入或输出;这种做法已经被Windows平台上其他的C和C++编译器采纳,包括Windows平台上的GCC。这种扩展在函数声明前使用codice_29属性:  如果是遵从C命名规范(naming convention)的外部名字,它们必须在C++代码中声明为codice_36以避免它们使用C++命名规范。如果使用dll的语言(如Fortran、Visual Basic 6)不能识别C命名规范,那么需要采取办法指出在DLL中输出函数的名字。也可以通过DEF文件来定义输出函数的名字与序号。或者使用如下的链接指令来制定dll输出函数名字:  除了使用codice_29属性定义输入输出函数之外,它们也可以列在项目codice_38文件的IMPORT或者EXPORTS部分。codice_38文件不是由编译器进行处理,而是由链接器据此生成DLL文件中输出函数的名字与顺序(ordinal number),这样DEF文件就不是C/C++特有的,其它语言写的程序如果想要编译为DLL也可以使用DEF。  DLL的编译将生成codice_25和codice_21两个文件。codice_21文件被称为输入库(import library),在编译时为调用DLL的程序提供“桩”(stub)实际上是间接跳转到运行时载入的DLL的对应的函数上再继续执行。这种通过输入库来使用DLL的方式,在程序运行时启动进程时就会自动(隐式)加载所有用到的DLL。另一种使用DLL的方式是通过codice_7(或者codice_11) API函数进行显式加载DLL,用codice_12 API函数通过函数名称获取其加载后的内存地址、通过codice_8卸载DLL。  codice_25一般说来必须放在PATH环境变量、缺省系统路经或者是使用它的程序所在路径三个的一个之内。COM服务器DLL使用regsvr32.exe注册,它将DLL的路径和全局唯一身份(GUID)记录在注册表中。应用程序能够通过在注册表中查找GUID、找到它的路径从而使用这个DLL。
title: 编程实例.
title: 创建DLL输出函数.
content: 下面的例子展示了与特定语言相关的从DLL输出符号表的方法。  Delphi  C 或 C++
title: 使用DLL输入.
content: 下面的例子展示了与特定语言相关的如何在编译时链接DLL输入符号表的方法。  C 或 C++
title: 运行时使用显式调用.
content: 下面的例子展示了如何使用不同语言特有的WIN32 API绑定进行运行时的调用和链接。  Microsoft Visual Basic C 或 C++
title: 组件对象模型.
content: 组件对象模型(COM)将DLL概念扩充到了面向对象编程。对象能够从另外一个进程调用或者在另外一台机器上运行。COM对象有一个唯一的GUID并且能够实现强大的后台以简化如Visual Basic和ASP这样的GUI前台应用。它们也可以使用脚本语言编程。COM对象的创建和使用比DLL更为复杂。

Summary: 动态连结函式库(英语:Dynamic-link library,缩写为DLL)是微软公司在微软视窗操作系统中实现共享函数库概念的一种实作方式。这些函式库函数的扩展名是codice_1、codice_2(包含ActiveX控制的函式库)或者codice_3(旧式的系统驱动程序)。

Dynamic-link library: Dynamic-link library (DLL) is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems. These libraries usually have the file extension codice_1, codice_2 (for libraries containing ActiveX controls), or codice_3 (for legacy system drivers). The file formats for DLLs are the same as for Windows EXE files – that is, Portable Executable (PE) for 32-bit and 64-bit Windows, and New Executable (NE) for 16-bit Windows. As with EXEs, DLLs can contain code, data, and resources, in any combination.