2009/11/19 Earnie Boyd <earnie@...>:
> Quoting "Raffaello D. Di Napoli" <raffaellod@...>:
>> Was there ever any explicit such statement from Microsoft? Or you (or
>> whoever else) simply inferred that because msvcrt started being
>> ubiquitous, and having a superset of the crtdll functions, it was
>> assumed to be its replacement?
>
> Isn't the Windows API dependent on MSVCRT.DLL?
I’m honestly not sure what to answer. I was going to answer “no”, but
I wanted to support my answer with some actual proof, and... well, at
least on Windows XP (the only OS I’ve available right now, since my
old virtualized Windows 98 is in maintenance), it does look like no
DLLs (I tried about 15) depend on crtdll.dll anymore.
Looking at any core Win32 API DLL, so those implementing the set of
functions that have been part of Win32 ever since, so HeapAlloc,
ZeroMemory, CreateThread, CloseHandle and so on, there’s no dependency
on either: they use ntdll.dll instead (which is pretty much the only
dependency of msvcrt.dll), as that does provide something similar to
the C runtime, and all of its functions are either contained in it or
forwarded to a system call.
For example, advapi32.dll (advanced API: registry, security, ...)
depends, both directly and indirectly, on ntdll.dll only (going
through kernel32.dll and a few others).
Things change if you include the myriad of DLLs that are de facto part
of Microsoft Windows, but are actually dependencies of Internet
Explorer and its Active Desktop. So, for shlwapi.dll (shell
lightweight API, introduced of course with and for the Active
Desktop), msvcrt.dll is indeed a dependency.
Also, it looks like Microsoft, at least from Windows XP on, did start
replacing crtdll.dll with msvcrt.dll.
Take comctl32.dll: looking at the pre-XP version (latest was 5.82 -
it’s the last version you’ll see sitting in XP’s system32), you’ll
find no C runtime imports from any library, except RtlUnwind from
ntdll.dll; if you take the assembly from SxS, version 6 (that’s why
you need a manifest file to have XP load it instead of the one in
system32), you’ll find it does depend on msvcrt.dll - for 5 functions,
like memmove and wcslen... it’s a very silly dependency.
So, while msvcrt.dll did start, as its name implies, as the runtime
for Microsoft Visual C, it has found its way into many of the least
critical system DLLs (that is, many of them); even its embedded
version info, reports “Windows NT CRT DLL”. So the answer could be:
from Windows XP onwards, certainly. Before that... I don’t know, and
back to Windows 98, probably not quite.
Actually, it looks like DLLs in XP are quite different from what
probably used to be in previous Windows versions: I took a look at
msvcrt40.dll, and I’m sure “VC 4.x CRT DLL (Forwarded to msvcrt.dll)”
is not quite the version info string it used to bear in its original
release - even the version number, 5.1.2600.2180, is the same as XP,
but curiously enough msvcrt.dll doesn’t follow suit, sporting version
7.0.2600.2180 - an interesting mixture of major+minor and
revision+build numbers, uh?
As a last note, it’s also quite interesting that many of the Windows
binaries depending on msvcrt.dll, only need it for
__exception_handler3. Everything else they use, dependency after
dependency, turns out to be only ntdll.dll (which is the only one
kernel interface, or libc if you want).
Sorry for the overlong post,
--
R
|
