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

我经常遇到与程序可执行文件捆绑在一起的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中,通常有一个编译器,一个链接器,并且它们具有明确定义的目标文件格式,调用约定和名称修改规范.这个东西通常附带操作系统.编译器的半特殊状态(加上强调跨不同*nix的可移植性)意味着可以预期某些东西存在,并且以程序可以轻松找到并使用它的方式命名和/或版本化.

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

顺便说一句,这个名字应该是一个线索; 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,不断改变版本