Is MSVCRT under Windows like glibc (libc) under *nix?

Question

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 t

Answer 1

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.

Answer 2

[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.

Answer 3

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, 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.

Answer 4

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