Re: static vs shared (was: Re: Win vs. UNIX usability )

[David Jeske <jeske home chat net>]

On Wed, Sep 30, 1998 at 02:47:30PM -0500, Alan Shutko wrote:
> >>>>> "L" == Liss Svanberg <lisss@ydab.se> writes:
> 
> L> The windows shared library problem doesn't exist becuse they have
> L> got a different format, it's because virtally every little stupid
> L> program comes with it's own shared librarys.  UNIX (or Gnome or any
> L> app enviroment/OS) can end up there too...  (... and I wouldn't
> L> like it that way)
> 
> No, that's not the problem at all.  If every application came with
> itss own shared libraries _and left other apps libs alone_, there
> would be no problems.

I think you are getting there, but that is not exactly correct. The
problem with shlibs (IMO) is that:

1) they only loosely define compatibility. (i.e. is a bug in an old
shlib guaranteed to be present in a new one for pure backward
compatibilty, not usually)

2) there isn't an easy way to have multiple but compatible versions on
the same system.

3) there isn't an easy way to allow one app to use one version of a
shlib and one app to use another. For example, most apps will look for
something like "libc.so.4", and you connect that to the 'current
version' (be it 4.1 4.2, etc). However, what if one version works with
4.1, and the other works with 4.2?

> But that's not the way it is on Windows.  Apps commonly install copies
> of whatever shared libraries they used, such as the ones which come
> with their compiler, ones which come with the OS, etc.  There's no
> version control to speak of on Windows, so letting apps run the
> version they need is impossible.  So things break.

You are correct in that on windows DLLs often collide, both because
they exist in a common namespace (i.e. they usually get thrown into
\windows\system), and because they replace old DLLs with new DLLs with
the same name.

However, I argue that there shouldn't be version control. There should
be 'compatibility control'. That is, _no_ two shlibs should ever
collide with eachother, ever. Two builds of the same shlib version
shouldn't even collide with eachother, because one might have been
build for ELF and the other for XCOFF, or one might have been built
with AMD K6 3DNow instructions, and the other one with regular x86
instructions.

After we've established that _every_ shlib (and I would extend this
concept to all data, but lets keep it to shlibs right now) has a
globall uniqueness in the world, we should then be defining a
COMPATIBILTY for that shlib. Does it work on K6 processors? Does it
work with GIMP? Does it work with the new Linux Kernel? If we layer
all this information on _top_ of the shlib, instead of sticking it
inside it, then we can constantly update the "compatibility control"
information as more datapoints are gathered by all the users. 

There should be a map which decides how to bind shlibs to an app, and
that map should include the above compatibility information, plus
information about _which_ app is asking, and what they are asking for
exactly.

---

Getting back to the point, I think the UNIX shlib model is just as bad
as the Windows DLL model. The only reason it's a "huge problem" on
Windows is that windows has _tons_ of applications and _tons_ of
DLLs. If we had tons of software on UNIX, and tons of shared
libraries, we would be running into tons of problems also.

> In contrast, I don't see that on Unix or in Gnome.  Apps use shared
> libraries when they want to share functionality between apps.  For
> example, would you want the GNOME libs staticly linked into
> everything?  Or IMLIB?  Maybe zlib should be staticly linked, because
> I've actually seen problems related to having different versions of
> that around.

If zlib is statically linked into two programs, then each program is
going to have 'duplicate' but different code pages. If both programs
use a zlib shlib, then they can share those codepages. However, in
UNIX the shlib system isn't very flexible, so this isn't always
desirable. For example, users often can't install shlibs on the system
(even for use in their own apps). Or it's often a difficult operation
for users to install their own private shlibs, it depends on which
UNIX is being used.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net