[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] DLL conflict between wget and curl
From: |
Henrik Holst |
Subject: |
Re: [Bug-wget] DLL conflict between wget and curl |
Date: |
Sun, 29 Apr 2012 15:33:23 +0200 |
Actually Windows does not work like you describe, it uses the already
loaded dll only if it would be loaded by the same path. So Windows can have
multiple versions of the same dll in ram if they are loaded from different
paths.
/hh
Den 29 apr 2012 04:46 skrev "David H. Lipman" <address@hidden>:
> From: "Jeremy Nicoll - ml wget users" <address@hidden<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://multi-av.thespykiller.co.uk>
> http://www.pctipp.ch/**downloads/dl/35905.asp<http://www.pctipp.ch/downloads/dl/35905.asp>
>
>
>
- Re: [Bug-wget] DLL conflict between wget and curl, (continued)
- Re: [Bug-wget] DLL conflict between wget and curl, Ángel González, 2012/04/28
- Re: [Bug-wget] DLL conflict between wget and curl, Jeremy Nicoll - ml wget users, 2012/04/28
- Re: [Bug-wget] DLL conflict between wget and curl, Ángel González, 2012/04/28
- Re: [Bug-wget] DLL conflict between wget and curl, Ray Satiro, 2012/04/28
- Re: [Bug-wget] DLL conflict between wget and curl, Tobias Senz, 2012/04/29
- Re: [Bug-wget] DLL conflict between wget and curl, Jeremy Nicoll - ml wget users, 2012/04/29
- Re: [Bug-wget] DLL conflict between wget and curl, Henrik Holst, 2012/04/29
Re: [Bug-wget] DLL conflict between wget and curl, David H. Lipman, 2012/04/28