Newsgroups: comp.unix.internals
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Shared libraries are not necessary
Message-ID: <1991May17.075555.29787@Think.COM>
Keywords: ISC i386 shared libraries
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <196@titccy.cc.titech.ac.jp> <1991May16.135009@wsl.dec.com> <202@titccy.cc.titech.ac.jp>
Date: Fri, 17 May 91 07:55:55 GMT

In article <202@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>Those who support shared libraries claimed it is good for software upgrade.
>I disagreed. Usual software upgrade is not so simple. As THEIR (not mine)
>example was introduction of DNS, I proved they are wrong.

There are two kinds of software upgrades: those which change the interface
to the library, and those which only change the implementation.

Most of the common shared library designs only make the second kind simple.
That's certainly better than nothing.

Note that an upgrade to use the DNS didn't *have* to include support for
multiple addresses.  It just so happened that the implementors chose to
make both changes at the same time, because the ability to access more
hosts made this misfeature more noticeable.  I believe they also enhanced
the /etc/hosts version of the routine to return multiple addresses (our
/etc/hosts file has several host names with multiple addresses).  Shared
libraries help with the conversion to DNS, but not with the conversion to
multiple addresses.

In Multics, library design guidelines also make the first kind easy.  Most
library routines with non-trivial parameters take most of the parameters as
a pointer to a structure.  By convention, the first member of the structure
is a version number or version string (in the 80's we started using an
8-character string containing a structure-specific prefix and a version
suffix, so that structures would be recognizable in memory dumps).  The
library routine can look at the version number and determine whether it is
being called with an old version of the parameter structure, and then
emulate the old version of the routine (or return an error code if support
for that version has been dropped, which was rare for documented library
routines).

Some old programs that predated the version conventions look at the
contents of the structure and use heuristics to decide whether it's an old
or new version.  For instance, if the original version of the structure
starts with a number that should never be negative, an upgrade might
implement versioning by requiring that a negative number be placed there,
followed by a version string.  The library routine would emulate the old
version when the structure begins with a non-negative number, but look at
the explicit version string if it's negative.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar