msvcrt.dll, msvcirt.dll, msvcrt20.dll and msvcrt40.dll, explanation please!

I need to figure out if I have some kind of 'C' library
incompatability that is causing an old windows function to seize up.

Currently I have on my computer:

msvcrt.dll: 6.00.8337.0 Microsoft (R) C Runtime Library
msvcirt.dll: 6.00.8168.0 Microsoft (R) C++ Runtime Library
msvcrt20.dll: 2.11.000 Microsoft® C Runtime Library
msvcrt40.dll: 4.20 - OS use only. DO NOT DISTRIBUTE Microsoft (R) C
Runtime Library Forwarder DLL

I know enough to know that certain computer programs are written in
'C' and 'C++'. I presume that these dlls are to allow windows to run
them.

As a starting point can anyone explain to me the history of these four
dlls and how they interact?

My second question is, what is the earliest version of all these
files?

TIA

SNOOPY


--
Join the fight against aggressive, unrepentant
spammers 'china-netcom'. E-mail me for more
details

--

 

Thus spake te**[email protected]*et.*z.*is'n':

Close enough.

Well they are all versions of Microsoft's "C Runtime Library" as you
say. As to the history, only Microsoft can tell you for sure, since
there version numbers are "A little unintuitive".

 

You'd be better off here describing the problem you have in more detail.
Then someone might be able to help you diagnose the cause better. No
sense discussing the specific function of a dll, or debating the precise
meaning of "newer" and "older" versions, when this may very well be
beside the point. As Aaron suggested, Microsoft is probably your best
source for technical details, but if you want help troubleshooting then
just exlain the problem you're seeing better.

Conflicting versions of the dlls you mention *can* cause trouble. I
haven't seen this myself since Win2K/XP but I suppose it's possible.
(What OS are you running, btw?) In the case of the Win9x trouble I used
to see, the first application to run that needs, say, msvcrt40.dll loads
whatever version is specified in the main executable -- this might be
the common version located in windows\system or some other version
located in the home directory. All is well to that point. But then the
next application to run that needs msvcrt40.dll is stuck with what's
already loaded -- for better or worse. Some very strange behavior
sometimes resulted that could only be remedied by deleting all copies of
the dll outside windows\system. A related problem was caused by apps
that re-wote the Regsistry key identifying the location of a common
system dll (like msvcrt40.dll ) and so pointed Windows to always load
the home-directory version. Very nasty business.

Good luck

 

'msvcrt20.dll' and 'msvcrt.dll' are both described as a 'Microsoft® C
Runtime Library' and , yet both msvcrt.dll and msvcrt20.dll are
described under the product version tab as C++ compilers.

Why would they be called C runtime libraraies when in reality they are
C++ runtime libraries? Is a pure 'C' runtime library now obsolete?

You are saying that this is not correct?

Because things are not always as they *seem*. If you have a counter
experience, please share it.

SNOOPY




--
Join the fight against aggressive, unrepentant
spammers 'china-netcom'. E-mail me for more
details

--

 

I obtained the install file. Double clicked it while monitoring it
with 'Cleansweep' and got a print out of everything that was
installed. There was definitely nothing installed in the registry at
that time. 'Cleansweep' does trace registry entries as I have seen
it report on them with other installations of other programs I have
done.

Then again, I originally installed 'Activemovie' as part of IE3 or
Windows 95 I think. Because 'Activemovie' is tightly integrated into
Windows all of the registry entries you speak of may have gone in
then.

I was a little bemused by your suggestion, as I don't have a video
card. I have just relied on the standard issue Windows 95 drivers
and I assumed these would be rebuilt when I reloaded Windows.

Nevertheless I sought out a suitable driver from the net and installed
it. And now Mplayer is working again for video playback!

You are the man on this one Patrick. Thanks very much!

Perhaps this means the driver on my Win 95 diskettes is corrupt?

Anyway, I have my configuration set up so that when I 'double click'
an mpg file Activemovie is fired up. And, surprise surprise, this
now works too!

I got my duplicate Activemovie dlls, vxs, drvs and ocxs from

http://www.zadilly.com/w95f.htm

There is also

http://www.zadilly.com/w98f.htm


A couple of very useful sites for downloading pieces of Win95/98 that
you are missing or doubtful about. The files I got were not 'better'
than the ones I had before. They were identical.

Scandisk shows no problems with my hard drive.

Do you know anything about the way these two files interact? If so
please spill the beans.

Well the option isn't available to me, but yes if I was starting again
from scratch I would be tempted to look for a Win 98se machine. In
the meantime, I am not a particularly demanding user, so Win 95 suits
me fine.

My strategy is to let Windows itself do as little as possible, and try
to get alternative software to accomplish the tasks that Windows
normally covers. I am even a bit reluctant to use Activemovie and
Media Player 2.

I am on the lookout for a piece of software that plays *.mpg files
that is not just a skin on top of media player, as many of the
'supposed alternative' mpg players seem to be. Any suggestions?

What are you saying? That Cleansweep *deliberately* misses changes to
certain areas of the registry?

I find the plain vanilla Regedit a satisfactory tool, should I need to
dive into the registry to purge some files.

SNOOPY




--
Join the fight against aggressive, unrepentant
spammers 'china-netcom'. E-mail me for more
details

--

 

Activemovie is part of Media Player now, forget it.

Just reinstall Windows.

Get something more modern, what do you expect!

A lot of apps aren't even available for Windows 95 now.

 

yes that sounds like common sense!

 

No. It means that the generic Windows driver doesn't do video. This is
hardly surprising since they are made to work with all video cards on the
market.

Windows comes with hundreds of different device drivers for only a few
different types of devices, including video. Just because it hasn't
detected your video card and installed the correct drivers doesn't mean
you should keep using the default Windows driver, which in most cases
will only display 640 x 480 at 16 colours.

Does it matter - no.

Windows 95 is no longer supported by MS, meaning that security patches
are not available, most new software is not available for Windows 95
either. Running an old computer with such an old OS and old software
leaves your computer vulnerable to viruses and exploits.

 

If it works and does all you want it to do, why forget it?

Tried that. It failed to fix the problem

As long as you don't need those applications it isn't a problem.

SNOOPY








--
Join the fight against aggressive, unrepentant
spammers 'china-netcom'. E-mail me for more
details

--

 

Ok. runtime libraries. Basically they are a bunch of computer program
subroutines all glued together in one big bunch. So there may be a
routine that does the display when you click on a menu bar, another that
does a file requester, one that does a message box with either an
exclamation mark or a question mark graphic on it ...

The idea of having this in a dll is, that you don't have to program this
'basic' stuff every time you write a program: you do it once, create a
dll and then you can re-use the same code from every program you write in
the future.

Now, there are two ways about putting together a dll, the right way and
the wrong way. The wrong way is, you the programmer know where all the
different bits are in the dll and so you tell your program: execute the
bit of code in myown.dll starting at byte 1024 and ending at byte 2048.
The right way of putting together a dll is to have a jump table. So you
have a name for every bit of code, the jumptable knows the offset in the
dll and your program calls the subroutine by referring to the jumptable.
What this does is, it keeps the dll file compatible with your programs if
you should decide to make a change to some of the code in the dll - all
you have to do is adjust the jump table to point to the new locations.

I expect that your 'forwarder' is just such a jump table. Of sorts.
Part of what all that karfuffel with MS lawsuits re monopoly and abuse
recently was about is, that MS deliberately obfuscates their code, does
not publish [complete] jumptables or documentation so other software
developers don't have full access to the powers of the operating system.
Of course they shoot themselves in the foot with that technique, too.

Unless one of them is a jump table for another, they probably do not
interact at all.
This is one of the things that have always had me highly suspicious of
the standard of software engineering at Microsoft - look at all the
Visual Basic runtime libraries. Has it never occurred to those clowns to
have One and One Only Visual Basic runtime library, backwardly compatible
via jump table with all prior versions? Sheesh - I learned that technique
nearly 20 years ago ... instead we have vbrun.dlls coming out of our
ears. (see above for a possible reason for this)


-P.

 

There is only one VB runtime, isn't there? If there are multiple ones, it'll
either be because they are from different versions or they have different
functions, eg. you if don't need database access, you won't need that .dll
for distribution. It'd be very hard to have a "Backwards compatible" one,
because you'd either have to invent new names for every routine every time
you changed the parameters, the basic operation, or the way that the result
should be interpreted of the routines.

BTW... programs in Delphi don't need any .DLLS .

Cheers,
Nicholas Sherlock

 

Every version of VB has come out with a new vbrun___.dll - ok, that makes
sense. But that they are not backwardly compatible, that does not make
sense at all. If you use a jumptable at the beginning of the dll, as is
accepted good practice, all you need to do is to tack the new routines on
to the end of the jumptable, update the offsets to allow for a longer
jumptable, and all the programs using the older version of the dll would
run fine with the new one: resulting in your only having to have one
(vb)runtime on your machine at any one time. So much for that.

You are, of course, absolutely right in that Delphi does not need dlls,
but you can certainly use Delphi to write yor own ones. There is quite a
lot written about it in Delphi [manuals] and literature. And, of course,
a lot of Delphi programmers use the WinAPI libraries ( I just LOVE trying
to comprehend their code usually <sigh> - I'm no hotshot, that's for
sure).

-P.

 

Thanks for that explanation Peter. Just what I was after. I have
run 'Dependency Walker' on Activemovie again, and here is how it
handles the two 'C++' Microsopft library files:

-----------

0:00:02.244: DllMain(0x78000000, DLL_PROCESS_ATTACH, 0x00000001) in
"c:\windows\system\MSVCRT.DLL" called by thread 1.
00:00:02.280: GetProcAddress(0xBFF70000
[c:\windows\system\KERNEL32.DLL], "IsProcessorFeaturePresent") called
from "c:\windows\system\MSVCRT.DLL" at address 0x780045C0 and returned
NULL by thread 1. Error: The specified module could not be found
(126).
00:00:02.342: DllMain(0x78000000, DLL_PROCESS_ATTACH, 0x00000001) in
"c:\windows\system\MSVCRT.DLL" returned 1 (0x1) by thread 1.
00:00:02.357: DllMain(0x780A0000, DLL_PROCESS_ATTACH, 0x00000001) in
"c:\windows\system\MSVCIRT.DLL" called by thread 1.
00:00:02.373: DllMain(0x780A0000, DLL_PROCESS_ATTACH, 0x00000001) in
"c:\windows\system\MSVCIRT.DLL" returned 1 (0x1) by thread 1.
00:00:02.389: DllMain(0x779D0000, DLL_PROCESS_ATTACH, 0x00000001) in
"c:\windows\system\MSVCRT40.DLL" called by thread 1.
00:00:02.405: DllMain(0x779D0000, DLL_PROCESS_ATTACH, 0x00000001) in
"c:\windows\system\MSVCRT40.DLL" returned 1 (0x1) by thread 1.
00:00:03.702: Loaded "c:\program files\microsoft
hardware\mouse\MSWHEEL.DLL" at address 0x61230000 by thread 1.
Successfully hooked module.
<snip>

-----------

That last line is me moving the mouse and no more instances of the C++
libraries were called after that.

My reading of the above is as follows. Activemovie firsts looks for

MSVCRT.DLL

at the address "0x780045C0" and can't find it. It then goes to the
address "0x780A0000" and does find it. (Why did it go to the wrong
place in the first place? Can anyone explain that?)

Activemovie then finds "MSVCRT40.DLL" at "0x779D0000", and the program
then sits with both of these modules loaded waiting for instructions.

I don't know if any significance can be attached to the order in which
the dlls were called. Anyone?

Those of you who are familiar with 'Activemovie' will know that this
is as far as it gets if you fire up the program Activemovie itself.
There is no way to play a movie file with Activemovie by firing up the
program itself. You can only change file associations by doing this.

To truly see how these two DLL libraries (MSVCRT40.DLL and MSVCRT.DLL)
interact you would have to run a movie clip. I don't know a way of
making 'Dependency Walker' trace such a process.

SNOOPY


--
Join the fight against aggressive, unrepentant
spammers 'china-netcom'. E-mail me for more
details

--

 

Delphi can be configured to use "runtime packages", which are actually
DLLs, and guess what, these come in different versions. Plus you can call
functions in other people's DLLs, and in fact many calls in Delphi
applications are made to the Windows system DLLs, so actually Delphi
applications make extensive use of DLLs.

 

But they don't use DLLs or runtime packages by default and they not
necessary at all. Unlike Visual Basic, which absolutely depends on a slew of
DLLs. None of my Delphi applications need external DLLs. Some database
applications use external DLLs, but there are products available that
compile right into your .exe.

The runtime packages you can distribute with Delphi aren't real DLLs either.
They offer far better integration into your Delphi programs than DLLs in
other languages ever could.

Of course calls to Windows system DLLs are made. Every application uses
them. All of the Windows API that you use to do every single thing in
Windows is made available through DLLs. The difference is that these are
part of a default Windows installation (Windows would not run without them).

Cheers,
Nicholas Sherlock

 

VB relies on DLLs, called the VB runtime environment.

Delphi when configured to use runtime packages relies on DLLs called the
runtime packages - not a lot different.

The reasoning is the same in both cases, your EXE can be a lot smaller if
it doesn't wrap up the same common code in every application - that code
can be put into one DLL (or package) and shared among all applications.

All you Delphi programs use the Windows DLLs by default, because of
things like the common controls - most of the stuff on the first three
tabs of the VCL are Windows' built in controls that Delphi just provides
a wrapper for. All the functionality of these controls is handled by
calls to the Windows DLLs. Just because you only have one EXE file to
distribute doesn't mean your app is immune to issues around DLL versions
and whether they are installed or not. To give an example, some
functionality available in Windows NT was not available in 9x. If you
happened to call that functionality in your program, it would not work on
a 95 system.

Another example is with COM where the server application is not
installed, this is very easy to do with Delphi and with the standard
components supplied with it.

They are runtime libraries and have the same issues as other types of
runtime libraries such as DLLs.

You can get into issues in a Delphi app with different versions of the
Windows DLLs. For example you see specified in the Delphi literature that
certain types of controls will not function correctly if the common
controls DLL version number is 4.70 or less. That is because some of the
common controls in Windows were not made available until for example
Internet Explorer 4.