Can someone explain how msvcrt.dll versioning is supposed to work?
As near as I can tell, there are many versions of it versions 1 through
7 corresponding with the MSVC release of the same version. Some of
these come packaged with Windows or Explorer or other MS tools.
Applications, seemingly at random, either install and bind to a specific
major version named msvcrtXX.dll, or upgrade the system's msvcrt.dll to
their version, and just use that.
There also seem to be several different popular minor versions with the
same major version number of msvcrt.dll, that export different and
apparently mutually incompatible sets of symbols! (Later versions
remove some symbols [although possibly unuseful] as well as add.)
There appear to be some programs still using msvcrt10.dll, but I don't
know if they are using it with the msvcrt.dll name.
The lowest version of msvcrt.dll I can find in the wild coming from
system software is 220.127.116.1138.
What is unfortunate here is that mingwrt's msvcrt.def contains some
names that are not in this DLL's exports.
Adding to the confusion are these msvcrXX.dll files which seem to have
superceded msvcrtXX.dll, but seem to be the same thing, mysteriously
missing the 't'.
Also, and its come up before, mingwrt deliberately omits C++ symbols and
other things that do not have an obvious purpose.
It seems reasonable to me that the default import library for msvcrt.dll
should only have symbols that there is some garentee everyone will have.
As with other versioned libraries, people should have to ask for more
to get more. Perhaps additional msvcrt .def's should be created to
match the different msvcrt.dll variants, and msvcrt.dll made to be the
least common denominator?
I also think there should be some consideration of adding all symbols,
in particular, the C++ symbols, in msvcrt.dll to the import library.
While mingwrt does not use these symbols, they are in fact in the DLL,
and they are occasionally useful, in the case where the user links to
MSVC C++ exporting a C interface, which is quite common. In some cases
their absense causes a link failure where otherwise the mingw tools
might work flawlessly. There is also no possibility of conflict, as the
C++ symbols do not have a leading underscore.
Can someone fill in any holes here? Any comments on my two suggestions?
Aaron W. LaFramboise