有关动态链接库的知识

模块直接将 DLL 导出函数当作本地函数（local function）进行调用。这需要你在对模块进行链接时链接该 DLL 的导入库。导入库为系统提供了载入 DLL 所需要的信息，并提供了在应用载入时找到导出函数的信息。

当系统运行使用载入时链接的程序时，它会使用链接器放在程序文件中的信息来确定程序所使用的 DLL 的名字。系统在之后开始搜索 DLL。

如果系统不能找到需要的 DLL，它会终止进程并显示一个报告错误的对话框。若顺利找到 DLL，系统会将 DLL 映射到进程的虚拟地址空间中并给 DLL 的引用计数加一。

系统会调用 DLL 的入口点函数。这个函数接收到表明进程载入 DLL 的代码。如果入口点函数的返回值不是 TRUE，系统会终止程序并报告错误。

最后，系统会以 DLL 导入函数的起始地址对函数地址表进行修改，让程序中的函数调用对应到相应的函数地址。

使用运行时链接的方式进行调用不需要提供头文件和导入库

通过使用特定的函数 LoadLibrary 或 LoadLibraryEx 来在运行时载入 DLL。在 DLL 载入后，可以通过函数 GetProcAddress 来得到 DLL 导出函数或数据的地址。通过该函数返回的指针来使用导出函数。这样就不必使用导入库了。

当应用程序调用 LoadLibrary 或 LoadLibraryEx 时，系统会尝试定位 DLL。如果搜索成功，系统会将 DLL 模块映射到进程的虚拟地址空间并增加库的引用计数。如果对 LoadLibrary 或 LoadLibraryEx 的调用指定了一个已经映射到虚拟地址的 DLL，那么函数仅会返回该 DLL 的句柄并增加引用计数。需要注意的是，同名但不同目录的 DLL 不被看作是同一个 DLL。

系统会对入口点函数进行调用，该调用在调用 LoadLibrary 或 LoadLibraryEx 的上下文中。如果 DLL 已经载入过一次，在没有出现相对应的 FreeLibrary 函数的情况下，通过 LoadLibrary 或 LoadibraryEx 载入的 DLL 的入口点函数不会被调用。

如果系统不能找到 DLL 或入口点函数返回值为 FALSE， LoadLibrary 或 LoadLibraryEx 会返回 NULL。如果它调用成功，则会返回 DLL 模块的句柄。进程可以使用这个句柄来调用 GetProcAddress ， FreeLibrary 或 FreeLibraryAndExitThread 等函数。

GetModuleHandle 函数返回一个 DLL 的句柄。仅当 DLL 已经映射到了进程的地址空间， GetModuleHandle 的调用才会成功。与 LoadLibrary 和 LoadLibraryEx 不同的是， GetModuleHandle 不会增加模块的引用计数。 GetModuleFileName 函数可以检索模块的绝对路径。

GetProcAddress 函数可用于获得导出函数的地址，它需要使用 DLL 模块的句柄。

当 DLL 模块不再被需要时，进程可以调用 FreeLibrary 或 FreeLibraryAndExitThread 。这些函数会减少模块的引用计数，并在引用计数降为零时取消 DLL 的虚拟内存映射。

运行时链接允许进程在即便 DLL 不可用的情况下运行。进程可以使用替代方法来达成它的目的。例如，如果一个进程不能定位一个 DLL，它可以尝试使用另一个，或直接向用户提示错误。如果用户能够提供缺失 DLL 的绝对路径，这个进程可以使用这个路径来载入 DLL，即便该路径不是一般的搜索路径。

对于使用 DllMain 函数来为每一个线程初始化的进程，运行时链接可能会造成一些问题，因为入口点函数不会为在调用 LoadLibrary 或 LoadLibraryEx 之前就存在的线程进行调用。

• 如果同名的 DLL 已经载入到内存中，不论它在哪个目录，系统只会在检查已载入的 DLL 之前检查重定向。系统不会搜索该 DLL。
• 如果 DLL 存在于应用程序运行的 Windows 版本的 已知 DLL 列表中，系统会使用已知 DLL 的副本而不是寻找 DLL。
• 如果一个 DLL 存在依赖，系统会搜索它依赖的 DLL，并假设它们只有名字信息（没有路径信息）。即使第一个 DLL 以指定的绝对路径载入，其余依赖的 DLL 也只会使用名字进行搜索。

桌面应用可以通过指定绝对路径，使用 DLL 重定向或使用 Manifests 来控制 DLL 的载入位置。如果这些方法都没有被使用，系统在载入时的 DLL 搜索操作如下所示。

在开始对 DLL 的搜索之前，系统首先会对如下项进行检查：

• 如果同名的 DLL 模块已经在内存中载入了，系统会使用载入的 DLL，不论它的地址如何。系统不会搜索 DLL。
• 如果 DLL 存在于 已知 DLL 表上。系统不会搜索 DLL，而是使用已载入的 DLL。

系统使用的标准 DLL 搜索顺序取决于 DLL 搜索安全模式（SafeDllSearchMode）的打开或关闭。DLL 搜索安全模式将用户的当前路径放在搜索顺序靠后的地方。DLL 搜索安全模式默认打开（Windows XP 默认关闭）。调用 SetDllDirectory 来添加库搜索目录会关闭 SafeDllSearchMode。

如果 SafeDllSearchMode 是打开的，搜索顺序如下所示：

1. 应用程序载入的目录。
2. 系统目录。使用 GetSystemDirectory 可以得到这个目录的路径。
3. 16位系统目录。没有函数能够获得这个目录的路径，但是它会被搜索。
4. Windows 目录。使用 GetWindowsDirectory 函数来获取目录的路径。
5. 当前目录。
6. 列在 PATH 环境变量中的目录。这不包括由 App Path Key 指定的应用目录。

如果 SafeDllSearchMode 被关闭了，当前目录会成为第二个被搜索的目录，其余保持不变。

在 DLL 中定义为全局变量的变量会被编译器和链接器作为全局变量对待，每个载入给定 DLL 的进程都会有属于它自己的 DLL 全局变量。静态变量被限制在定义它的区域内。

默认情况下，每个进程都会有属于它的 DLL 全局变量和静态变量实例。

在如下事件发生时，系统会调用入口点函数：

• 一个进程载入了 DLL。对于使用载入时链接的进程，DLL 在进程初始化时就被载入。对于使用运行时链接的进程，DLL 的载入发生在 LoadLibrary 和 LoadLibraryEx 返回之前。
• 一个进程卸载了 DLL。当进程终止时，或调用 FreeLibrary 且引用计数归零时，DLL 会被卸载。如果进程是因为 TerminateProcess 或 TerminateThread 而终止，系统则不会调用 DLL 的入口点函数。
• 在进程中创建的新线程载入了 DLL。你可以在创建线程时使用 DisableThreadLibraryCalls 来使其无效化。
• 一个载入了 DLL 的进程的线程正常终止了。对整个进程，入口点函数只会被调用一次，而不是对每个存在于进程中的线程。同样的，可以使用 DisableThreadLibraryCalls 来使其无效化。

系统在创建进程或线程（进程或线程载入了 DLL）的上下文中调用入口点函数。这就允许 DLL 通过使用入口点函数在进程的虚拟内存空间上分配内存。

入口点函数的函数原型为：

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,
    DWORD fdwReason,
    LPVOID lpReserved);

当库第一次开始和终止时， DllMain 都会被调用。DllMain 的第一个参数是库的实例句柄，第二个参数的值可以是四个值中的一个，用来说明 Windows 调用 DllMain 函数的原因。第三个参数是系统保留参数。如果初始化成功， DllMain 应该返回非 0 值，返回 0 导致 Windows 无法运行该程序。

入口点函数必须声明为标准调用 __stdcall 的调用约定。如果 DLL 入口点函数没有被正确地声明，DLL 不会被载入，系统会显示消息来表明：DLL 入口点函数必须声明为 WINAPI 。

在函数体中，你可以处理以下消息：

• 进程载入了 DLL （DLL_PROCESS_ATTACH）
• 当前进程创建了新线程（DLL_THREAD_ATTACH）
• 线程正常退出（DLL_THREAD_DETACH）
• 进程卸载 DLL（DLL_PROCESS_DETACH）

可以通过使用 __declspec(dllexport) 关键字来从 DLL 中导出数据，函数，类，或类成员函数。 __declspec(dllexport) 将导出指令添加到目标文件中。使用了 __declspec(dllexport) 则无需使用 DEF 文件。

对于导出函数，如果指定了调用约定关键字，那么关键字 __declspec(dllexport) 必须写在调用约定关键字的左边。例如

__declspec(dllexport) __cdecl void Function(void);

（注意： __declspec(dllexport) 不能用于使用了 __clrcall 调用约定的函数）

要导出类中的所有公共数据成员和成员函数的话，这个关键字应该出现在类名的左边，就像这样：

class __declspec(dllexport) CExamplaExport : public CObject
{ ... class definition ... };

创建 DLL 时，一般会创建一个包含导出函数的函数原型和导出的类的头文件（用于 DLL 的构建），并将在这些声明中加上 __declspec(dllexport) 。为了让代码的可读性更强，可以为 __declspec(dllexport) 定义一个宏，并使用这个宏来标注导出函数。

#define DllExport __declspec(dllexport)

extern "C" __declspec(dllexport) int MyFunc(long parm1);

//MyFunc.h
#ifdef __cplusplus
extern "C" { //only need to export C interface if
             // used by C++ source code
#endif

__declspec(dllimport) void MyCFunc();
__declspec(dllimport) void AnotherCFunc();

#ifdef __cplusplus
}
#endif

extern "C" {
#include "MyCHeader.h"
}

DEF 文件（*.def）是一个包含一个或多个模块语句的文本文件，这些语句描述了 DLL 的多种性质。如果没有使用 __declspec(dllexport) 来导出 DLL 的函数，那么 DLL 就需要一个 DEF 文件进行相关说明。

一个 DEF 文件必须包含以下模块定义语句

• 文件的第一个语句必须是 LIBRARY 语句。这条语句标识 DEF 所属的 DLL。LIBRARY 后接 DLL 的名称。链接器会将这个名字放在 DLL 的导入库中。
• EXPORT 语句列出了函数名和可选的导出函数的序列值（ordinal）（可选）。通过在函数名后面接上符号（@）和一个数字，你将一个序列值赋给了该函数。序列值的范围从 1 到 N，N 是 DLL 导出函数的个数。

一个简定的 DLL 的 DEF 文件可以是这样：

LIBRARY MYDLL
EXPORTS
    Fun1 @1
    Fun2 @2
    Fun3 @3
    Fun4 @4

如果你要导出 C++ 文件中的函数，你要么将被修饰过的名字放进 DEF 文件，要么通过使用 extern "C" 来使用标准 C 链接。修饰名可以通过 dumpbin 工具查看（/MAP 选项）。需要注意的是，由编译器生成的修饰名是特定于编译器的，如果你将由 MSVC 产生的修饰名用在 DEF 文件中，那么使用这个 DLL 的程序必须使用相同于构建 DLL 版本的 MSVC，这样修饰名才会匹配。

假设 func1 是一个 DLL 中的函数，与包含 main 函数的 .exe 文件分离。

不使用 __declspec(dllimport) ，考虑下面的代码

int main(void)
{
    func1();
}

编译器会生成类似下面的代码：

call func1

链接器会将它翻译成类似这个样子：

call 0x40000000       ; The address of 'func1'

如果 func1 存在于其它 DLL 中（而不是 .exe 中），链接器不能直接对其进行分析，因为它无法知道 func1 的地址。在 16 位环境中，链接器将地址添加在 .exe 文件的表中，载入器可以通过它在运行时使用正确的地址进行相应的修补。在 32 位或 64 位环境中，链接器会生成一个 thunk ，它知道地址。在 32 位环境中看起来就像这样：

call 0x40000000: jmp DWORD PTR __imp_func1

在这里， imp_func1 是 .exe 文件中的导入地址表中 func1 的地址。这样，链接器就可以识别所有地址。载入器（loader）只需在载入时更新 .exe 文件的导入地址表即可使程序正常运行。

因此，使用 __declspec(dllimport) 更好，因为如果不需要的话，链接器就不会生成一个 thunk。Thunk 让代码更多并可能会降低 cache 性能。如果你告诉编译器该函数在 DLL 中，它能为你产生一个间接调用。

使用下面的代码：

__decpspec(dllimport) void func1(void);
int main(void)
{
    func1();
}

会生成这样的指令：

call DWORD PTR __imp_func1

现在，thunk 和 jmp 指令就不存在了，代码变得更小更快。

另一方面，对于 DLL 内的函数调用，不需要使用间接调用。你已经知道了函数的地址。在间接调用之前，载入和存储函数地址需要时间和空间，因此直接调用总是更小更快。你只有在从 DLL 外部调用 DLL 函数时使用 __declspec(dllimport) 。不要在构建 DLL 时在 DLL 内使用 __declspec(dllimport) 。

对数据而言，使用 _declspec(dllimport) 可以消除一层间接。当你从 DLL 中导出数据时，你仍然需要浏览整个导入地址表，这意味着你当你访问 DLL 导出的数据时，你不得不记住额外的间接层，执行额外的间接寻址，就像这样：

//project.h
#ifdef _DLL //if accessing the data from inside the DLL
    ULONG ulDataInDll;
#else       //if accessing the data from outside the DLL
    ULONG *ulDataInDll;

当你使用 __declspec(dllimport) 来标出数据时，编译器会自动为你生成间接代码。你不必担心是否需要解引用，可以直接使用变量而不是指针。

不要在构建 DLL 时使用 __declspec(dllimport) ，在 DLL 内的函数不需要使用导入地址表来访问数据对象。

__cdecl 是 C 和 C++ 的默认调用约定。因为栈的清理工作由调用者完成，它可以用作 vararg 函数。 __cdecl 调用生成会创建比使用 __stdcall 更大的可执行程序，因为它需要为每个函数调用包含清理栈的代码。

__stdcall 调用约定用于 Win32 API 函数。被调函数负责栈的清理，因此编译器会将 vararg 函数变成 __cdecl 的调用约定。使用该约定的函数需要一个函数原型。

关于更多的调用约定，可参考 Calling Conventions