为什么将 C++ 库作为 Windows 的本机 DLL 发布？

Question

编辑：这个问题最初提出的方式并没有让我在讨论中寻找的内容那么明显。这里发布了一个新问题：将 Windows 上的 native-DLL 复制到可执行目录如何共享代码？

我很欣赏下面其他人贡献的想法。最初的问题是考虑到 Windows 上的约定是将 DLL 复制到可执行目录，DLL 相对于静态库有什么好处。虽然我认为 Linux 中的某些功能可以更轻松地维护不同目录中的库，但这不是问题的重点，而且我们陷入了争论，而这并不是我的本意，所以我发布了新的内容.

Answer 1

这确实是您的错误假设：DLL 不需要与使用它的可执行文件位于同一文件夹中。 Windows 上的替代方案是：

• 所有应用程序都可以使用位于

  PATH

  环境变量中列出的文件夹中的 DLL。
  这就是计算机上的多个应用程序通常可以同时访问 DLL 的方式。
• 如果应用程序在显式设置的路径中查找所需的 DLL。
  后一个选项是通过 SetDllDirectory 函数完成的。

这回答了问题的“如何”部分：消费者可以选择是否更喜欢管理给定的库，方法是将其复制到使用该库的每个可执行文件旁边，或者通过更新

PATH

。一般来说，越是核心的DLL，就越有可能被更新

PATH

。

---

现在回答“为什么你更喜欢共享库：它可以节省磁盘空间确实是一个历史原因，现在已经无关紧要了。

然而，在某些情况下，共享库有助于实现静态库无法实现的目标：例如，维护 DLL 的“二进制兼容”版本非常有意义，特别是从系统/网络管理的角度来看。根据定义，静态库不存在二进制兼容性，因为可执行文件需要重新编译。
就像上面一样，DLL 越核心，维护跨版本的兼容性就越有用。 如果您的库被例如使用单个系统上有 50 个应用程序和/或如果您的库由销售软件的第三方使用，

能够纠正安全问题，而无需重新编译 50 个应用程序或无需等待第三方升级其可执行文件

是一个很大的优势，原因显而易见。
实现这一点需要大量的技术知识，但绝对有用。

不确定是否正确回答您的问题。

Answer 2

从历史的角度来看

我想我们有：

静态链接（甚至系统库的各种副本）

动态链接（尽量避免库的副本、需要更少的空间等）
动态库无处不在，甚至是 macOS 应用程序包的副本（我毫不怀疑这对于 Windows 来说几乎是一样的）。 Mac OS 甚至不允许静态链接整个可执行文件。
3. 在时间 2 出现了一个问题：管理版本和依赖项。据我们所知，一团糟。

在时间 3 时，应用程序包是独立的，因此您可以安全地删除应用程序，而无需每次都询问“我是否也需要删除一些无用的外部库”？所有内容都包含在一个唯一的目录中（大致）。

一些可能的理由。

一些库是通用的，这些库可以为了一致性、更小的内存占用等优点而共享。想想像 ffmpeg 这样的东西，它提供了一个库来操作流。因此，最好构建一个 DLL，以便许多其他软件依赖于它的单一安装并在运行时共享代码。当然，这不是必需的，您可以使用自己的 ffmpeg lib 副本（静态或非静态）来分发应用程序。

我不知道它在 Windows 下是如何工作的，但 MacOS 应用程序的结构是捆绑包，其中包含几乎所有“私有”框架/库。您可能认为这与静态库没有什么不同，这几乎是正确的，但应用程序不是单个可执行文件。应用程序可以通过用户界面调用它的多种方式提供不同的执行模式（运行完整的应用程序、将其用作系统服务、快速查找功能、自动化插件等）。因此，共享这个“应用程序”的库代码确实有意义。这也让应用程序的更新只考虑它的一部分（一些库/框架、一些可执行文件等）。

最后，惰性链接是共享库的好处之一：除非有必要，否则不要考虑链接（推迟运行时的“真正”链接），即使一个好的操作系统可能不会加载所有代码一次但按需（延迟加载代码）。