[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: Micah Cowan
Subject: Re: [Bug-wget] DLL conflict between wget and curl
Date: Fri, 27 Apr 2012 16:43:07 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1

On 04/27/2012 04:02 PM, address@hidden wrote:
>> Welcome to Windows' infamous DLL hell ;)
> Several years ago I read Gordon Letwin's book "Inside OS/2". There he speaks 
> very, very 
> highly of the concept of "Dynamically Linked Libraries".

Well, surely DLLs are a vast improvement over static libraries.

> The fine thing was that the code in a DLL could be shared by several 
> programs. And - 
> here's the sweet part - every new version of a DLL was perfectly, totally, 
> backwards 
> compatible! You only needed one single version of a DLL on your system. The 
> latest one!

Yeah... that's obviously where it breaks down. This can only work if
every library always maintains perfect API backwards-compatibility. Not
to mention that differences and improvements in library building have
produced other sorts of incompatibilities as well.

> It somehow seems to me Mr. Letwin's dream didn't come true. I've got friends 
> with recent 
> incarnations of Windows. It seems they've introduced some magic to let you 
> have several 
> different versions of the same (same-named) DLL on board at the same time.

Yeah. I like the standard Unix (or at least GNU/Linux?) system that
allows for having multiple versions of a library installed to the
standard paths simultaneously - include the version in the filename,
with symlinks through the major and minor version numbers so you can
link just to the level of version number you expect to care about. The
system's far from perfect, but obviously a huge improvement over the
Windows system (at least, the one I'm familiar with). Windows COM of
course made the bone-headed decision to push the compatibility issue
upon the library developers (in a very ugly way), rather than provide a
more general and automatic solution.

I remember reading through OS X development manuals, and saw that
Applications (and I think Libraries maybe, too?) are simply directory
hierarchies, that can contain the true library files within them, which
strikes me as a convenient way to package library files with an
application, and still allow for them to be individually replaced if
necessary. I don't know whether much advantage is actually taken of that
design, but it struck me as a nice way to do things. (I'm not a Mac
developer, nor a Windows one, so I'm sure my knowledge of both has
gaping holes.)


reply via email to

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