> "By the way, why doesn't mingw include its own runtime libraries?
Because the explicit purpose of mingw (I hope) is to be mostly
compatible with MSVC6 (as long as just C code is concerned), and use
the same C runtime. If mingw used its own runtime, mingw-built code
couldn't in general be reliably called from MSVC6-compiled code, and
vice versa. (For instance things like file descriptors and thus the
FILE structs would be completely incompatible.) This would make mingw
much less useful for people who want to distribute libraries that can
be used both from mingw- and MSVC6-compiled code.
Of course, newer MSVC versions (7, 8, .NET, 2003, 2005, etc) don't
really support building code against msvcrt.dll any longer, so the
above is getting less and less relevant, sigh. Although it does seem
that quite many are hanging on to good'old MSVC6.
What would really rock now would be for somebody to produce a suitably
licensed (MIT or X11-style license) Open Source C runtime for both
mingw and MSVC(6,7,8), and then that most developers/distributors of
Open Source software for Win32 *and* Win64 would be persuaded to use
it. Any volunteers...? One hard thing in such an effort would be to
avoid the temptation of reinventing half of Cygwin, i.e. adding too
> It seems very curious that they reuse the VC versions. How is that
msvcrt.dll is bundled with the operating system.
> Meanwhile, their not giving you source code for the libraries will
> make debgging certain classes of problems quite difficult."
You get the source for (some version of) msvcrt with the Platform
SDK. It is also not hard to find copies (leaked by mistake?) on the