in reply to Perl/TK application and DLL hell on Win32

If you place the dlls in the same directory as the executable is loaded from, they should always be found before any similarly named dlls elsewhere on the machine. Other placements are possible and on XP/2003 there are a couple of configuration options and a LoadModuleEx() parameter that can affect the search ordering. See dynamic-link_library_search_order for details, but putting the dlls with the executable is the surest bet.

However, there is a danger(with 95/98/ME? Not NT/2K/XP) with this that if there is an already running application that has the other set of dlls loaded in memory, they will be used instead. One answer to this is to rename the dlls you distribute in some obvious way and ensure that the import records that cause them to be loaded are similarly named. If you do not compile the importing module yourself, you might consider a binary edit to match the names. If the loading is done at runtime rather than load-time, make sure the appropriate constants are updated.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: Perl/TK application and DLL hell on Win32

Replies are listed 'Best First'.
Re^2: Perl/TK application and DLL hell on Win32
by Tanktalus (Canon) on Nov 18, 2005 at 00:49 UTC

    Re that danger you talk about. I thought that Windows got rid of that - if you load two libraries from different locations that they should coexist in memory properly. That was a problem with Win3.1 and Win95+ for sure. I'm not positive about NT3.51 or NT4, but somewhere between W2K and WinXP, I'm pretty sure that problem was licked.

      You are right. I finally found the (only?) relevent passage of the docs (though it is not clear if this applicable to 95/98/ME?

      Note that two DLLs that have the same base file name and extension but are found in different directories are not considered to be the same DLL.

      I'll amend the post above.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.