Windows下的MSVCRT是否像* nix下的glibc(libc)一样?
我经常遇到Windows程序,这些程序将MSVCRT(或者它们的最新版本)与程序可执行文件捆绑在一起。在典型的PC上,我会找到相同.DLL的许多副本。我的理解是MSVCRT是C运行时库,有点类似于* nix下的glibc / libc.so。
为什么Windows程序必须带同他们的C库,而不仅仅是共享系统范围的libc?
更新:感谢Shog9,我开始阅读有关SxS的信息,这进一步打开了我对DLL链接问题(DLL地狱)的视野http://blogs.msdn.com/b/martynl/archive/2005/10/13 /480880.aspx是该问题的一个有用的介绍...
解决方案
程序链接到特定版本的运行时,并且不能保证所需的版本在目标计算机上存在。同样,匹配版本曾经是有问题的。
在Windows世界中,期望用户走出去并找到并安装单独的库以使用应用程序是非常不好的态度。我们确保应用程序包含主机系统之外的所有依赖项。
在linux世界中,这并不总是那么简单,因为主机系统的外观会有很大的变化。
简短的答案?因为直到SxS为止,MSVCRT的版本都不可靠!我们能想象如果针对libc 5进行编译和测试的程序将悄无声息地开始使用libc 6会导致疯狂吗?这就是我们在Windows上使用多年的情况。我们大多数人将永远不会再一次信任MS来保持对版本的重大更改。
[我是Microsoft Native SxS技术的当前维护者]
MSVCRT的新版本与Visual Studio的新版本一起发布,并反映了对C ++工具集的更改。因此,使用特定版本的Windows继续发行后发布的VS版本编译的程序可以在较低级别工作(例如Windows XP上的VS 2008项目),MSVCRT可重新发行,因此可以在那里安装。
CRT安装会将库放入%windir%\ winsxs \,这是一个全局系统位置,需要管理员特权才能这样做。
由于某些程序不想随安装程序一起提供,或者不希望用户需要计算机上的管理员特权才能运行其安装程序,因此它们将CRT直接捆绑在与应用程序相同的目录中,以供私人使用。因此,在典型的计算机上,我们会发现许多选择了此解决方案的程序。