RE: [Mingw-users] msvcrtd.dll

[Andrew S. <ac...@sy...>]

>-----Original Message-----
>From: min...@li...
>[mailto:min...@li...]On Behalf Of Lorne
>Easton
>Sent: October 5, 2002 00:44
>To: min...@li...
>Subject: [Mingw-users] msvcrtd.dll
>
>
>Hi,
>
>Is there an import library available for msvcrtd.dll? It provides some
>debugging functions for the c runtime. Of particular interest to me
>are_CrtMemCheckpoint() and _CrtMemDifference().
>
>Also, out of curiosity, when exporting DLL functions, I use LoadLibrary(),
>GetProcAddress(), then FreeLibrary() when I am done (i.e: In the
>destructor). So, does LoadLibrary() load the DLL into heap space? I.E: The
>library cannot be freed until all of the proc *s returned by GetProcAddress
>go out of scope or cease being used? If so, how do the import libraries
>work? Don't te related resources have to be freed when the application
>terminates? How is this done?
>
>Regards,
>Lorne

The call to LoadLibrary will load the specified module (dll,exe,(etc.)) and
map the necessary symbols into the calling process's address space, it also
increments the usage count on that module.

GetProcAddress simply returns the mapped address of the requested symbol, it
does not change the reference count on the module, nor does windows make any
attempt to determine what the scope of the variable the address is assigned
to.

When you call FreeLibrary, it decrements the usage count on the module, and
if the module is no longer in use it is un-mapped from the calling process's
address space.

If you don't call FreeLibrary for any module you explicitly loaded, it will
be unloaded when you process exists.

So, in the following sequence and results would be at best undetermined, at
worst probably a BSOD.

LoadLibrary(a)
GetProcAddress(handle,proc);
FreeLibrary(a)
call proc

AFAIK, the import libraries contain 'stubs' of the symbols they represent in
a dll.  When a process is load-time linked with some dll, I believe that the
relocatable symbol's addresses get remapped to the correct addresses in the
dll.  I am by no means an expert in this particular area, so if I'm wrong,
hopefully someone else will correct me.

Andrew.