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: Ángel González
Subject: Re: [Bug-wget] DLL conflict between wget and curl
Date: Sat, 28 Apr 2012 15:51:56 +0200
User-agent: Thunderbird

On 27/04/12 22:16, Jeremy Nicoll wrote:
> 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:
>From where have you doenloaded them?

> 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.
It depends on what you want. If you want the most stability, sure, keep
the original version. If you want the latest fixes, use the latest
version. libeay32.dll and libssl32.dll are providing openssl. It's
security sensitive (eg. suppose there was a vulnerability in https
decoding leading to code execution) so I'd always use the latest version.
In this case, both programs would probably work with both openssl
versions (it's as simple as trying with each combination and downloading
from a https page), but if one doesn't, I'd download a newer version of
that.


> 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?
Not necessarily. If you have several folders in the PATH, the loader
will search first for a dll with that name in the program folder (time
ago, it wasn't that way, but was later changed).
You also have the option of making a thin wrapper that is placed in the
PATH and just calls the .exe from a different folder.




reply via email to

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