Warning msvcrt.dll is no longer redistributeable!!! Will cause win 95/98 to crash!

[Dave]

Apparently Microsoft seems to have changed the rules for this file and it is
no longer redistributeable. If you try to take the new one that comes with
VS.NET (on say an XP machine) and use that to install with your app it will
crash Win 95/98 machines. I think this is a HUGE mistake on microsofts part
as this .dll has been fully backward compatible for years and standard
operating procedure for years has been if you get a new version or update to
the visual studio tool then you need to get the new msvcrt.dll file along
with mfcXX.dll for redistribution.

If this file is replaced with the newer one Win 98 tells users to re-install
windows!

I think there is a similar problem with msvcp60.dll but less so than
msvcrt.dll. I was asked why not rebuild completely with vs.net to avoid the
need for older files, but I use old components I don't have control over.

I think MS will end up getting lots of issues with this as more vendors
migrate their apps and discover this.

The way to get around this at the moment is to make sure you only install
the older versions of msvcrt.dll this way it won't overwite the new one and
should be fine for older systems.

I think it was bad policy to make this file non-backward compatible given
the history for this file. Microsoft should have renamed the file if they
didn't want to make the new one backward compatible.

You could say do a side by side install.. well that won't work well on the
older win 95/98 operating systems I think..(maybe it will, but as I said the
standard operating procedure was to not worry about this file since it was
always backward compatible.) Now we have to worry about it a bit.

[Tomas Restrepo [MVP]]

Dave,

> Apparently Microsoft seems to have changed the rules for this file and it
is
> no longer redistributeable. If you try to take the new one that comes
with
> VS.NET (on say an XP machine) and use that to install with your app it
will
> crash Win 95/98 machines.

VC++.NET compiled applications don't use msvcrt.dll. What you're trying to
do, likely, is install the XP version of the library in WIn98, which won't,
of course, work. So it's pretty much your fault.

Now, msvcrt.dll is considered a system component you should NOT update.
Leave that to MS.

The new CRT DLL is, indeed, not backward compatible, and they DID rename it!
The correct CRT DLL for VC++.NET apps is called msvcrt7.dll, and that's the
one you should distribute with your apps. Keep in mind you want to install
it in your apps directory, and not in the windows system directory.

--
Tomas Restrepo
tom...@mvps.org

[Ted]

There are other DLLs like that (e.g. oleaut32.dll, olepro32.dll,
stdole2.tlb, and asycfilt.dll version 3.50 that come with Windows XP) that
should NOT be installed on any other platform. It's easy to make the
mistake, e.g. Microsoft's own package and deployment wizard will grab newer
versions of system files without hestitation and include them in your setup.
There should at least be a KB article on this issue, which there still
hasn't been (remember the "incompatible verion of the RPC stub" fiasco?)

I sympathize with you, however, it's just an issue that you will have to
learn about and find which DLLs from Windows XP that will break other
operating systems. Sometimes you will have to grab earlier versions of
those DLLs from the target OSes themselves.

Ted.

"Dave" <ju...@junkmail.com> wrote in message
news:uprelzf3BHA.2292@tkmsftngp07...

[Mark Jordan]

"Dave" <ju...@junkmail.com> wrote in message
>

> I think MS will end up getting lots of issues with this as more vendors
> migrate their apps and discover this.
>

Yes, I agree, I've just finished rebuilding about 12 dll
libraries at work for a huge genomics package. There were
some really strange things going on where some dlls were
using the old runtime, and others using the new one. Luckily
I have control over all the libraries. I don't know what
I would have done otherwise.

Cheers,
Mark.

[Dave]

The point is people have for years always grabbed the latest msvcrt.dll and
distributed it as needed. It is new to VS.NET that this is not needed and
it is new that windows XP includes a system version with the same name as
the original redistributeable one that is not backward compatible. MS
should not have created any versions of msvcrt.dll that were not backward
compatible to prevent the confusion. While VS.NET apps don't need this by
default I have old components that still use it, so as is our standard
procedure it was to install the latest VS.NET or Service pack and grab those
files (such as msvcrt.dll and MFCXX.DLL) as those were the standard files
we;ve been doing that for years, it was inadvisable for MS to create the
confusion with this particular .dll by making it not backward compatible as
has been the case for how many years now?

Now yes everyone should read the docs and new distribution agreements after
every new version they get to know there have been changes.. but c'mon how
many people do. The likelyhood is this is going to cause vendors, MS and
users some problems in the future. Which could have been alleciated by not
creating a non-backward compatible .dll with the same name as ones that used
to be. I agree this should at very least be a KB article, if not more.

"Tomas Restrepo [MVP]" <tom...@mvps.org> wrote in message
news:uEIMCoj3BHA.1580@tkmsftngp04...

[Brandon Bray [MSFT]]

Dave wrote:
> The point is people have for years always grabbed the latest msvcrt.dll
> and distributed it as needed.

Hi Dave,
I can offer some explanation, but at least you get to say that you're
breaking one bad habbit. :-)

> It is new to VS.NET that this is not needed and it is new that windows XP
> includes a system version with the same name as the original
> redistributeable one that is not backward compatible.

Even if you were able to drop any version of msvcrt.dll onto old systems,
you would have found out that your application did not run. The libc.lib
and similar files point to msvcr70.dll and msvcp70.dll and similar files.
(I think it's obvious why msvcp60.dll is being replaced with msvcp70.dll,
just as msvcp60.dll replaced msvcp50.dll.)

> MS should not have created any versions of msvcrt.dll that were not
> backward compatible to prevent the confusion.

That is an ideal situation, but the reality is that we do not live in an
ideal world. Entropy exists. Everything syntactic flaw must be maintained
to ensure backwards compatibility. Ensuring this while keeping the DLL name
the same is not impossible, but certainly requires some feat of software
engineering. The semantic issues are far more dicey. Any time there is a
change to the semantics, even if the old semantics were clearly wrong, we
will break programs. (Believe me, we've had more than enough experience
with this to know the dangers that exist). So, of course, we could have
kept the name the same, but as soon as we started fixing problems that
applications actually needed the buggy behavior, they'd all break. This
could even be your application! Ideally, everyone would depend upon the
clean and well-defined semantics of an API, but reality has proven
otherwise.

So, the best solution -- isolate the nature of the changes. In this case,
we are making sure that the newly named msvcr70.dll is specifically designed
for applications (not the system), and so that applications can determine
when and how msvcr70.dll is serviced. The Visual C++ team is dilligently
advocating that msvcr70.dll does not become a "known DLL" in the system file
protection of Windows 2000 and later. This ensures that the environment an
application was developed and tested in is also the environment that an
application is used in -- it is not subject to other applications or even
the system subjecting it to a possibly breaking change.

> While VS.NET apps don't need this by default I have old components that
> still use it, so as is our standard procedure it was to install the
> latest VS.NET or Service pack and grab those files (such as msvcrt.dll and
> MFCXX.DLL) as those were the standard files we;ve been doing that for
> years, it was inadvisable for MS to create the confusion with this
> particular .dll by making it not backward compatible as has been the case
> for how many years now?

In this case, msvcrt.dll didn't even ship with Visual Studio .NET.
Needless, to say, we had good reasons to make this change. I'll look into
ways of stepping up the announcement of this change.

> Now yes everyone should read the docs and new distribution agreements
> after every new version they get to know there have been changes.. but
> c'mon how many people do.

Well, you haven't had to read anything new for three years... I'm sure you'd
want to do this! <grin> Anyways, you're absolutely right -- no one reads
the documentation, so they have to find out in other ways.

> The likelyhood is this is going to cause vendors, MS and users some
> problems in the future.

In this case, the existance of msvcr70.dll is all that it takes to run the
program. Without it, the program cannot run (even on older systems). So, I
should hope that most developers would be able to isolate this problem
quickly.

> I agree this should at very least be a KB article, if not more.

If there isn't already a KB article, I'll ask that one be written.

I hope that helps give you some background.

--
Cheerio!
Brandon Bray Program Manager in the Visual C++ Compiler Team

And now a word from the lawyers: This posting is provided "AS IS" with no
warranties, and confers no rights. You assume all risk for your use. © 2002
Microsoft Corporation. All rights reserved.

[Ted]

I don't think he's complaining about the CRT name change in 7.0 (that is a
GOOD thing), I think that he's mad (as most are) that the latest msvcrt.dll
from XP doesn't work with existing shipping VC6 apps on Win9x platforms, and
there's no real clue about this anywhere. The same thing happens with
oleaut32.dll etc, with the 3.50 versions, and also there's no real info
about this in any whitepaper, kb article or documentation.

For example, many people are making use of the package and deployement
wizard or whatever, and taking the DLLs that they will distribute from their
system folder (something I would never do, but people are doing it), so we
get epidemic problems like the 3.50 oleaut32.dll being installed on Win9x
and breaking the system.

The only real solution to this DLL Hell type deployment problem is
education, via tons of articles in MSDN, KBs, etc. A lot of people will use
VC 6 for a long time and muck up many people's systems by mistakenly
including a newer msvcrt.dll or OLE file.

Ted.

"Brandon Bray [MSFT]" <branbra...@microsoft.com> wrote in message
news:u09D$7x3BHA.2284@tkmsftngp02...

[Brandon Bray [MSFT]]

Ted wrote:
> The only real solution to this DLL Hell type deployment problem is
> education, via tons of articles in MSDN, KBs, etc.

Hi Ted,
Thanks for the clarification. I'm certainly hoping that we'll have better
education soon. I've asked for several KB articles to be written
specifically about this and similar subjects.

Your help is much appreciated!