我经常遇到 Windows 程序将 MSVCRT（或其更新的等效程序）与程序可执行文件捆绑在一起。在典型的 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 是对该问题的一个有用的介绍...
【问题讨论】：
[我是微软 Native SxS 技术的当前维护者]
新版本的 MSVCRT 与新版本的 Visual Studio 一起发布，反映了对 C++ 工具集的更改。为了使使用特定版本的 Windows 继续发布后发布的 VS 版本编译的程序可以在下层工作（例如 Windows XP 上的 VS 2008 项目），MSVCRT 是可再分发的，因此可以安装在那里。
CRT 安装将库放入 %windir%\winsxs\，这是一个全局系统位置，需要管理员权限才能执行此操作。
由于某些程序不希望附带安装程序，或者不希望用户需要机器上的管理员权限才能运行其安装程序，因此他们将 CRT 直接捆绑在与应用程序相同的目录中，以供私人使用。所以在一台典型的机器上，你会发现很多程序都选择了这个解决方案。
【讨论】：
MSVCRT 现在只是作为 Windows 的一部分发布，并且新版本 VC 的运行时具有新的 DLLNAME？
Windows 中并没有真正的“系统范围的 libc”。
在 *nix 中，通常有一个编译器、一个链接器，以及定义良好的目标文件格式、调用约定和名称修改规范。这些东西通常随操作系统一起提供。编译器的半特殊状态（加上对跨不同 *nix 的可移植性的强调）意味着某些东西可以预期在那里，并以程序可以进行命名和/或版本化的方式轻松找到并使用它。
在 Windows 中，事情更加分散。编译器不随操作系统一起提供，因此人们需要拥有自己的编译器。每个编译器都提供自己的 CRT，它的功能可能与 MSVCRT 相同，也可能不同。也没有关于调用约定或名称应如何出现在库中的真正规范，因此不同的编译器（具有不同的处理方式）可能难以在库中查找函数。
顺便说一句，这里的名字应该是一个线索； MSVCRT 是“MicroSoft Visual C++ RunTime”的缩写。它并不是真正的“系统范围”库，就像kernel32 那样——它只是 MS 编译器使用的运行时库，他们可能在构建 Windows 时使用了它。可以想象其他编译器可以链接到它，但是（1）可能存在许可问题； (2) 编译器会将他们的代码与 MS 绑定在一起——这意味着 (2a) 他们将不再有任何方法可以添加到运行时或修复错误，除非希望 MS 能够修复它们； (2b) 如果 MS 决定更改 RTL 中的内容（他们可以随意更改，并且可能在每个新版本的 VC++ 中都有），或者名称的显示方式，其他程序可能会中断。
【讨论】：
简短回答？因为在 SxS 之前，MSVCRT 没有可靠的版本化！你能想象如果针对 libc 5 编译和测试的程序会默默地开始使用 libc 6 会导致多么疯狂吗？这就是我们多年来在 Windows 上的情况。我们中的大多数人很快就会不再相信 MS 会在版本中保留重大更改
【讨论】：
程序与运行时的特定版本相关联，并且该所需版本不保证存在于目标计算机上。此外，匹配版本曾经是个问题。
在 Windows 世界中，期望您的用户出去寻找并安装一个单独的库来使用您的应用程序是非常不礼貌的。您确保所有不属于主机系统的依赖项都包含在您的应用中。
在 linux 世界中，这并不总是那么简单，因为主机系统的外观可能会有更大的变化。
【讨论】：