在32位Windows中,DLL是如何导出的?

在32位Windows中,DLL是如何导出的?

作者:BlogUpdater |  时间:2023-09-11 |  浏览:390 |  评论已关闭 条评论

32 位 Windows 的设计者不必担心将所有内容压缩到 256KB 的内存中。由于 Win32 中的模块基于需求分页,因此你所要做的就是将整个映像映射到内存中,然后运行访问所需的部分。

DLL中的常驻名(resident name)和非常驻名(non-resident name)之间没有区别,导出函数的名称仅存储在 DLL 文件中,并带有指向导出表中存储的名称的指针(即相对虚拟地址)。

与 16 位序号导出表不同,32 位序号导出表不是稀疏的。

例如,如果 DLL 导出两个函数,一个作为序号 10,一个作为序号 1000,你将有一个 991 条目表,该表由两个实际函数指针和大量零组成。
因此,应尽量不要在序号导出中出现较大的间隙,否则将浪费 DLL 的导出表中的空间。

导出的名称表的功能与 16 位 Windows 中导出的名称表相同,将名称映射到序号。
与顺序无关的 16 位命名导出表不同,32 位 Windows 中的导出名称表保持排序,以便可以使用更有效的二进制搜索来查找函数。
与 16 位 Windows 一样,每个命名函数都分配有一个序号。

如果程序员未在模块定义文件中分配一个序号,则链接器将为你创建一个,与 16 位 Windows 一样,链接器构成的值可能因生成而异。

但是,这两种模型之间存在主要区别:回想一下,我们不鼓励在 16 位 Windows 中进行命名导出(出于效率原因),因此,每个导出的函数都被显式分配了一个序号,这是链接到函数的首选方式。

另一方面,32 位 Windows 中的命名导出是常态,没有显式序号分配。这意味着命名导出的序号不是固定的。

例如,让我们看一下早年分配给 kernel32 函数 LocalAlloc 的序数:

现在,有些人习惯于对导入库进行逆向工程,可能是因为他们懒得下载平台SDK并获取真正的导入库。

手动生成导入库的问题在于,你无法判断分配给 LoadLibrary 函数的序号是由模块定义文件分配的(因此不会在生成之间更改)还是仅由链接器自动生成(在这种情况下,序号将更改)。

导入库生成工具可以安全地使用命名导出,因为这在这两种情况下都有效,但由于某种原因,它们使用序号导出。(这可能是 16 位 Windows 的遗留物,正如我们之前看到的,序数优先于名称。)

导入库生成工具的这种设计方式,给 DirectX 团队带来了兼容性问题。(我不知道为什么 DirectX 比其他团队受到的打击更大。也许是因为游戏开发人员没有时间学习 Win32 的细节,他们只是想写他们的游戏吧)

由于他们使用了这些工具之一,他们最终通过序号而不是名称链接到 DirectX 函数,如 DirectDrawCreate,然后当下一个版本的 DirectX 出现并且链接器为名称分配了不同的序号时,他们的程序就会崩溃。

DirectX 团队必须返回到旧的 DLL,记下链接器随机分配的所有序号,并在模块定义文件中显式分配这些序号,以便它们将来不会再修改。

无法从 DLL 生成导入库还有其他原因,稍后,当我更详细地讨论导入库时,我将讨论这些主题。

总结

如果你是在 32 位 Windows 平台上做开发,则始终使用名称,而不是序号进行 DLL 调用,这样会免去很多麻烦。
毕竟,写入到 SDK 中的名称,不太可能随随便便的改变。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一,里面有很多关于Windows的小知识,对于广大Windows平台开发者来说,确实十分有帮助。
本文来自:《How are DLL functions exported in 32-bit Windows?》

最近我写了个东西

正如你们所知道的,拓扑梅尔智慧办公平台(Topomel Box)是一款绿色软件,主要面向经常使用电脑的朋友。它提供了各种提升办公效率的小功能,同时操作上尽可能地简单方便。
我想:你值得拥有。

评论已关闭。