Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!axion!uzi-9mm.fulcrum.bt.co.uk!igb
From: igb@fulcrum.bt.co.uk (Ian G Batten)
Newsgroups: comp.unix.internals
Subject: Re: Shared libraries are not necessary
Keywords: ISC i386 shared libraries
Message-ID: <5DV_MK@uzi-9mm.fulcrum.bt.co.uk>
Date: 23 May 91 08:04:42 GMT
References: <1991May17.075555.29787@Think.COM> <211@titccy.cc.titech.ac.jp> <7972@auspex.auspex.com>
Sender: news@fulcrum.bt.co.uk (News with an UZI)
Organization: BT Fulcrum, Birmingham
Lines: 23

In article <7972@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
> If UNIX routines had followed a Multics-like convention, the first
> parameter to "gethostbyname()" would be a version number or version
> string, with the host name a later parameter; old programs that expect a
> 4.2BSD-like interface would pass in a version number of 1, and would
> have the returned structure contain a pointer to one host address, and
> new programs that expect a 4.3BSD-like interface would pass in a version
> number of 2, and would have the returned structure contain a pointer to
> an array of pointers to host addresses.

I'm surprised that no one has pointed out the isomorphism between the
Multics calling convention (yes, I did hack Multics for a few years) and
the program/function/version number strategy of the (Sun) rpc mechanism.
That, to me, provides a fairly clean way for library routines to be
upgraded, possibly with changes to interface, while providing support
for callers that still want to use the older versions.

I've got a project for which about 60% of access to a set of routines
will be over the network and about 40% will be local.  I'm quite happy
to accept the overhead of making local remote procedure calls on that
40% in order to get the benefits seen above.

ian