msvcrt - Windows 下的 MSVCRT 是否像 *nix 下的 glibc (libc)？

Question

我经常遇到与程序可执行文件捆绑在 MSVCRT(或它们更当前的等价物)中的 Windows 程序。在典型的 PC 上，我会找到许多相同 .DLL 的副本。我的理解是 MSVCRT 是 C 运行时库，有点类似于 *nix 下的 glibc/libc.so。

为什么 Windows 程序必须随身携带他们的 C 库，而不仅仅是共享系统范围的 libc？

更新:感谢 Shog9，我开始阅读有关 SxS 的文章，这进一步让我看到了 DLL 链接问题 (DLL Hell) - http://blogs.msdn.com/b/martynl/archive/2005/10/13/480880.aspx是对这个问题的一个有用的介绍......

Answer 1

Windows 中并没有真正的“系统范围的 libc”。

在 *nix 中，通常有一个编译器、一个链接器，以及定义良好的目标文件格式、调用约定和名称修饰规范。这些东西通常随操作系统一起提供。编译器的半特殊状态(加上强调跨不同 *nixes 的可移植性)意味着可以预期某些东西在那里，并以程序可以轻松找到和使用它的方式命名和/或版本化。

在 Windows 中，事情更加分散。编译器不随操作系统一起提供，因此人们需要拥有自己的编译器。每个编译器都提供自己的 CRT，它可能具有或不具有与 MSVCRT 相同的功能。也没有关于调用约定或名称应如何出现在库中的真正规范，因此不同的编译器(具有不同的处理方式)可能难以在库中查找函数。

顺便说一句，这里的名字应该是一个线索； MSVCRT 是“MicroSoft Visual C++ RunTime”的缩写。它不是真正的“系统范围”库，就像 kernel32 那样。是——它只是 MS 的编译器使用的运行时库，他们大概在构建 Windows 时使用了它。可以想象其他编译器可以链接到它，但是(1)可能存在许可问题； (2) 编译器会将他们的代码与 MS 绑定(bind)在一起——这意味着 (2a) 他们将不再有任何方法可以添加到运行时或修复错误，除非希望 MS 能够修复它们； (2b) 如果 MS 决定更改 RTL 中的内容(他们可以随意更改，并且可能在每个新版本的 VC++ 中都有)，或者名称的显示方式，其他程序可能会中断。