Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!reid%Shasta@su-score
From: reid%Shasta@su-sc...@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Shared library free-for-all
Message-ID: <4196@sri-arpa.UUCP>
Date: Sat, 20-Aug-83 01:31:00 EDT
Article-I.D.: sri-arpa.4196
Posted: Sat Aug 20 01:31:00 1983
Date-Received: Sun, 14-Aug-83 20:32:57 EDT
Lines: 50

From:  Brian Reid <reid%Shasta@su-score>

I'm so amused by all of the re-invention of 20-year-old computer science that
I'm almost afraid to say anything for fear this entertaining little fantasy
might die down. But good heavens, folks: the @i[ability] to share is
absolutely not the @i[requirement] to share.

Let's suppose we make a library that we are going to share. We can call it
"/usr/lib/libShare.z" or we can call it "George"; the name doesn't matter.
What this means is that when we load an executable program, before it
actually starts to execute, part of its address space is made to come from
some in-core copy of that library. We assume that other people are also using
it, and that that sharing saves space, which is good and wonderful.

Now let's suppose that we want to change that library, fix some bug, redefine
some calling sequence. What do we do? We create a new shared library with a
different name. Then any program that wants to use the old one can continue
to use the old one, and any program that wants to use the new one can use the
new one.

This procedure can be easily automated. Translating it into Unix-like
vocabulary, one might create a central file named, perhaps,
/usr/lib/ShareVersion. Into this file would be placed some serial number.
Initially "1", let's say it is now "23". When a program is being linked, the
current contents of /usr/lib/ShareVersion would be used to generate the name
of the shared library that will be referenced; in this case, the a.out file
would contain a reference to the shared library /usr/lib/shared/lib23, or
some such. As long as that file continues to exist, then every program that
needs lib23 will continue to work forever. Meanwhile, eager hackers can go on
and create lib24, lib25, and so forth as needed. The linker could easily be
provided with a means to allow user-owned shared libraries, though for
hardware reasons you often want to restrict a program to reference only one
shared library.

This scheme gives you all of the benefits of shared libraries (faster loading,
smaller object files, more efficient memory usage) with almost none of
the drawbacks (dynamic rebinding, incorrect locus of fault detection,
decoupling of cause from effect in library update, etc.)

Unix is the only "modern" operating system that I know of that does not have
some sort of memory sharing. Dennis Ritchie's comment should remind us of
why: that Unix was originated in a backlash against Multics, and
memory-sharing was what Multics was all about.

Didn't you guys learn all about this stuff in your operating systems
classes? Or do people become Unix Wizards by learning only about this one
particular operating system called Unix?

		Brian Reid
		Stanford