Difference between MSVCRT.DLL and MSVCR70.DLL?

[Jan Bares]

Hi,

can someone shed some light, what is the difference? Why MS decided to
change the name?

Ciao Jan

[Michael (michka) Kaplan]

Because msvcrt.dll is now a "system file".

--
MichKa

Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/

International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/

"Jan Bares" <jan....@ante.cz.no.spam> wrote in message
news:#fikV8DwBHA.2100@tkmsftngp07...

[Jan Bares]

Thanks for answer. Can you point me some MS page with explanation what is
system file? BTW does msvcr70.dll run on Win95? I know that this system is
no more supported by MS but lot of our customers use it.
I did some search on MSDN and Google groups but found nothing useful.

Best regards, Jan

[Michael (michka) Kaplan]

I really am not an index of pages on the MS site, sorry. :-)

A system file is one that is now a part of the system -- it comes with the
OS now. Just like kernel32.dll or ntdll.dll or any other file that is
installed by Windows.

Since Win95 is not supported, I do not think you can ever distribute 7.0
apps to it? I have no idea if it works or not in non-managed apps (in
managed apps it definitely fails).

--
MichKa

Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/

International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/

"Jan Bares" <jan....@ante.cz.no.spam> wrote in message

news:uDgDauGwBHA.2020@tkmsftngp02...

[Todd Brooks]

Statically linking in non-managed apps will make it work under Win95,
assuming you aren't using any extra libraries that are not installed on
Win95 by default (like WMI, SOAP, etc).

If you statically link, you can distribute your 7.0 apps to any Win32
platform.

todd

"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote
in message news:eKhltxGwBHA.2592@tkmsftngp05...

[Jan Bares]

Is this based on your opinion or is this official statement from Microsoft?
The problem is that the new DLL require to test all programs on all
platforms again. And I will be glad if I can find some official statement
about MSVCR70.DLL.

Regards, Jan

[Michael (michka) Kaplan]

Did you try reading the license agreement and redist list:? You may HAVE the
documentation.

--
MichKa

Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/

International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/

"Jan Bares" <jan....@ante.cz.no.spam> wrote in message

news:u5dLqHQwBHA.2020@tkmsftngp02...

[Jan Bares]

Probably I am blind but I cannot find any useful doc. The redist.txt says
nothing about where to put this DLL. I don't want to use the merge
modules...is this information in licence agreement? I don't think so.

Jan

"Michael (michka) Kaplan" <forme...@nospam.trigeminal.spamless.com> wrote

in message news:ewBiczRwBHA.2560@tkmsftngp07...

[Michael (michka) Kaplan]

I would not suggest moving forward without a clearer understanding of the
licensing issues -- and much more than you could get from a newsgroup
contact from an MS employee (what you originally asked for here).

If redist.txt has the file than you can redistribute it.

--
MichKa

Michael Kaplan
Trigeminal Software, Inc. -- http://www.trigeminal.com/

International VB? -- http://www.i18nWithVB.com/
C++? MSLU -- http://msdn.microsoft.com/msdnmag/issues/01/10/

"Jan Bares" <jan....@ante.cz.no.spam> wrote in message

news:e5ivq$TwBHA.2592@tkmsftngp04...

[Ronald Laeremans [MSFT]]

The official statement is that we do not support running programs created
with Visual Studio .Net 7.0 on any version of Windows 95. It simply hasn't
been part of the tests we run. So it might work and it might not.

Ronald Laeremans
Visual C++ compiler team

"Jan Bares" <jan....@ante.cz.no.spam> wrote in message

news:u5dLqHQwBHA.2020@tkmsftngp02...

[Jan Bares]

Thanks Ronald, that is what I expected. We still have customers with Win95,
hmm...

But I have another problem. Brandon Bray mentioned that msvcr70.dll is
intended to be redistributed
with the application -- it should be installed in the application directory.
I tried to search this statement in the official documentation from
Microsoft, but found nothing. Is this true?

Best regards Jan

[Brandon Bray [MSFT]]

Jan Bares wrote:
>
> But I have another problem. Brandon Bray mentioned that msvcr70.dll is
> intended to be redistributed with the application -- it should be
> installed in the application directory. I tried to search this
> statement in the official documentation from Microsoft, but found
> nothing. Is this true?

Hi Jan,
Yes it's true. To be quite honest, I'm not sure where this is documented.
Nevertheless, our reasoning for making msvcr70.dll separate from msvcrt.dll
was to help protect you against DLL hell. Since msvcr70.dll is not a known
system DLL, the system will use the version distributed with you application
instead of the version shipped with the operating system. Overall, this
helps you isolate your testing environment.

Obviously you cannot redistribute msvcrt.dll since it is not shipped with
Visual Studio... so it makes sense that you're left with msvcr70.dll.

I hope that clears some of the confusion!

--
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.

[Jan Bares]

Hi and thanks. I have more questions (I hope final).

* Does the same reasoning (DLL Hell) apply to MFC70.DLL?

* Someone from MS mentioned that MSVCRT.DLL will be used by drivers. Since
VC.NET has no option to use that DLL instead of MSVCR70.DLL does it mean
that that the last version that can be used to build drivers is VS 6.0?
Or will the DDK ship with different msvcrt.lib?

* I don't think that there will be frequent bug fixes in MSVCRT. The code is
out for several years and it is heavily used. But nobody mentioned that
VS.NET needs support for new runtime checks in standard library. That is
(IMHO) the main reason why you have to change the name.

Frankly speaking, this new DLL and the changed for loop scope destructor
(see my post) makes very difficult to upgrade to VS.NET.

Best regards, Jan

[Brandon Bray [MSFT]]

Jan Bares wrote:
> Hi and thanks. I have more questions (I hope final).

No problem!

> * Does the same reasoning (DLL Hell) apply to MFC70.DLL?

Honestly, I don't know much about MFC, but the name change does seem
reasonable. I am not sure if mfc70.dll is considered a system dll or not.

> * Someone from MS mentioned that MSVCRT.DLL will be used by drivers. Since
> VC.NET has no option to use that DLL instead of MSVCR70.DLL does it mean
> that that the last version that can be used to build drivers is VS 6.0?
> Or will the DDK ship with different msvcrt.lib?

I believe the DDK will have to ship a different msvcrt.lib. I'll look into
that and hopefully have an answer at some point. Basically, since
msvcrt.lib will change with every update to the operating system -- it makes
sense that drivers would be updated as well (or at least tested to work with
the updated msvcrt.dll). Applications probably would prefer to stick with
whatever CRT it was developed and tested with.

> * I don't think that there will be frequent bug fixes in MSVCRT. The code
> is out for several years and it is heavily used. But nobody mentioned that
> VS.NET needs support for new runtime checks in standard library. That is
> (IMHO) the main reason why you have to change the name.

You'd actually be surprised -- the CRT does get serviced fairly frequently,
and it does get new features. Many of these features certainly aren't
flashy, but they address needs of critical applications.

That said, msvcrt.dll and msvcr70.dll are mostly the same. Given the limit
as time approaches positive infinity, the binary images of both DLLs is
identical. Since we don't live in the time of positive infinity, we have to
face the more practical effects of software engineering. While this
solution is perhaps not ideal, it is far better than what we had before.

> Frankly speaking, this new DLL and the changed for loop scope destructor
> (see my post) makes very difficult to upgrade to VS.NET.

Why does this new DLL cause so many problems? If you were doing it right
before, you were redistributing msvcrt.dll rather than relying on the system
copy. A name change is a temporary growing pain... you get past it very
quickly.

As for the the "for scope" change, we'll be damned if we do and damned if
don't. At least right now we're being practical and providing a
transitional solution until we can exclusively support the conformant
semantics. Fixing your code so that is conformant with the C++ standard is
definitely in your best interest in any situation.