bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] DLL conflict between wget and curl


From: David H. Lipman
Subject: Re: [Bug-wget] DLL conflict between wget and curl
Date: Sat, 28 Apr 2012 22:45:57 -0400

From: "Jeremy Nicoll - ml wget users" <address@hidden>

Win-32 XP Pro SP3

A few hours ago I downloaded cURL, unpacked its zip, and moved the exe and
necessary DLLs to the folder where I keep CLI programs.  That is:

   curl.exe          659 KB    V7.25.0.0
   libcurl.dll       529 KB    V7.25.0.0
   libeay32.dll     1516 KB    no version number
   libssl32.dll      345 KB    no version number

Then I moved on to do the same for wget.   But the dependencies zip comes
with 4 DLLs:

   libeay32.dll     1150 KB    V0.9.8.8
   libiconv2.dll     985 KB    V1.12.2872.39125
   libintl3.dll      101 KB    V0.14.4.1952
   libssl32.dll      228 KB    V0.9.8.8

Clearly I can't put the libeay32 & libssl32 DLLs supplied with wget into the
same folder as the two that came with curl.  And because Windows Explorer
shows no version number info for the ones that came with curl, I don't know
which ones are the more recent versions.

Even if I did know that, I don't know whether it's good practice to keep
each exe with the specific versions of DLLs it was shipped with (though I
suspect that IS the best method) or whether one should just install the most
recent version of each libxxxx.dll and hope.

If the DLLs need kept separately then it follows that neither set should be in a folder on PATH, and I suppose that neither curl.exe nor wget.exe should
be either.  Is the solution to this problem to put each app in its own
folder and alway specify the path to the exe when I want to use it?


Here's what I see in the problem...

When an EXE makes a call to a DLL if it is in the same folder as the executable then it loads it. If it doesn't exist in that folder then it will attempt to load the DLL from the PATH. If the DLL is not found in the PATH the program will error out. This behaviour can be modified by a Registry tweak.

The problem occurs when an EXE loads DEPENDENT.DLL version X and is now loaded in memory. Then a second application loads that wants the same DLL but expects version Y. Since the DLL is loaded in memory the second application loads without error. However since version X is loaded not version Y when the second application makes a call to a DLL function it does not return what is expcted and then second application either does not work correctly or it generates an error message.

If it is a case where an EXE loads DEPENDENT.DLL version X and then exits, the DEPENDENT.DLL is unloaded. If it is a case where an EXE loads DEPENDENT.DLL version X and stays resident, then you may have problems.


--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp




reply via email to

[Prev in Thread] Current Thread [Next in Thread]