Re: Windows and DLLs

[Christopher Curtis <ccurtis ee fit edu>]

On Wed, 30 Sep 1998, David Jeske wrote:

> On Wed, Sep 30, 1998 at 09:51:04PM -0400, Federico Mena Quintero wrote:
    [credit snipped]
> > >  Y'all might be interested in knowing about Microsoft's solution to their DLL
> > >  Hell problem; it's called Windows Installer.
> > 
> > Can we *PLEASE* end this discussion?  It is completely off-topic for
> > this list.
> 
> I completely disagree, Gnome is challenged with making a desktop for

Here I go again ... ignore the thread for a long time and then chime in.
These are my thoughts, nothing more ... =)


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>

Changes in the <micro> version should not change anything.  Any program
that compiled against any library with the same major and minor versions
should build regardless of the micro version.

Changes in the <minor> version indicate, typically, featuritis.  Something
with a higher minor version may have added functionality not available in
the library with the same major version but a lower minor version.
Programs written for a lower minor version should compile with a higher
minor version, given that the major version is the same.  Conversely,
programs written for a higher minor version may not work with a library
with a lower minor version (it depends on the program using the new
features of the newer library - it may compile with an older version
afterall but this should be unlikely).

Changes in the <major> version indicate a modification to the API, or a
new 'dialect' of the library.  This will be completely incompatible with
versions of the library with a lower major version number.  The difference
is that anything compiled for a lesser version of this library is
guaranteed not to work.


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:

libMyLib.a.1.6.9
libMyLib.a.1.6 -> libMyLib.a.1.6.9
libMyLib.a.1.8.20
libMyLib.a.1.8 -> libMyLib.a.1.8.20
libMyLib.a.1 -> libMyLib.a.1.8.20

And when the program is compiled, it should link against the proper
library.  The linker will try its best to use the most proper library, but
you may have to specify this when compiling your programs.

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.  However, these problems are bound to appear during development
cycles so it's not wholly "their fault".  On the other hand, they seem to
be trying to imitate the linux kernel system of odd numbers being
development and even being stable - this does not work 100% for libraries;
in that sense, they are doing it wrong and should properly change the next
higher version number.  Then following that system, though, the scenario
changes to be that of even numbers (and zero) being development and odd
numbers being stable.

Now, I'm not trying to criticize the GTK+ people - just trying to give an
example of how people are currently having problems and that there is a
solution that does not require reinventing a library system that has held
up for the past twenty years.

GNOME is not Windows.  Unix is not Windows.  Do not look to Windows for
new ways of making old mistakes.


Christopher