Re: Windows and DLLs

[Christopher Curtis <ccurtis ee fit edu>]

On Thu, 1 Oct 1998, David Jeske wrote:

> On Thu, Oct 01, 1998 at 11:10:18AM -0400, Christopher Curtis wrote:
> > THe Windows problem is self inflicted by releasing different versions of
> > the same library without changing the name.  *nix has already circumvented
> > this problem by properly using library naming conventions.  It can
> > basically be represented as:
> > 
> > lib<library>.[a|so].<major>.<minor>.<micro>
> 
> This does not solve the problem. What happens when:
> 
> 1) a user wants to use an app which only works with a newer
> lib. (i.e. he can't install it easily unless he's administrator, or a
> unix wizard)

He puts the library in his home directory and adds $HOME to his
LD_LIBRARY_PATH.  Do you want users downloading apps and installing
unknown libraries in system locations?  That's Part II of the Windows
Problem.  Rarely do programs the user downloads require special shared
libraries anyway.  That's how it is when programs ship as source code.

> 2) a newer micro version of a lib fixes a bug which caused problems
> with some app, but the fix causes problems with another app.

This is a problem with the library.  If it causes problems with another
app then it needs either to increase the Major number, or release another
micro-level bugfix.  There is nothing at either the micro or minor level
should should break existing compatibility - as I said originally.

> > This is a pretty well known system for unices, and has been very
> > successful.  The problems with it now are that some developers are not
> > following these guidelines, or that installations are not properly
> > creating correct links, or that programs are not being compiled with the
> > right 'hints'.  For example, /lib should look like:
> 
> This is only going to get worse as the number of apps and developers
> gets larger. That is my point. In other words:

Your point, then, is that developers are stupid.  Windows has no means to
resolve this issue, at least none that is currently implemented in any
standard means.  This is not true for Unix.  Play by the rules or suffer
the wrath of your users.

> > One of the problems people have now is with GTK+ and the GIMP.  The
> > problem here is that the GTK people aren't really following the rules. 
> > GTK+ version 1.1 should be backwards compatible with GTK+ 1.0 (same major
> > version number), but have significant performance increases or new
> > widgets.  
> 
> This is exactly why I think the UNIX lib system is just as broken as
> the windows lib system. I think that _what works_ should define
> compatibility, not what is 'supposed to work'. If someone puts out

Well, if you read the followup to my post, I was wrong.  The GTK+ people
have different version for their libraries than they do for their toolkit.
I find this rather confusing, but it should not be a problem.  If it is a
problem, it's probably a RedHat based problem, like so many posts of
people complaining about problems.  Half of libraries "being done right"
is that the person who puts together your dist does it right as well.

> GTK-1.1, I don't care what they decided to name the lib, I want
> programs to be bound to that lib which are known to work with that
> lib. If a program is known to have a problem with 1.1, then it should
> keep binding to 1.0. This information should _not_ be hard-coded into
> the install location of the lib and some archaic static system for
> binding together apps and libs.

If a program has trouble binding to 1.1, the library should be called 2.0.
The information is not hard-coded into the install location of the lib
(whatever that means).  The information about what library is needed is
compiled into the program and ld.so resolves what library it gets, no
matter where the library physically sits.

Christopher