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

[Jeremy Nicoll - ml wget users]

Tobias Senz <address@hidden> wrote:

>Hello!
>
>On 28.04.2012 16:47, Jeremy Nicoll - ml wget users wrote:
>> a) For curl, I looked at the list of packages specified at:
>>    http://curl.haxx.se/download.html  
>> b) for wget, the binaries & dependencies zips described at
>>    http://gnuwin32.sourceforge.net/packages/wget.htm 
>
>Any particular technical reason you're not just using Cygwin?

Ignorance of what it is.

> In theory, if you don't like the installer you could just get the
> particular packages with wget.exe and curl.exe inside and whatever
> libraries they immedeately require.

The problem is finding out what an installer does, before running it.

Because of the way I've chosen to use Dropbox I /really/ prefer the simplest
possible install done once on one machine, which makes the app available on
them all.  It simplifies the problem of having multiple machines to
maintain.

Until now all the CLI tools I've installed have either required no DLLs or
have had just one that the author has provided themselves with their own
support code in it, so typically oneoftheirapps.exe comes with
theirsharedlib.dll, and there's been no problem putting those (and
oneoftheirapps.ini, oneoftheirapps.chm etc) into one common folder.

I've found quite a few apps that come with a choice of zip or setup, and
surprisely often the zip version has very little in it.  It becomes obvious
that the setup version is mainly for people who don't know how to create
shortcuts, quick launch area links etc... whereas I tend (if I use the
installer) either to turn off these fripperies or have to go round the
machine afterwards finding and deleting them.  I also hate installers which
generate no log of what they did.  It's simpler just to copy stuff around
and know what I did and why. 

> It'll tell you one by one when you start the .exe without the neccessary
> .dlls present which ones it requires. There is a search function on
> cygwin.com website to find files inside packages.

The problems I've hit here and presumably because the utilities I'm
installing come from a unix/linux background where there's a different
philosophy about support libaries, which doesn't fit the Windows DLL concept
very well.

My own background is in MVS [now z/OS] systems programming, which of course
has its own ways of solving this sort of problem.  

> If you don't fully know what problems that entails, probably better
> install the normal way.

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