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

Discussion in 'NZ Computing' started by Snoopy, Aug 14, 2003.

  1. Snoopy

    Snoopy Guest

    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

    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



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

    Snoopy, Aug 14, 2003
    1. Advertisements

  2. 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".
    Aaron Lawrence, Aug 14, 2003
    1. Advertisements

  3. Snoopy

    Patrick Bold Guest

    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
    Patrick Bold, Aug 15, 2003
  4. Snoopy

    Snoopy Guest

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


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

    Snoopy, Aug 16, 2003
  5. Snoopy

    Snoopy Guest

    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

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

    There is also

    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.


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

    Snoopy, Aug 16, 2003
  6. Snoopy

    Mainlander Guest

    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.
    Mainlander, Aug 16, 2003
  7. Snoopy

    Mainlander Guest

    yes that sounds like common sense!
    Mainlander, Aug 16, 2003
  8. Snoopy

    Mainlander Guest

    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

    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.
    Mainlander, Aug 16, 2003
  9. Snoopy

    Snoopy Guest

    Snoopy, Aug 17, 2003
  10. Snoopy

    Snoopy Guest

    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.


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

    Snoopy, Aug 17, 2003
  11. 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)

    Peter Huebner, Aug 17, 2003
  12. 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 :).

    Nicholas Sherlock
    Nicholas Sherlock, Aug 17, 2003
  13. 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

    Peter Huebner, Aug 19, 2003
  14. Snoopy

    Snoopy Guest

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


    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


    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.


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

    Snoopy, Aug 20, 2003
  15. Snoopy

    Mainlander Guest

    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.
    Mainlander, Aug 24, 2003
  16. 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).

    Nicholas Sherlock
    Nicholas Sherlock, Aug 24, 2003
  17. Snoopy

    Mainlander Guest

    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.
    Mainlander, Aug 25, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.