Hello.

I have developed an app on Windows 2000 with Vc++ 6 (service pack 5).
The app needs msvcrt.dll, which on my development machine is
"6.1.9844.0".

(If Im not mistaken windows 95 is the only version of windows which
doesnt ship with msvcrt.dll in the system32 folder..can anybody
confirm this?)

Im not sure whats the best strategy for (not) distributing msvcrt.dll.
Should I always install the msvcrt.dll from my devlopment machine into
my apps folder on the user's machine? Should I only do it if the user
has an older (or no) version in his system32 folder (or %PATH%).
Or should I distribute the newest version of the dll (presumably that
which ships with vista or xp)?

If I do copy msvcrt.dll into my apps folder, will that version always
be used by my app?

On Windows Xp/Vista my app crashes unexpectedly if I put the
msvcrt.dll into the same folder as my app's exe. Everything seems fine
if I dont (so that my app instead uses the version from windows'
system32 dir). Are such crashes to be expected, if is using the
msvcrt.dll from win 2000 machine? And are newer versions always
better, or are the versions which ship from microsoft with each os the
most appropriate (in whihc case what to do with win 95)?

Thanks very much in Advance.

Re: Distributing msvcrt.dll by Anders

Anders
Wed Apr 16 19:48:50 CDT 2008

On Tue, 15 Apr 2008 13:57:39 -0700 (PDT), p8mode <p8mode@gmx.net>
wrote:

> I have developed an app on Windows 2000 with Vc++ 6 (service pack 5).
> The app needs msvcrt.dll, which on my development machine is
> "6.1.9844.0".
>
> (If Im not mistaken windows 95 is the only version of windows which
> doesnt ship with msvcrt.dll in the system32 folder..can anybody
> confirm this?)

do a goole on "breaking changes CRT" check the differences on the CRT

hth/Anders
--
A: People bitching about top-posting

> Q: What's the most annoying thing on USENET?

Re: Distributing msvcrt.dll by Ben

Ben
Thu Apr 17 10:00:42 CDT 2008

> On Windows Xp/Vista my app crashes unexpectedly if I put the
> msvcrt.dll into the same folder as my app's exe. Everything seems fine
> if I dont (so that my app instead uses the version from windows'
> system32 dir). Are such crashes to be expected, if is using the
> msvcrt.dll from win 2000 machine? And are newer versions always
> better, or are the versions which ship from microsoft with each os the
> most appropriate (in whihc case what to do with win 95)?

Many system DLLs use functions from msvcrt.dll. If you loaded an old
version of msvcrt.dll, then the system version can't be loaded (name
collision) and the system DLLs will fail.

>
> Thanks very much in Advance.



Re: Distributing msvcrt.dll by p8mode

p8mode
Mon Apr 21 03:48:42 CDT 2008

On Apr 17, 5:00 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
> > On Windows Xp/Vista my app crashes unexpectedly if I put the
> > msvcrt.dll into the same folder as my app's exe. Everything seems fine
> > if I dont (so that my app instead uses the version from windows'
> > system32 dir). Are such crashes to be expected, if is using the
> > msvcrt.dll from win 2000 machine? And are newer versions always
> > better, or are the versions which ship from microsoft with each os the
> > most appropriate (in whihc case what to do with win 95)?
>
> Many system DLLs use functions from msvcrt.dll. If you loaded an old
> version of msvcrt.dll, then the system version can't be loaded (name
> collision) and the system DLLs will fail.
>
>
>
> > Thanks very much in Advance.

So I shouldn't copy (an old, win2000) version of msvcrt.dll into my
app's folder, since when my app starts (and loads this version), the
other apps wont be able to load the newer version they need, even
though theyre trying to load the one in the system32 folder?

Re: Distributing msvcrt.dll by Ben

Ben
Mon Apr 21 10:45:36 CDT 2008

p8mode wrote:
> On Apr 17, 5:00 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
>>> On Windows Xp/Vista my app crashes unexpectedly if I put the
>>> msvcrt.dll into the same folder as my app's exe. Everything seems
>>> fine if I dont (so that my app instead uses the version from
>>> windows' system32 dir). Are such crashes to be expected, if is
>>> using the msvcrt.dll from win 2000 machine? And are newer versions
>>> always better, or are the versions which ship from microsoft with
>>> each os the most appropriate (in whihc case what to do with win 95)?
>>
>> Many system DLLs use functions from msvcrt.dll. If you loaded an old
>> version of msvcrt.dll, then the system version can't be loaded (name
>> collision) and the system DLLs will fail.
>>
>>
>>
>>> Thanks very much in Advance.
>
> So I shouldn't copy (an old, win2000) version of msvcrt.dll into my
> app's folder, since when my app starts (and loads this version), the
> other apps wont be able to load the newer version they need, even
> though theyre trying to load the one in the system32 folder?

It's not "other apps", this doesn't affect them at all. It's the system
libraries your own application relies on that will fail to work if an old
version of msvcrt.dll is loaded into your process, as Windows only allows
one copy of a library with a particular name to be loaded at once.



Re: Distributing msvcrt.dll by p8mode

p8mode
Tue Apr 22 02:24:08 CDT 2008

Thanks for the helpful insight and information.

> Windows only allows
> one copy of a library with a particular name to be loaded at once.

Would you possibly be able to point me to somewhere in msdn where this
is documented?


Re: Distributing msvcrt.dll by Ben

Ben
Tue Apr 22 08:36:19 CDT 2008

p8mode wrote:
> Thanks for the helpful insight and information.
>
>> Windows only allows
>> one copy of a library with a particular name to be loaded at once.
>
> Would you possibly be able to point me to somewhere in msdn where this
> is documented?

http://msdn2.microsoft.com/en-us/library/ms684175(VS.85).aspx
If lpFileName does not include a path and there is more than one loaded
module with the same base name and extension, the function returns a handle
to the module that was loaded first.


This applies to all static imports, AFAIK the import table never contains a
path to the DLL.