Windows 和 Unix 下动态链接库的区别

动态链接库在 unix 下，习惯以 .so 为文件名结尾（通常还以 lib 开头）。而 Windows 下是以 .DLL 为文件后缀。Windows 在处理 dll 上还有一些细节容易被人忽略

如果需要运行时主动加载一个动态链接库，windows 下可以使用 LoadLibrary 这个 kernel API (在 kernel32.dll 中)；unix 下是用 dlopen 。Windows 下找到 dll 中导出符号的地址，可以用 GetProcAddress ，而 unix 也有对应的 api ...

这些相互对应的 api ，似乎预示着对等的功能，但事实上是有区别的。

DLL 事实上和 EXE 文件一样，同属 PE 格式的执行文件。对于隐式的引用外部符号，需要把外部符号所在的位置写在 PE 头上。PE 加载器将从 PE 头上找到依赖的符号表，并加载依赖的其它 DLL 文件。

但是，unix 上并非如此，so 文件大多为 elf 执行文件格式。当它们需要的外部符号，可以不写明这些符号所在的位置。也就是说，通常 so 文件本身并不知道它依赖的那些符号在哪些 so 里面。这些符号是由调用 dlopen 的进程运行时提供的。而 unix 下的执行文件本身会暴露自己静态链接的符号，（可以是自己本身实现的，或者是从静态库 .a 文件里链入的）。dlopen 将把这些符号通报给 dlopen 加载的 .so 文件，最终完成动态链接。（事实上 dlopen 还可以指定 mode ，完成更复杂的操作）

因为这个区别，unix 下的 lua 解释器可以完全静态链接所有的 lua api ；我们为 lua 扩展的库，以 so 的形式存在被运行时加载不会有任何隐患。而 Windows 下，必须生成一个 luacore 的 DLL 文件，由 lua 解释器于扩展库共享 lua api (还包括 crt 的实现) 才不会出问题。

也因为这个区别，VC 下才会有让 windows 开发新手困惑不解的动态链接 CRT ，静态链接 CRT ，多线程库，单线程库，等等的选项。没点点 windows 开发功力的人，多少都要在上面栽几个跟头。

从动态链接库的这个设计上来看，我个人感觉，Windows 弄的真是糟糕透顶。尤其是对开发者来说是这样。至少我们在 windows 下做一个 dll 文件给大家使用还需要携带一个 .lib 文件；而 unix 下一般只需要有相应的头文件就够了。对于编写新的 .so ，找不到的符号可以就让它在那里，直到最终执行文件来把所有需要的符号联合到一起。windows 可以存在一个 dll 对另一个 dll 的隐式依赖；而 unix 下一般不需要让 so 和 so 有隐式依赖关系。这让我们全局替换类似 CRT 的东西变的困难许多；而以我自己的编程经验来看，好处却没有多少。

顺便一提的是 unix 下需要用 ldconfig 来管理动态库，这比 windows 下 copy DLL 到当前目录下就可以用的方式，无疑提高了系统的安全性。