我经常遇到与程序可执行文件捆绑在 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是该问题的一个有用介绍...
[我是微软 Native SxS 技术的当前维护者]
新版本的 MSVCRT 与新版本的 Visual Studio 一起发布，并反映了对 C++ 工具集的更改。因此，使用特定版本的 Windows 继续发布后发布的 VS 版本编译的程序可以在下层工作（例如 Windows XP 上的 VS 2008 项目），MSVCRT 是可再分发的，因此可以安装在那里。
CRT 安装将库放入 %windir%\winsxs\，这是一个全局系统位置，需要管理员权限才能执行此操作。
由于某些程序不希望附带安装程序，或者不希望用户需要机器上的管理员权限才能运行其安装程序，因此他们将 CRT 直接捆绑在与应用程序相同的目录中，以供私人使用。所以在一台典型的机器上，你会发现很多程序都选择了这个解决方案。
Windows 中并没有真正的“系统范围的 libc”。
在 *nix 中，通常有一个编译器、一个链接器，以及定义良好的目标文件格式、调用约定和名称修饰规范。这些东西通常随操作系统一起提供。编译器的半特殊状态（加上强调跨不同 *nixes 的可移植性）意味着可以预期某些东西在那里，并且以程序可以轻松找到和使用它的方式命名和/或版本化。
In Windows, things are more fragmented. A compiler doesn't come with the OS, so people need to get their own. Each compiler provides its own CRT, which may or may not have the same functions in it as MSVCRT. There's also no One True Spec on calling conventions or how names should appear in the libraries, so different compilers (with different ways of doing stuff) might have trouble finding functions in the library.
BTW, the name should be a clue here; MSVCRT is short for "MicroSoft Visual C++ RunTime". It's not really a "system-wide" library in the same way that, say, kernel32 is -- it's just the runtime library used by MS's compilers, which they presumably used when building Windows. Other compilers could conceivably link against it, but (1) there might be licensing issues; and (2) the compilers would be tying their code to MS's -- meaning (2a) they'd no longer have any way to add to the runtime or fix bugs, short of hoping MS will fix them; and (2b) if MS decides to change what's in the RTL (which they can do at will, and probably have in each new version of VC++), or how the names appear, those other programs might break.
简短的回答？因为，在 SxS 之前，MSVCRT没有可靠的版本控制！你能想象如果针对 libc 5 编译和测试的程序会默默地开始使用 libc 6 会导致多么疯狂吗？这就是我们多年来在 Windows 上的情况。我们中的大多数人很快就会再也不相信 MS 会在版本中保留重大更改
程序与特定版本的运行时链接，并且不保证目标机器上存在所需的版本。此外，匹配版本曾经是有问题的。
在 Windows 世界中，期望您的用户出去寻找并安装一个单独的库来使用您的应用程序是非常不礼貌的。您确保任何不属于主机系统的依赖项都包含在您的应用程序中。
在 linux 世界中，这并不总是那么简单，因为主机系统的外观可能会有更大的变化。