Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!adm!rbbb@rice.edu
From: rbbb@rice.edu
Newsgroups: comp.lang.c
Subject: Re: Shared run-time libraries
Message-ID: <6644@brl-adm.ARPA>
Date: Wed, 1-Apr-87 14:09:59 EST
Article-I.D.: brl-adm.6644
Posted: Wed Apr  1 14:09:59 1987
Date-Received: Sat, 4-Apr-87 07:51:25 EST
Sender: news@brl-adm.ARPA
Lines: 28

> There is a third and much more efficient way:
> 	Shared resident libraries.

This is a good idea, but how are they implemented/administered?
VMS has these, and they are great when used intelligently (I ran a VMS
machine once, so of course they were used intelligently :-), but their
administration under VMSes 2.* and 3.* left something to be desired.

There, to install a library or an image as shared required special
privileges.  This was partly because of the consumption of Valuable System
Resources, partly because of the security problem (can you say Trojan
termites?), and partly because VMS also allowed shared programs and
libraries to run with special privileges (remember that VMS has a much
more fine-grained allocation of privileges than Unix).  I believe under
VMS 2.* that an uncoordinated library replacement could crash the machine,
too, but this was definitely fixed in one of the later version of 3.*.

There is also the Simple Matter of Implementation (reference-counts on
your pages, more things that Must Be Done when a process/"image" exits).
You have to be careful here, or you might end up with the famed
process-creation non-performance of VMS.  Think also about debugging code
that links against a shared library.

Comments (administration, implementation, interactions) on how it is done
in later versions of VMS, Apollo, versions of Unix?  Send them to me, I'll
summarize.

David