在架构上，共享对象 (SO) 和动态链接库 (DLL) 有什么区别？

Question

问题几乎就在标题中：就操作系统级别的实现而言，共享对象和 dll 有何不同？

我之所以问这个是因为我最近阅读了this page on extends Python，其中指出：

Unix 和 Windows 使用完全不同的范例来运行时加载代码。在尝试构建可以动态加载的模块之前，请了解您的系统是如何工作的。

在 Unix 中，共享对象 (.so) 文件包含程序要使用的代码，以及它希望在程序中找到的函数和数据的名称。当文件加入程序时，文件代码中对这些函数和数据的所有引用都会更改为指向程序中函数和数据在内存中放置的实际位置。这基本上是一个链接操作。

在 Windows 中，动态链接库 (.dll) 文件没有悬空引用。相反，对函数或数据的访问是通过查找表进行的。因此 DLL 代码不必在运行时固定以引用程序的内存；相反，代码已经使用了 DLL 的查找表，并且查找表在运行时被修改以指向函数和数据。

谁能详细说明一下？具体来说，我不确定我是否理解包含对他们期望找到的内容的引用的共享对象的描述。同样，对我来说，DLL 听起来几乎是相同的机制。

这是对正在发生的事情的完整解释吗？有更好的吗？实际上有什么区别吗？

我知道如何链接到 DLL 或共享对象以及一些用于编写 DLL 的机制（.def 列表、dllexport/dllimport），因此我明确地不寻找这些领域的方法；我对后台发生的事情更感兴趣。

（编辑：另一个明显的观点 - 我知道它们在不同的平台上工作，使用不同的文件类型（ELF 与 PE），与 ABI 不兼容等......）

Answer 1

Dll 与 .so 或 .dylib (MacOS) 文件使用的机制几乎相同，因此很难准确解释它们之间的区别。

核心区别在于每种类型的文件默认可见的内容。 .so 文件导出语言 (gcc) 级链接 - 这意味着（默认情况下）所有“外部”的 C 和 c++ 符号在 .so 被拉入时都可用于链接。 这也意味着，由于解析 .so 文件本质上是一个链接步骤，加载程序并不关心符号来自哪个 .so 文件。它只是按照 .a 文件遵循的通常链接步骤规则以某种顺序搜索指定的 .so 文件。

另一方面，Dll 文件是操作系统功能，完全独立于语言的链接步骤。 MSVC 使用 .lib 文件来链接静态库和动态库（每个 dll 文件生成一个用于链接的配对 .lib 文件），因此生成的程序在构建后是完全“链接”的（从以语言为中心的角度来看） .

然而，在链接阶段，符号在代表 Dll 的 lib 中被解析，允许链接器在 PE 文件中构建导入表，其中包含显式的 dll 列表和每个 dll 中引用的入口点。在加载时，Windows 不必执行“链接”来解析共享库中的符号：该步骤已经完成 - Windows 加载程序只需加载 dll 并直接连接函数。