Perl/TK application and DLL hell on Win32

jdtoronto has asked for the wisdom of the Perl Monks concerning the following question:

Esteemed monks,

I have a large Win32 Perl/Tk app. It uses LWP and needs https, so it has to use two dll's - libeay32.dll and ssleay32.dll. All is fine provided the machine we install on either had up to date dll's or is able to use the dll's I unpack with the app using ActiveStates PerlApp packager.

But if their are outdated dll's in the Windows or Windows/System32 directories then I appear to be our of luck!

I have had to walk several users through the process of downloading and installing the newer DLL's in their Windows - having found where the files are.

I am almost at the point of writing a Perl based installer that will check out the whole sordid mess and figureo ut what needs to be done to replace the dll's. Is this the right way to do it? Am I missing something?

jdtoronto

Comment on Perl/TK application and DLL hell on Win32

Replies are listed 'Best First'.
Re: Perl/TK application and DLL hell on Win32 by monarch (Priest) on Nov 17, 2005 at 23:58 UTC
sigh I hope there is a better way to do it. I don't know how to resolve this issue. One of the particular problems I have on a Win32 machine is that I like to use wget from GnuWin32. However the `libeay32.dll` and `ssleay32.dll` DLLs are different to the ones downloaded with the ActiveState module: `ppm install http://theoryx5.uwinnipeg.ca/ppms/Crypt-SSLeay.ppd` [download]	[reply] [d/l] [select]
Re: Perl/TK application and DLL hell on Win32 by BrowserUk (Patriarch) on Nov 18, 2005 at 00:35 UTC
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.	[reply]
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.	[reply]
Re^3: Perl/TK application and DLL hell on Win32 by BrowserUk (Patriarch) on Nov 18, 2005 at 01:19 UTC
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.	[reply]
Re: Perl/TK application and DLL hell on Win32 by zentara (Cardinal) on Nov 18, 2005 at 13:39 UTC
Thats not hell, that's a MSWindows "security feature". I'm not really a human, but I play one on earth. flash japh	[reply]