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

Architecturally what is the difference between a shared object (SO) and a dynamic link library (DLL)?

提问by

The question is pretty much in the title: in terms of OS-level implementation, how are shared objects and dlls different?

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

The reason I ask this is because I recently read this pageon extending Python, which states:

我问这个的原因是因为我最近阅读了有关扩展 Python 的页面，其中指出：

Unix and Windows use completely different paradigms for run-time loading of code. Before you try to build a module that can be dynamically loaded, be aware of how your system works.

In Unix, a shared object (.so) file contains code to be used by the program, and also the names of functions and data that it expects to find in the program. When the file is joined to the program, all references to those functions and data in the file's code are changed to point to the actual locations in the program where the functions and data are placed in memory. This is basically a link operation.

In Windows, a dynamic-link library (.dll) file has no dangling references. Instead, an access to functions or data goes through a lookup table. So the DLL code does not have to be fixed up at runtime to refer to the program's memory; instead, the code already uses the DLL's lookup table, and the lookup table is modified at runtime to point to the functions and data.

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

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

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

Could anyone elaborate on that? Specifically I'm not sure I understand the description of shared objects containing references to what they expect to find. Similarly, a DLL sounds like pretty much the same mechanism to me.

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

Is this a complete explanation of what is going on? Are there better ones? Is there in fact any difference?

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

I am aware of how to link to a DLL or shared object and a couple of mechanisms (.def listings, dllexport/dllimport) for writing DLLs so I'm explicitly not looking for a how to on those areas; I'm more intrigued as to what is going on in the background.

我知道如何链接到 DLL 或共享对象以及一些用于编写 DLL 的机制（.def 列表、dllexport/dllimport），所以我没有明确地在这些方面寻找方法；我对背景中发生的事情更感兴趣。

(Edit: another obvious point - I'm aware they work on different platforms, use different file types (ELF vs PE), are ABI-incompatible etc...)

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

采纳答案by Chris Becke

A Dll is pretty much the same mechanism as used by .so or .dylib (MacOS) files, so it is very hard to explain exactly what the differences are.

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

The core difference is in what is visible by default from each type of file. .so files export the language (gcc) level linkage - which means that (by default) all C & c++ symbols that are "extern" are available for linking when .so's are pulled in. It also means that, as resolving .so files is essentially a link step, the loader doesn't care which .so file a symbol comes from. It just searches the specified .so files in some order following the usual link step rules that .a files adhere to.

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

Dll files on the other hand are an Operating system feature, completely separate to the link step of the language. MSVC uses .lib files for linking both static, and dynamic libraries (each dll file generates a paired .lib file that is used for linking) so the resulting program is fully "linked" (from a language centric point of view) once its built.

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

During the link stage however, symbols were resolved in the lib's that represents the Dlls, allowing the linker to build the import table in the PE file containing an explicit list of dlls and the entry points referenced in each dll. At load time, Windows does not have to perform a "link" to resolving symbols from shared libraries: That step was already done - the windows loader just loads up the dll's and hooks up the functions directly.

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