第11章 Windows平台库开发

课程目录第11章 Windows平台库开发

一、Windows平台库开发：从静态库到DLL的跨越

说实话，很多从Linux转过来的朋友，第一次接触Windows DLL时都会有点懵。我记得自己刚入行那会儿，看着__declspec(dllexport)这串东西，心里直犯嘀咕——这语法也太奇怪了吧？

但别急，DLL其实没那么神秘。说白了，它就是Windows下的共享库。跟Linux的.so文件是同一个思路——把代码打包，让多个程序共用。

1.1 为什么需要DLL？

我遇到过不少团队，项目一大了就把所有代码塞进一个exe里。结果呢？改一行代码，整个程序要重新编译，链接时间长得能喝杯咖啡。

DLL的好处很明显：

模块化：每个DLL负责一块功能，互不干扰
节省内存：多个进程可以共享同一个DLL的代码段
独立更新：修复bug只需替换一个DLL文件，不用重新发布整个程序
延迟加载：用到了才加载，程序启动更快

我的经验：在大型项目中，我习惯把核心算法、UI组件、网络通信分别做成独立的DLL。这样团队分工清晰，测试也方便。

1.2 DLL的核心机制：导出与导入

DLL工作的核心就两个动作——导出和导入。

导出，就是DLL告诉外界：“我有这些函数，你们可以用。”
导入，就是exe或其他DLL说：“我要用那个DLL里的这些函数。”

Windows提供了两种方式来实现：

__declspec(dllexport/dllimport)：直接在代码里声明，简单直观
.def文件：用单独的配置文件管理导出符号，更灵活

我个人更推荐第一种方式，尤其是中小型项目。代码里一眼就能看出哪些函数是导出的，维护起来方便。

1.3 declspec(dllexport) 和 declspec(dllimport)

这两个关键字，是DLL开发中最常用的工具。

__declspec(dllexport)：告诉编译器，这个函数或变量要导出给其他模块用。

// mydll.h
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif

MYDLL_API int Add(int a, int b);
MYDLL_API void PrintMessage(const char* msg);

你看，这里用了一个宏MYDLL_EXPORTS来控制。在DLL项目里，我们定义这个宏，所以MYDLL_API展开成__declspec(dllexport)。在exe项目里，不定义这个宏，它就变成__declspec(dllimport)。

为什么要这么麻烦？

嗯，这里有个小细节：__declspec(dllimport)能让编译器生成更高效的调用代码。如果不加，也能用，但性能会差一点。我在优化一个图形渲染库时，就因为这个少了几个百分点的性能，后来全部补上了。

重要提醒：导出函数时，记得加上extern "C"（如果是C++代码），否则函数名会被C++编译器修饰（name mangling），导致其他语言调用时找不到函数。

// 正确的导出方式
extern "C" MYDLL_API int Add(int a, int b);

// 或者用宏包裹
#ifdef __cplusplus
extern "C" {
#endif

MYDLL_API int Add(int a, int b);

#ifdef __cplusplus
}
#endif

1.4 .def文件：另一种导出方式

除了用__declspec，还可以用.def文件来管理导出。.def文件是一个纯文本文件，列出了所有要导出的符号。

; mydll.def
LIBRARY "MyDLL"
EXPORTS
    Add
    PrintMessage
    Subtract @3
    Multiply @4 NONAME

这里有几个要点：

LIBRARY：指定DLL的名字
EXPORTS：列出所有导出的函数
@数字：指定导出序号（ordinal），可以加快查找速度
NONAME：只导出序号，不导出函数名，可以减小DLL体积

我曾经接手过一个老项目，里面全是.def文件。说实话，刚开始挺不习惯的。但后来发现，.def文件有个好处——可以控制导出符号的序号，这在某些兼容性场景下很有用。

避坑指南：我曾经遇到过一个bug，.def文件里漏写了一行，结果某个函数怎么都调不到。排查了半天才发现是.def文件没更新。所以，如果你用.def文件，一定要记得同步更新。

1.5 DllMain函数：DLL的入口点

每个DLL都可以有一个DllMain函数。它会在DLL加载、卸载、线程创建、线程销毁时被调用。

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,  // DLL模块的句柄
    DWORD fdwReason,     // 调用原因
    LPVOID lpvReserved   // 保留参数
)
{
    switch (fdwReason)
    {
    case DLL_PROCESS_ATTACH:
        // DLL被加载到进程空间
        // 适合做初始化工作
        break;

    case DLL_PROCESS_DETACH:
        // DLL被从进程卸载
        // 适合做清理工作
        break;

    case DLL_THREAD_ATTACH:
        // 进程创建了新线程
        break;

    case DLL_THREAD_DETACH:
        // 线程正常退出
        break;
    }
    return TRUE; // 返回FALSE表示加载失败
}

这里有几个关键点：

DLL_PROCESS_ATTACH：只会在第一个线程加载DLL时触发一次
DLL_PROCESS_DETACH：DLL被卸载时触发
DLL_THREAD_ATTACH/DETACH：每个线程创建/销毁时都会触发

重要限制：在DllMain里，你不能做以下事情：

调用LoadLibrary或FreeLibrary
调用CoInitialize、CoUninitialize等COM函数
创建窗口或消息循环
等待其他线程

为什么？因为DllMain是在加载器锁（loader lock）下执行的。一旦你在里面做了复杂操作，很容易造成死锁。

我记得有一次，一个同事在DllMain里调用了CreateThread，结果程序启动时随机崩溃。排查了两天才找到原因——加载器锁导致的死锁。从那以后，我养成了一个习惯：DllMain里只做最简单的初始化，比如分配一个全局变量，复杂的初始化放到一个专门的初始化函数里。

1.6 知识体系总览

下面这张图，帮你理清DLL开发的核心脉络：

1.7 实战建议

说了这么多，给你几个实际开发中的建议：

统一导出宏：在项目里定义一个统一的导出宏（比如上面的MYDLL_API），所有导出函数都用它。这样代码整洁，也方便切换导出方式。
DllMain保持精简：只做最必要的初始化。复杂的逻辑放到单独的初始化函数里，让调用方显式调用。
注意C++名字修饰：如果DLL要供C#、Python等其他语言调用，记得用extern "C"。
版本管理：给DLL加上版本号，避免“DLL地狱”（不同版本互相覆盖导致的问题）。

小技巧：在Visual Studio中，可以在项目属性里设置“链接器 → 输入 → 模块定义文件”来指定.def文件。如果同时使用__declspec(dllexport)和.def文件，.def文件的优先级更高。

好了，DLL的基础知识就讲到这里。下一章我们会深入DLL的加载机制，看看隐式链接和显式链接到底有什么区别，以及如何在实际项目中做出选择。

📚 课程目录

一、Windows平台库开发：从静态库到DLL的跨越

1.1 为什么需要DLL？

1.2 DLL的核心机制：导出与导入

1.3 __declspec(dllexport) 和 __declspec(dllimport)

1.4 .def文件：另一种导出方式

1.5 DllMain函数：DLL的入口点

1.6 知识体系总览

1.7 实战建议

1.3 declspec(dllexport) 和 declspec(dllimport)