Shared libraries are not necessary

[Guy Harris]

>>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.
>
>And, my claim is that the second kind is almost nothing.
>
>Your (those who support shared libraries) example of DNS prove that.

No, it proves no such thing.  *ONE* example won't prove anything like
that; you'd have to have a reasonably exhaustive list of changes of the
two types listed, and that list would have to show that almost all the
changes were of the first kind.

Changes of the second kind include:

	1) bug fixes to bugs in the implementation, rather than the
	   specification, of a routine;

	2) performance improvements that don't require specification
	   changes;

	3) functionality improvements that don't require specification
	   changes (e.g., changing some lookup routine to check an
	   indexed version of the file being checked, or a network
	   database, such as changing "getpw{nam,uid}()" to use an
	   "ndbm" database, 4.3BSD-style, or to use the NCS Registry or
	   ONC NIS or Hesiod).

And as for whether the DNS upgrade is of the first or second kind, read
on....

>>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).
>
>You believe what? No. They didn't do so.

No, what Berkeley did in 4.3BSD was:

	1) change the specification of "gethost*()" so that, instead of
	   them returning a structure containing, among other members, a
	   "char *" pointing to a single network address, they returned
	   a structure containing a "char **" pointing to the first
	   member of an array of "char *"s pointing to network
	   addresses, the array being terminated by a NULL pointer;

	2) provided an "/etc/hosts"-based implementation of that
	   specification that always returned a pointer to an array with
	   one pointer to a network address, followed by a NULL pointer;

	3) provided a DNS-based implementation of that specification
	   that would return a pointer to an array with one or more
	   pointers to network addresses;

	4) modified at least some programs (e.g, "telnet" and "ftp") so
	   that they would use elements of that array other than the
	   first, if they were provided.

Thus, you have two binary-compatible implementations of the same
specification, and at least some programs capable of making use of the
added capabilities of the second implementation.

What Sun did in SunOS 4.0 was:

	1) pick up Berkeley's change to the specification of
	   "gethost*()";

	2) provide an "/etc/hosts"-or-NIS-based implementation of that
	   specification that provided only one host address;

	3) provided, after 4.0 came out, a version of "libc" that
	   included a DNS-based implementation of that specification
	   that, being based on the 4.3BSD implementation, presumably
	   could provide more than one host address;

	4) picked up, as I remember, at least some of the 4.3BSD
	   modified versions of the programs in question, e.g. "telnet"
	   and "ftp" - can anybody who's actually dropped in the
	   DNS-based version of "libc", and tried to connect to a host
	   with multiple addresses using any of those programs, verify
	   that those programs will try more than just the first
	   address?

Thus, you have any program that uses "gethostbyname()" capable of
picking up the first address for a host from the DNS simply by dropping
in the new shared library; while it won't necessarily handle all the
addresses, it will handle the first, which is better than nothing, and
no worse than what you get with vanilla 4.3BSD.

Those programs that are supplied, in 4.x, in a form that *does* know
about multiple addresses - "telnet" and "ftp" might be among those
programs - will be able to handle all the addresses that the DNS-based
implementation gives them.

>>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
>
>The only parameter for gethostbyname() is, trivially, a string.

And so is the first parameter to "index()"/"strchr()".  So what? He
didn't say the first parameter was "a string", he said it was "a
*VERSION* number or a *VERSION* string".

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.

This still wouldn't mean that programs - whether built for the
4.2BSD-style interface or the 4.3BSD-style interface - that don't know
about the array would magically start using all the addresses they'd
been provided, but they would still use the only (4.2BSD-style) or first
(4.3BSD-style) address they were given, which, again, is no less than
what you get with 4.3BSD.

In this particular case, that version-number trick wouldn't have made a
difference, as shared libraries weren't available prior to 4.0, so any
programs expecting the 4.2BSD-style *binary* interface wouldn't be
affected by the change to the interface.

So what exactly *was* the point you were trying to make with that
comment?  Is it at all relevant to the discussion, or was it a random
unrelated bit of information?