Thread view

Hello all,
I remember reading here that everyone believes msvcrt.dll to be
reasonably everywhere (that is, in every Windows system); still, I
can’t remember ever reading why crtdll.dll was ever supported in the
first place.
(I hope I’m not wrong in remembering that recent mingw-gcc produces
binaries that link by default to msvcrt, as I can’t test that now.)
In case I’m not the only one wondering about this, I found a quite
detailed list of DLLs shipped with “clean” Windows versions (I assume
many didn’t ship with IE, from 95 backwards):
http://www.bearwindows.boot-land.net/dllhell.htm
I’m not yet raising questions about whether mingw should get back to
using crtdll, for I believe there were good reasons to do so despite
the potential dropping support for abandoned (never updated and never
infected by IE) Windows installations.
--
R

On 2009-11-18 11:29Z, Raffaello D. Di Napoli wrote:
>
> I remember reading here that everyone believes msvcrt.dll to be
> reasonably everywhere (that is, in every Windows system); still, I
> can’t remember ever reading why crtdll.dll was ever supported in the
> first place.
http://programming.ccp14.ac.uk/ftp-mirror/programming/mumit-khan/pub/khan/egcs/mingw32/egcs-1.1.1/README.msvcrt40
|
| File: README.msvcrt40
| Last Updated: Fri Jan 1 20:29:29 CST 1999
| =====================================================================
|
| If you want egcs-1.1.1/mingw32 to produce executables that use MSVCRT40
| instead of the default CRTDLL, then you should be able to use the
| runtime replacement components in egcs-1.1.1-msvcrt40-runtime.zip to
| do just that.
Windows 95 OSR2, released 1996-08-24, included 'msvcrt.dll';
for releases prior to OSR2, you could get that dll by upgrading
the builtin browser, at no charge. But not everyone had done so,
and some people were still running 'win32s' under Windows 3.1;
therefore the older and less capable 'crtdll.dll' was the MinGW
default in that era.
> I’m not yet raising questions about whether mingw should get back to
> using crtdll, for I believe there were good reasons to do so despite
> the potential dropping support for abandoned (never updated and never
> infected by IE) Windows installations.
http://www.cygwin.com/ml/cygwin/2001-03/msg01162.html
|
| > PS: For my curiosity, what are the reasons for switching from CRT to MSVC ?
|
| The reason is that CRTDLL is deprecated. It was created for Win95
| version 1. Microsoft changed to MSVCRT with Win95 version 2. I polled
| this list before the change was made. No one spoke against the change.
If you're still using an OS older than windows 95 OSR 2, and don't
want to install the ms browser (or the OS), then you can probably
find a copy of 'msvcrt.dll' on the web. You might want to consider
GNU/Linux as an alternative.

2009/11/18 Greg Chicares <gchicares@...>:
>
> Windows 95 OSR2, released 1996-08-24, included 'msvcrt.dll';
> for releases prior to OSR2, you could get that dll by upgrading
> the builtin browser, at no charge. But not everyone had done so,
> and some people were still running 'win32s' under Windows 3.1;
> therefore the older and less capable 'crtdll.dll' was the MinGW
> default in that era.
So, “less capable” answers my question on why msvcrt was considered
superior to crtdll.
I guess the lessening of installations share of Win32s and Win95
pre-OSR2 (and the increase in adoptions of IE) gave sort of a green
light to the replacement.
> If you're still using an OS older than windows 95 OSR 2, and don't
> want to install the ms browser (or the OS), then you can probably
> find a copy of 'msvcrt.dll' on the web. You might want to consider
> GNU/Linux as an alternative.
Oh, I was just asking out of curiosity, mostly because I accidentally
run into the page I mentioned in the opening post. Otherwise, I use
Gentoo Linux :)
Thank you for the very detailed and quick anwer,
--
R

Quoting "Raffaello D. Di Napoli" <raffaellod@...>:
> Hello all,
> I remember reading here that everyone believes msvcrt.dll to be
> reasonably everywhere (that is, in every Windows system); still, I
> can?t remember ever reading why crtdll.dll was ever supported in the
> first place.
> (I hope I?m not wrong in remembering that recent mingw-gcc produces
> binaries that link by default to msvcrt, as I can?t test that now.)
>
The crtdll.dll was required by the first release of Windows 95 and any
version of Windows prior to it. The second release of Windows 95 used
msvcrt.dll. We supported crtdll.dll because of Windows 95. The
msvcrt.dll is used by default in all compiler versions. You can use a
specific -lcrtdll, -lmsvcr## or -lmsvcr##d, where ## is the version of
msvcrt.dll you want to use and d is the debug enabled version of the
dll, to link to a different version of the runtime. You are only
guaranteed that all environments will contain msvcrt.dll however,
which is why it is used as the default.
HTH,
--
Earnie

2009/11/18 Earnie Boyd <earnie@...>:
> You are only guaranteed that all environments will contain
> msvcrt.dll however, which is why it is used as the default.
Really? You also stated this back when the choice was made (thanks Greg):
http://www.cygwin.com/ml/cygwin/2001-03/msg01162.html
|
| > PS: For my curiosity, what are the reasons for switching from CRT to MSVC ?
|
| The reason is that CRTDLL is deprecated.
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?
I’m asking, because your statement (the guarantee all environments
contain msvcrt) contradicts the link I included in the first post, and
from the material on that same web site, that DLL list has obviously
been put together by someone who knows obsolete Windows versions
*very* well.
By all means, if you can’t remember or don’t care, it’s fine. I’m just
curious to know if there’s *one* C runtime DLL that’s been shipped
with every 32-bit Windows version.
>From what I remember seeing myself, crtdll was still used by Windows
XP’s explorer.exe and quite a few DLLs (but not those part of the
then-called Active Desktop, the main reason msvcrt started being a
staple in Windows installations).
I know this talking about ancient/obsolete software might be pointless
to many, but I’m into retrocomputing and retro-virtualization (and
many virtualizators don’t/no longer provide additions for ancient
OSes, so I might write them at some point).
--
R

2009/11/18 Greg Chicares <gchicares@...>:
> On 2009-11-18 14:59Z, Raffaello D. Di Napoli wrote:
>> [...] I’m just
>> curious to know if there’s *one* C runtime DLL that’s been shipped
>> with every 32-bit Windows version.
>
> According to this message:
> http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/48af4bf3-68c4-4ff4-8700-3ceb2a3c1a71
> 'crtdll.dll' is not present in "Windows 2008 Server Core".
> And versions prior to windows 95 OSR2 didn't provide 'msvcrt.dll'.
> So I suppose the answer to your question would be 'no'.
Uh, I did fear that the shift to .NET would phase out older binaries
from the Windows 95 era.
Most of the binaries I’ve seen introduced since the permanent
embedding of IE in Windows use msvcrt, and I believe that newer
binaries included in Vista are all .NET-based, so I gather this
allowed to get rid of the old crtdll in Vista/2008 Server.
Or maybe they simply migrated older programs to msvcrt.
> This 1996 article might interest you:
> http://www.microsoft.com/msj/archive/S572.aspx
> | I can't see a clean way to produce a program that uses the system-
> | provided C/C++ RTL DLL and that can rely on that DLL being present
> | on all current Win32 platforms.
Well, it was an interesting article indeed, but the reason the author
gives for this statement is that MSVC had stopped (at the time of
writing) shipping an import library for crtdll, so that doesn’t quite
matter to mingw.
Thank you for your precious links, Greg, I really appreciate your and
Earnie’s willingness to help me in getting an answer to my questions.
--
R

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?
--
Earnie

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

Quoting "Raffaello D. Di Napoli" <raffaellod@...>:
> 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.
>
Even though the API may not be, the OS executables are. Try ``grep
-irl msvcrt.dll $WINDIR/system32/*.exe'' to see the list.
--
Earnie