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

[我是微软Native SxS技术的当前维护者]

新版本的MSVCRT随新版本的Visual Studio一起发布，并反映了对C ++工具集的更改。因此，在特定版本的Windows继续发布后，使用VS版本编译的程序可以向下运行（例如Windows XP上的VS 2008项目），MSVCRT是可再发行的，因此可以在那里安装。

CRT安装将库放入％windir％\ winsxs \，这是一个全局系统位置，需要管理员权限才能执行此操作。

由于某些程序不希望随附安装程序，或者不希望用户在计算机上需要管理员权限来运行其安装程序，因此它们将CRT直接捆绑在与应用程序相同的目录中，供私人使用。因此，在典型的机器上，您会发现许多程序都选择了此解决方案。

Answer 2

实际上没有“系统范围的libc”。在Windows中。

在* nix中，通常有一个编译器，一个链接器，并且它们具有明确定义的目标文件格式，调用约定和名称修改规范。这个东西通常附带操作系统。编译器的半特殊状态（加上强调跨不同* nixes的可移植性）意味着某些东西可以期望存在，并以程序可以这样的方式命名和/或版本化很容易找到并使用它。

在Windows中，事情更加分散。编译器没有附带操作系统，因此人们需要获得自己的操作系统。每个编译器都提供自己的CRT，它可能与MSVCRT具有相同或不同的功能。调用约定或名称应如何出现在库中也没有One True Spec，因此不同的编译器（使用不同的方式）可能无法在库中查找函数。

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

Answer 3

简短回答？因为，直到SxS，MSVCRT 无法可靠地版本化！你能想象如果针对libc 5编译和测试的程序会默默地开始使用libc 6会导致疯狂吗？这就是我们在Windows上多年的情况。我们中的大多数人很快就再也不会相信MS会在版本中保持更改

Answer 4

程序与特定版本的运行时链接，并且所需的版本不保证在目标计算机上存在。此外，匹配版本曾经是有问题的。

在Windows世界中，期望用户外出并查找和安装单独的库以使用您的应用程序是非常不礼貌的。您确保应用程序中包含不属于主机系统的任何依赖项。

在Linux世界中，这并不总是那么简单，因为主机系统的外观变化要大得多。