Windows下的MSVCRT就像*nix下的glibc（libc）一样吗？
我经常遇到将 MSVCRT（或其更新的等效项）与程序可执行文件捆绑在一起的 Windows 程序。 在典型的 PC 上，我会发现相同 .DLL 的许多副本。 我的理解是MSVCRT是C运行时库，有点类似于*nix下的glibc/libc.so。
为什么 Windows 程序必须携带它们的 C 库，而不是仅仅共享系统范围的 libc？
更新：感谢 Shog9，我开始阅读有关 SxS 的内容，这进一步让我了解了 DLL 链接问题（DLL Hell） - 链接是对该问题的一个有用的介绍...
I frequently come across Windows programs that bundle in MSVCRT (or their more current equivalents) with the program executables. On a typical PC, I would find many copies of the same .DLL's. My understanding is that MSVCRT is the C runtime library, somewhat analogous to glibc/libc.so under *nix.
Why do Windows programs have to bring along their C libraries with them, instead of just sharing the system-wide libc?
Update: thanks to Shog9, I started to read about SxS, which has further opened up my eyes to the DLL linkage issues (DLL Hell) - Link is one useful intro to the issue...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
[我是 Microsoft Native SxS 技术的当前维护者]
新版本的 MSVCRT 与新版本的 Visual Studio 一起发布，并反映了对 C++ 工具集的更改。 为了使在特定版本的 Windows 继续后发布的 VS 版本编译的程序可以在下层工作（例如 Windows XP 上的 VS 2008 项目），MSVCRT 是可重新分发的，因此可以安装在那里。
CRT 安装会将库放入 %windir%\winsxs\，这是一个全局系统位置，需要管理员权限才能执行此操作。
由于某些程序不想附带安装程序，或者不希望用户需要计算机上的管理员权限才能运行其安装程序，因此它们将 CRT 直接捆绑在与应用程序相同的目录中，以供私人使用。 因此，在典型的计算机上，您会发现许多程序都选择了此解决方案。
[I'm the current maintainer of the Native SxS technology at Microsoft]
New versions of MSVCRT are released with new versions of Visual Studio, and reflect changes to the C++ toolset. So that programs compiled with versions of VS released after a particular version of Windows continue can work downlevel (such as VS 2008 projects on Windows XP), the MSVCRT is redistributable, so it can be installed there.
CRT installation drops the libraries into %windir%\winsxs\, which is a global system location, requiring administrator privileges to do so.
Since some programs do not want to ship with an installer, or do not want the user to need administrator privileges on the machine to run their installer, they bundle the CRT directly in the same directory as the application, for private use. So on a typical machine, you'll find many programs that have opted for this solution.
Windows 中并不存在真正的“系统范围的 libc”。
在 *nix 中，通常有一个编译器、一个链接器，以及良好定义的目标文件格式、调用约定和名称修改规范。 这些东西通常是操作系统附带的。 编译器的半特殊状态（加上对不同 *nix 之间的可移植性的强调）意味着某些东西可以预期存在，并且以程序可以进行命名和/或版本化的方式进行。轻松找到并使用它。
在 Windows 中，事情更加分散。 操作系统不附带编译器，因此人们需要拥有自己的编译器。 每个编译器都提供自己的 CRT，它可能具有也可能不具有与 MSVCRT 相同的功能。 关于调用约定或名称应如何在库中出现也没有一个真正的规范，因此不同的编译器（具有不同的处理方式）可能难以在库中查找函数。
顺便说一句，这个名字应该是一个线索； MSVCRT 是“MicroSoft Visual C++ RunTime”的缩写。 它并不是真正的“系统范围”库，就像
kernel32一样 - 它只是 MS 编译器使用的运行时库，他们可能在构建 Windows 时使用它。 可以想象其他编译器可以链接到它，但是（1）可能存在许可问题； (2) 编译器会将他们的代码与微软的代码捆绑在一起——这意味着(2a) 他们将不再有任何方法添加到运行时或修复错误，除非希望微软能够修复它们； (2b) 如果 MS 决定更改 RTL 中的内容（他们可以随意执行此操作，并且可能在每个新版本的 VC++ 中都有更改）或名称的显示方式，那么其他程序可能会崩溃。There isn't really a "system-wide libc" in Windows.
In *nix, there's generally one compiler, one linker, and with them a well-defined object file format, calling convention, and name mangling spec. This stuff usually comes with the OS. The compiler's semi-special status (plus an emphasis on portability across different *nixes) means that certain stuff can be expected to be there, and to be named and/or versioned in such a way that programs can easily find and use it.
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,
kernel32is -- 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.程序与特定版本的运行时链接，并且无法保证所需版本存在于目标计算机上。 此外，匹配版本曾经是一个问题。
在 Windows 世界中，期望用户出去寻找并安装单独的库来使用您的应用程序是非常不礼貌的。 您确保您的应用程序中包含不属于主机系统的任何依赖项。
在 Linux 世界中，这并不总是那么简单，因为主机系统的外观可能存在更大的变化。
Programs are linked against a specific version of the runtime, and that required version is not guaranteed to exist on the target machine. Also, matching up versions used to be problematic.
In the Windows world, it's very bad manners to expect your users to go out and find and install a separate library to use your application. You make sure any dependencies not part of the host system are included with your app.
In the linux world this isn't always as simple, since there's a much larger variation for how the host system might look.
简短的回答？ 因为，直到 SxS，MSVCRT 都没有可靠的版本！ 您能想象如果针对 libc 5 编译和测试的程序默默地开始使用 libc 6 会导致多么疯狂的结果吗？ 这就是我们多年来在 Windows 上遇到的情况。 我们大多数人都不会再相信微软会不断对版本进行重大更改
Short answer? Because, up until SxS, MSVCRT was not reliably versioned! Can you imagine the madness that would result if programs compiled and tested against libc 5 would silently start using libc 6? That's the situation we were in for many years on Windows. Most of us would just as soon never again trust MS with keeping breaking changes out of a version