Ari Heitner wrote:

> > PNG has something similar. It pretty much amazed me when I installed an
> > RPM package of gif2png on my computer, which ran properly (the ELF
> > soname for libpng was compatible), but complained that the older libpng
> > I had did not support a specific feature I was trying to use (gamma
> > compensation or somesuch), and worked for other cases. Excellent
> > versioning, which yielded partial functionality, but better than a
> > dialog box saying something like "DINPUT.DLL not found" or ld.so
> > complaining that it can't launch an application because of missing
> > libraries.
> >
> 
> Speaking as a unix hacker ...

Same here, I just happen to whack a Windows machine or two in the course
of my duties...

> Correct versioning on library names (which MS has *never* had) is what
> supposed to prevent this on unix. And it's a system that's worked pretty
> well.
> 
> Anytime that fails (i.e. the so major version number doesn't indicate
> compability) the authors should be shot. But interfaces can break with a
> component system too (correct versioning is policy, not mechanism ...).

Like Brendan mentioned, they have version information inside the DLLs,
but it seems to be used mainly as a suggestion. Sometimes, when you
install some software, you get a dialog box saying "I'm about to install
FOO.DLL, but you seem to have a newer version", with some information
about both DLLs and two buttons to make your choice. That's where it
starts to get fun. :-)

But no, they do not have allowance for multiple simultaneous
installation of binary incompatible versions in a controlled way. Some
DLLs have version information encoded in their name, like the MFC
libraries, but that's not the majority of them.

-- 
"As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet.  So if it works, you should be doubly impressed."
 -- Linus Torvalds

Reply via email to