On Thu, 21 Jul 2022 15:43:03 +0200, "R.Wieser"
<add...@nospicedham.not.available> wrote:
>George,
>
>> Sorry, I never used Tasm (any version), but WRT to GetProcAddress
>> I don't believe there is any other way to guarantee you will get
>> the right function.
>
>There is, and I mentioned it just below the 'GetProcAddress' method.
Yes, but it involved recompiling the module. Most people are not in a
position to rebuild system DLLs, so that isn't a general solution.
>> If you know the DLL is already resident you should use GetModuleHandle
>> instead of LoadLibrary.
>
>Does it make a difference ? (whats the 'should' about ?)
'should' means it is the best choice ... at least under the given
circumstances.
And it does make a difference, which I explained previously and will
expound on now:
LoadLibrary manipulates reference counts on the loaded module and
every call to LoadLibrary has to be paired with a call to FreeLibrary.
Unbalanced calls to LoadLibrary can cause a shared DLL to end up
locked into memory.
[Note that application exit automatically calls FreeLibrary for all
DLLs attached to the process. So application exit will balance one
LoadLibrary call for any given library.]
GetModuleHandle just searches for an already loaded module and returns
a handle to it (that can be passed to GetProcAddress).
If you are dealing with an already loaded DLL (for which you don't
have a handle available), you have to do one of the following:
(in C)
hnd = GetModuleHandle( "ComCtl32" );
ptr = GetProcAddress( hnd, "DllGetVersion" );
or
hnd = LoadLibrary( "ComCtl32" );
ptr = GetProcAddress( hnd, "DllGetVersion" );
FreeLibrary( hnd );
Whenever you call LoadLibrary, you also have to call FreeLibrary
UNLESS you are deliberately loading a /new/ DLL and intend it to
remain resident until application exit. And if you do deliberately
load something, you 'should' (best practice) save the returned handle
because it is simpler than having to discover it again later.
I realize the documentation[1,2] says application exit frees libraries
regardless of reference counts ... but "free" in this case means
"detached from your process" and it does not necessarily mean the
library can or will be be unloaded from memory. In particular, if the
library instantiates one or more COM objects based on LoadLibrary
calls (which in general you can't know), and those loads are not
balanced by FreeLibrary calls, the library will never be unloaded (ie.
it will be locked into memory).
NB: DLLs in Windows can have their own private heaps not associated
with any client process. Objects created on a private heap on behalf
of a client process might be able to survive the termination of that
process. COM objects have their own reference counts which are
unrelated to reference counts on the module that implements them.
Windows will not unload any module that still has live COM objects.
To be safe you need to make sure you always balance explicit
LoadLibrary calls with FreeLibrary calls.
>Regards,
>Rudy Wieser
Hope this helps.
George
[1]
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya
[2]
https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-freelibrary