c++ - 导入库如何工作以及为什么 MinGW 不需要它们？

Question

我查看了这个页面:An In-Depth Look into the Win32 Portable Executable File Format

它解释了链接器需要导入库，因为编译器无法区分正常函数调用和 API 函数调用。但他们还说 __declspec(dllimport) 将函数调用指定为 API 调用，因此链接器链接到 __imp_[<em>function-name</em>] . 但是有了这个关键字，编译器应该知道这是对 API 函数的调用。

为什么链接器还需要导入库？编译器可以通过在 __imp_ 之前标记此符号为已导入到函数名称并可以调用函数指针(这是一个尚未解析的符号)并且链接器可以用 IAT 条目的地址替换这个符号(因为它认为这是一个 API 调用)。

为什么 MinGW 链接器可以直接使用“MinGW-DLLs”而 Visual-Studio 链接器需要一个导入库？

当我阅读帖子时，还提出了一些其他问题。在完成与最终可执行文件的链接之前，“dlltool(或链接器)”(创建导入库的那个)如何知道 IAT 条目的位置？我认为 IAT 条目将在链接时与最终可执行文件一起构建。该帖子说，每个 API 调用在 IAT 表中都有一个固定位置，不管将链接多少个 DLL。我无法想象那是如何实现的。

Answer 1

正如 MinGW 清楚地展示的那样，可以在没有导入库的情况下链接到 DLL。因此，问题是为什么 MSVC 决定省略此功能。

主要是历史原因。

那时是 1983 年，当 Windows 出现并且设计 DLL 时，有许多来自不同供应商的工具链(编译器、链接器)。要求供应商实现对少数操作系统链接“DLL”的支持显然不是一种选择。

因此他们决定编写一个工具来生成每个人和他们的狗都可以链接的库，即使链接器完全不知道 DLL。

此外，导入库提供了一些在 3 年前非常重要但现在几乎已过时的功能。首先是按序号导入符号的能力——即 DLL 可以选择不提供任何名称，只提供地址列表；序号是此列表中的索引。当 RAM 数量受到严重限制时才有意义。

其次是对不同名称修改方案的支持。即使在 C 中也有一个名称修改方案，例如 FooBar 可能变成 _FooBar@4 (这取决于平台和调用约定)。对于 DLL 来说，在每个支持的平台上导出“FooBar”以保持一致性是非常有意义的(并且它使 GetProcAddress() 用户的生活更轻松)。导入库实现了_FooBar@4到FooBar的映射。

这是基于从一开始就参与 Windows 开发的 Raimond Chen 的博客(1，2)。