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

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.