Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > msvcrt.dll, msvcirt.dll, msvcrt20.dll and msvcrt40.dll, explanation please!

Reply
Thread Tools

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

 
 
Peter Huebner
Guest
Posts: n/a
 
      08-17-2003
In article <(E-Mail Removed)>,
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 ....
 
Reply With Quote
 
 
 
 
Nicholas Sherlock
Guest
Posts: n/a
 
      08-17-2003
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


 
Reply With Quote
 
 
 
 
Peter Huebner
Guest
Posts: n/a
 
      08-19-2003
In article <bhnhib$ceq$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed) 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 ....
 
Reply With Quote
 
Snoopy
Guest
Posts: n/a
 
      08-20-2003
On Sun, 17 Aug 2003 21:03:40 +1200, Peter Huebner
<(E-Mail Removed)> wrote:

>In article <(E-Mail Removed)>,
>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

--
 
Reply With Quote
 
Mainlander
Guest
Posts: n/a
 
      08-24-2003
In article <(E-Mail Removed). nz>,
(E-Mail Removed) says...
> In article <bhnhib$ceq$(E-Mail Removed)>, (E-Mail Removed) 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.
 
Reply With Quote
 
Nicholas Sherlock
Guest
Posts: n/a
 
      08-24-2003
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


 
Reply With Quote
 
Mainlander
Guest
Posts: n/a
 
      08-25-2003
In article <bi9aq5$k3k$(E-Mail Removed)>, (E-Mail Removed) 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
explanation of values, references, assignment, and method calls Joe Strout Python 2 10-28-2008 10:15 PM
Explanation of Vptr and V-table pai C++ 4 10-18-2006 02:09 PM
Off topic (with explanation and apologies): Game authoring software for bright pre-adolescent? Steven O. C++ 4 08-17-2005 08:14 AM
Checked and unchecked exceptions. A clearer explanation please. exquisitus Java 4 05-06-2005 12:09 PM
Strange results and no explanation on JVM Paul G. Java 0 08-01-2003 02:42 PM



Advertisments