From: gneuner2@nospicedham.comcast.net   
      
   On Thu, 21 Jul 2022 15:43:03 +0200, "R.Wieser"   
    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/   
   f-libloaderapi-loadlibrarya   
   [2]   
   https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/   
   f-libloaderapi-freelibrary   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)