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

[Jeremy Nicoll - ml wget users]

Micah Cowan <address@hidden> wrote:

>Welcome to Windows' infamous DLL hell ;)
>
>On 04/27/2012 01:16 PM, Jeremy Nicoll - ml wget users wrote:
>> 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.
>
> I'm not sure that follows - doesn't Windows generally look for DLLs first
> in the same directory as the executable that's being run?

I don't know.  

> If so, then it should be fine to put each in separate folders that are
> each on PATH.

The trouble with that is one could end up with tens or even hundreds of
separate directories on PATH, which must have implications for the way it
gets searched. 

(I have no idea if Windows reads the contents of each dir on path once and
caches that, then uses WMI or something to update the cache if any
subsidiary library gets altered - somehow I doubt it; I suspect a search
happens dir by dir, every time).


> Many, many Windows applications seem to ship with the DLLs they want, and
> keep them in the same dir... but perhaps they also do some path
> manipulation before firing, I dunno...

Apps installed in eg C:\Program Files\ aren't usually on PATH at all;
they're located by explicit paths to the .exe being stored in the registry
as part of the command required to start the app etc.


>> 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?
>
> Otherwise, if I'm wrong, then yeah, this is probably the way to go. Though
> perhaps you could write .bat wrappers around each that you place on PATH.

I'm doing it this way (unpacking zips and putting stuff where I want) rather
than using the SETUP installer, because (a) I like to know how the different
bits relate to each other, and (b) I only want to do it once for multiple
machines.  The straightforward single-executable only standalone CLI stuff
goes into

    C:\My Dropbox\CLIpgms\

(which /is/ on PATH on each machine).   Looks like these apps will go into

    C:\My Dropbox\Machine--ALL-\curl 7-25-0\       and   
    C:\My Dropbox\Machine--ALL-\wget 1-11-4-1\

then scripts use my %JN_DROPBXRT% environment variable to find where Dropbox
is, and assemble the rest of the path from known values. 

The sort of app that needs a full installer-type setup run, but gives me a
choice of where I put it (so not in C:\Program Files\ tends now to end up in

    C:\My Dropbox\Machine-xxxxx\vendor appname version\

(where xxxxx is a machine-id).  Although this means Dropbox ends up with
several copies of the app, I never have to think about backing any of it up,
whereas stuff in C:\Program Files\ does need separate backup (or is so
standard eg optional extra parts of Windows that I don't bother).  

The multiple copies thing is a nuisance but it also means that any badly
behaved apps which store config info in their install dir (or any I've
altered to do that, eg to modify a 'default' <slaps own wrist>) have those
differences visible in the copies, from any machine, and I can see at a
glance which apps/versions are installed on any machine from any machine.

-- 
Jeremy C B Nicoll - my opinions are my own.