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

    --
     
    Snoopy, Aug 14, 2003
    #1
    1. Advertising

  2. Thus spake te**yson@caverock.*et.*z.*is'n':
    > 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.


    Close enough.

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


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

    --
    aaronl at consultant dot com
    http://homepages.visp.co.nz/~aaronlawrence
    ...Gross Ignorance: 144 times worse than ordinary ignorance.
     
    Aaron Lawrence, Aug 14, 2003
    #2
    1. Advertising

  3. Snoopy

    Patrick Bold Guest

    "Snoopy" <te**yson@caverock.*et.*z.*is'n'> wrote in message
    news:...
    > On Fri, 15 Aug 2003 01:08:20 +1200, Aaron Lawrence
    > <> wrote:
    >
    > >Thus spake te**yson@caverock.*et.*z.*is'n':
    > >> 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.

    > >
    > >Close enough.
    > >

    >
    > Is it possible that a compiled Windows program can run on C *and* C++?
    >
    > What is the logic behind having a 'C runtime library forwarder'?
    > Does it just transfer execution to the 'C Runtime Library'?
    >
    > If so, why have it at all? It seems not to be needed. So the
    > forwarder must do something. What?
    >
    > >
    > >>As a starting point can anyone explain to me the history of these

    four
    > >>dlls and how they interact?

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

    >
    > What do you mean? The higher numbers seem to indicate newer
    > versions of the files. Why is that 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
     
    Patrick Bold, Aug 15, 2003
    #3
  4. Snoopy

    Snoopy Guest

    On Fri, 15 Aug 2003 23:34:07 +1200, Aaron Lawrence
    <> wrote:

    >Thus spake te**yson@caverock.*et.*z.*is'n':
    >> Is it possible that a compiled Windows program can run on C *and* C++?

    >
    >A C++ compiler can also compile C, so yes.
    >
    >Visual C++ started life (sort of) as Microsoft C...
    >


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

    >
    >> What do you mean? The higher numbers seem to indicate newer
    >> versions of the files. Why is that unintuitive?

    >
    >They *seem* to, yes.
    >


    You are saying that this is not correct?

    >
    >If it's easy, why are you asking us?
    >


    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

    --
     
    Snoopy, Aug 16, 2003
    #4
  5. Snoopy

    Snoopy Guest

    On Fri, 15 Aug 2003 21:27:50 -0400, "Patrick Bold"
    <> wrote:


    >
    >It's all well and good for you to dismiss Microsoft's advice (I agree,
    >they can be obtuse sometimes). But when you tinker like this, you'd best
    >be sure you know what you're doing. To say that there were "apparently
    >no registry changes" suggests to me you're guessing. That's not a good
    >start. As it happens, ActiveMovie has many Registry entries, as would
    >each of the ocx and vxd files. Proper uninstall programs synchronize all
    >of this. Have you?
    >


    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.

    >>
    >> My eventual goal is to put 'Powerpoint' on my computer. However, I
    >> have read that it relies on 'MPlayer.exe' to feed it. My
    >> 'Mplayer.exe' will play sounds but simply hangs on all video formats.
    >> Drastic steps like reinstalling windows have failed to fix it.
    >>
    >> 'Activemovie' has the same problem (completely unusable it just
    >> hangs). The file type menu is permanently greyed out. But it seems a
    >> simpler program that Mplayer, so I am trying to get it to work first.
    >>

    >
    >Ok, clue #1. You've got two programs that are each supposed to be able
    >to run videos. Neither one works on your machine. Reinstallation of
    >windows doesn't help. That suggests to me, not a dll problem, but a
    >basic system configuration problem with the video drivers. At least
    >that's where I'd start. Have you got the latest available drivers?
    >


    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 first suspected that the version of 'Activemovie' I was installing
    >> was somehow corrupt. So I searched the net for all the individual
    >> files contained with the 'Amovie installer', cut and pasted the six
    >> files I wanted to replace into a hoilding folder and copied new
    >> versions of Amovie.ocx, MCIQTZ.drv, MCIQTZ32.dll, Quartz.dll and
    >> Quartz.vxd into Windows/System. No change in behaviour.
    >>

    >
    >Yikes!! Care to mention where exactly you got each of the files and how
    >you determined that these were better than the ones that came with
    >Windows?
    >


    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.

    >
    >That's another guess. How about running ScanDisk or something comparable
    >and finding out for sure.
    >


    Scandisk shows no problems with my hard drive.

    >
    >> Next I fired up 'Dependency Walker' to find the file dependencies of
    >> the Activemovie files. It was then I noted that MSVCRT.DLL and
    >> MSVCIRT.DLL were of the version 6 generation, whereas MSVCRT40 is
    >> generation four. This is why I am suspicious of these files,
    >> although so far my efforts to find any older versions of these files
    >> have prove fruitless.

    >
    >Your suspicions are wrong. Msvcrt.dll and msvcrt40.dll are two different
    >files. Leave them alone.
    >


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


    >>
    >> Win95

    >
    >Bummer. At least make sure that you have downloaded and installed every
    >one of the 50 or so updates/patches etc that were available were this
    >OS. Without them, you will be chasing your tail forever. If the option
    >is at all available to you, I would strongly suggest upgarding to at
    >least Win98se.
    >


    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?


    >
    >Like I said, Amovie has many registry entries. Cleansweep, for whatever
    >it may be worth to you otherwise, is actually pretty useless when it
    >comes to accounting for crucial Registry changes.
    >


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

    >
    >Get yourself a program
    >like "Registry Crawler" that will do a keyword search and compile the
    >results. Even then you are going to miss some that are hidden under
    >obscure alpha-numeric codes.
    >


    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

    --
     
    Snoopy, Aug 16, 2003
    #5
  6. Snoopy

    Mainlander Guest

    In article <>,
    te**yson@caverock.*et.*z.*is'n' says...
    > On Fri, 15 Aug 2003 13:30:26 -0400, "Patrick Bold"
    > <> wrote:
    > >
    > >
    > >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,
    > >

    >
    > Except that Microsoft's technical advice consists of stuff like,
    >
    > "you can't uninstall ActiveMovie, its impossible" (yet it is only
    > three dll files and one drv and one ocx and vxd, and the main
    > executable, with apparently no registry changes)
    >
    > and 'don't worry about updating files as all are perfectly backwardly
    > compatible with earlier versions' which seems not to be the case.
    >
    > >
    > >but if you want help troubleshooting then
    > >just explain the problem you're seeing better.
    > >

    >
    > My eventual goal is to put 'Powerpoint' on my computer. However, I
    > have read that it relies on 'MPlayer.exe' to feed it. My
    > 'Mplayer.exe' will play sounds but simply hangs on all video formats.
    > Drastic steps like reinstalling windows have failed to fix it.
    >
    > 'Activemovie' has the same problem (completely unusable it just
    > hangs). The file type menu is permanently greyed out. But it seems a
    > simpler program that Mplayer, so I am trying to get it to work first.
    >
    > I first suspected that the version of 'Activemovie' I was installing
    > was somehow corrupt. So I searched the net for all the individual
    > files contained with the 'Amovie installer', cut and pasted the six
    > files I wanted to replace into a hoilding folder and copied new
    > versions of Amovie.ocx, MCIQTZ.drv, MCIQTZ32.dll, Quartz.dll and
    > Quartz.vxd into Windows/System. No change in behaviour.


    Activemovie is part of Media Player now, forget it.

    Just reinstall Windows.

    >
    > I think that doing the copying the way I have done it, also eliminates
    > the possibility that my hard disk has gone bad in the sectors that
    > used to hold the original files.
    >
    > Next I fired up 'Dependency Walker' to find the file dependencies of
    > the Activemovie files. It was then I noted that MSVCRT.DLL and
    > MSVCIRT.DLL were of the version 6 generation, whereas MSVCRT40 is
    > generation four. This is why I am suspicious of these files,
    > although so far my efforts to find any older versions of these files
    > have prove fruitless.
    >
    > >
    > >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?)
    > >

    >
    > Win95


    Get something more modern, what do you expect!

    A lot of apps aren't even available for Windows 95 now.
     
    Mainlander, Aug 16, 2003
    #6
  7. Snoopy

    Mainlander Guest

    In article <3f3c3705$1_3@newsfeed>, says...
    > Snoopy" <te**yson@caverock.*et.*z.*is'n'> wrote in message


    > > My eventual goal is to put 'Powerpoint' on my computer. However, I
    > > have read that it relies on 'MPlayer.exe' to feed it. My
    > > 'Mplayer.exe' will play sounds but simply hangs on all video formats.
    > > Drastic steps like reinstalling windows have failed to fix it.
    > >
    > > 'Activemovie' has the same problem (completely unusable it just
    > > hangs). The file type menu is permanently greyed out. But it seems a
    > > simpler program that Mplayer, so I am trying to get it to work first.
    > >

    >
    > Ok, clue #1. You've got two programs that are each supposed to be able
    > to run videos. Neither one works on your machine. Reinstallation of
    > windows doesn't help. That suggests to me, not a dll problem, but a
    > basic system configuration problem with the video drivers. At least
    > that's where I'd start. Have you got the latest available drivers?


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

    Mainlander Guest

    In article <>,
    te**yson@caverock.*et.*z.*is'n' says...
    > On Fri, 15 Aug 2003 21:27:50 -0400, "Patrick Bold"
    > <> wrote:
    >
    >
    > >
    > >It's all well and good for you to dismiss Microsoft's advice (I agree,
    > >they can be obtuse sometimes). But when you tinker like this, you'd best
    > >be sure you know what you're doing. To say that there were "apparently
    > >no registry changes" suggests to me you're guessing. That's not a good
    > >start. As it happens, ActiveMovie has many Registry entries, as would
    > >each of the ocx and vxd files. Proper uninstall programs synchronize all
    > >of this. Have you?
    > >

    >
    > 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.
    >
    > >>
    > >> My eventual goal is to put 'Powerpoint' on my computer. However, I
    > >> have read that it relies on 'MPlayer.exe' to feed it. My
    > >> 'Mplayer.exe' will play sounds but simply hangs on all video formats.
    > >> Drastic steps like reinstalling windows have failed to fix it.
    > >>
    > >> 'Activemovie' has the same problem (completely unusable it just
    > >> hangs). The file type menu is permanently greyed out. But it seems a
    > >> simpler program that Mplayer, so I am trying to get it to work first.
    > >>

    > >
    > >Ok, clue #1. You've got two programs that are each supposed to be able
    > >to run videos. Neither one works on your machine. Reinstallation of
    > >windows doesn't help. That suggests to me, not a dll problem, but a
    > >basic system configuration problem with the video drivers. At least
    > >that's where I'd start. Have you got the latest available drivers?
    > >

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


    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.

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


    Does it matter - no.

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


    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
    #8
  9. Snoopy

    Snoopy Guest

    On Sun, 17 Aug 2003 00:47:28 +1200, Mainlander <*@*.*> wrote:

    >In article <>,
    >te**yson@caverock.*et.*z.*is'n' says...


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

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


    There has never been a video card installed in this machine. It has
    always only had the standard Win 95 Cirrus driver. Yet it has played
    video for me in the past. So I think your statement that the standard
    video driver 'doesn't do video' is incorrect.

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


    I have no video card, and never have had one.

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

    >
    >Does it matter - no.
    >


    It doesn't matter to this problem. I'm still interested in finding
    out though.

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


    Vulnerability can be managed. Purging all traces of MS Outlook and
    the windows address book is a good start. As can keeping an up to
    date virus scanner that checks out any incoming e-mail attachments.

    SNOOPY





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

    --
     
    Snoopy, Aug 17, 2003
    #9
  10. Snoopy

    Snoopy Guest

    On Sun, 17 Aug 2003 00:30:13 +1200, Mainlander <*@*.*> wrote:

    >In article <>,
    >te**yson@caverock.*et.*z.*is'n' says...
    >> On Fri, 15 Aug 2003 13:30:26 -0400, "Patrick Bold"
    >> <> wrote:
    >>

    >
    >Activemovie is part of Media Player now, forget it.
    >


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

    >
    >Just reinstall Windows.
    >

    Tried that. It failed to fix the problem
    >
    >A lot of apps aren't even available for Windows 95 now.
    >

    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

    --
     
    Snoopy, Aug 17, 2003
    #10
  11. In article <>,
    te**yson@caverock.*et.*z.*is'n' says...
    > What is the logic behind having a 'C runtime library forwarder'?
    > Does it just transfer execution to the 'C Runtime Library'?
    >
    > If so, why have it at all? It seems not to be needed. So the
    > forwarder must do something. What?


    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.

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


    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.

    --

    Please note munged reply address - delete the obvious ....
     
    Peter Huebner, Aug 17, 2003
    #11
  12. Peter Huebner wrote:
    > 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)
    >


    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
     
    Nicholas Sherlock, Aug 17, 2003
    #12
  13. In article <bhnhib$ceq$>, says...
    > 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.

    --

    Please note munged reply address - delete the obvious ....
     
    Peter Huebner, Aug 19, 2003
    #13
  14. Snoopy

    Snoopy Guest

    On Sun, 17 Aug 2003 21:03:40 +1200, Peter Huebner
    <> wrote:

    >In article <>,
    >te**yson@caverock.*et.*z.*is'n' says...
    >> What is the logic behind having a 'C runtime library forwarder'?
    >> Does it just transfer execution to the 'C Runtime Library'?
    >>
    >> If so, why have it at all? It seems not to be needed. So the
    >> forwarder must do something. What?

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


    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

    --
     
    Snoopy, Aug 20, 2003
    #14
  15. Snoopy

    Mainlander Guest

    In article <>,
    says...
    > In article <bhnhib$ceq$>, says...
    > > 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).


    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
    #15
  16. Mainlander wrote:
    > 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
     
    Nicholas Sherlock, Aug 24, 2003
    #16
  17. Snoopy

    Mainlander Guest

    In article <bi9aq5$k3k$>, says...
    > Mainlander wrote:
    > > 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.


    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.

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


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

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


    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
    #17
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MiniEmma

    winlogon has caused an error in MSVCRT.DLL

    MiniEmma, May 4, 2004, in forum: Computer Support
    Replies:
    13
    Views:
    991
    MiniEmma
    May 11, 2004
  2. Loz

    msvcrt.dll???????

    Loz, Sep 16, 2004, in forum: Computer Support
    Replies:
    4
    Views:
    5,658
    juanpenaz
    Oct 8, 2007
  3. Peter

    kernel32.dll &msvcrt.dll

    Peter, Feb 9, 2004, in forum: NZ Computing
    Replies:
    2
    Views:
    369
    Peter
    Feb 10, 2004
  4. Peter

    kernel32.dll and msvcrt.dll Errors

    Peter, Feb 11, 2004, in forum: NZ Computing
    Replies:
    8
    Views:
    492
    Gavin Tunney
    Feb 14, 2004
  5. Peter

    kernel32.dll & msvcrt.dll

    Peter, Feb 14, 2004, in forum: NZ Computing
    Replies:
    0
    Views:
    397
    Peter
    Feb 14, 2004
Loading...

Share This Page