myamin@cbnewsm.att.com (m.yamin) (03/24/91)
From article <1991Mar24.024830.8763@swbatl.sbc.com>, by dwn@swbatl.sbc.com (David Neill-OKCy Mktg 405-278-4007): > In article <2172@estevax.UUCP> iain@estevax.UUCP (Hr Iain Lea) writes: >>Shared libs are available on SysV machines from R3 (?) onwards. ...... > And the 3b1 (aka UNIX-PC, AT&T 7300), a SYSVR2 (approximately) machine > has 'em. In fact, the UnixPC may have had the first released UNIX implementation of shared libraries. Software release 3.5 is copyrighted 1986, and the shared library feature may have been present in earlier releases. M. Yamin my@syscad.att.com
dt@yenta.alb.nm.us (David B. Thomas) (03/25/91)
myamin@cbnewsm.att.com (m.yamin) writes: >In fact, the UnixPC may have had the first released UNIX implementation >of shared libraries. Which brings up a historical question I've wondered about: was the unix pc the first unix machine to feature dynamically loadable device drivers? little david -- Bottom of stack = 0x40000 Stack pointer = 0x3fffe Don't push it!
dws@margay.cs.wisc.edu (DaviD W. Sanderson) (03/25/91)
myamin@cbnewsm.att.com (m.yamin) writes: >In fact, the UnixPC may have had the first released UNIX implementation >of shared libraries. > M. Yamin my@syscad.att.com As far as I know, static shared libraries (as opposed to the dynamic shared libraries in SVR4 and SunOS) were introduced with the UNIX-PC to make UNIX workable (as opposed to possible) on the machine. There are two relevant useful properties of static shared libraries (and dynamic shared libraries, for that matter). 1. Executables linked with a static shared library occupy less disk space than executables linked with the corresponding ordinary archive library. 2. The text of a static shared library is present in memory at most once. Thus executables need less physical memory to run, provided there is at least one other executable using the same library already running. The UNIX-PC had relatively little disk and memory, so for performance (and space) reasons static shared libraries were introduced. Most of the noncritical OS programs were linked with the shared libc; this significantly reduced the overall disk space requirements (I don't remember how much). One advantage of static shared libraries over dynamic shared libraries is that programs using them start more quickly (no "runtime linking" overhead). The BIG disadvantage relative to dynamic shared libraries is that source code maintenance is a headache if you want to create a new version of the library that can be installed and used by programs already linked with an older version of the library. (e.g. creating a new /shlib/libc_s to be installed somewhere WITHOUT having to relink all the programs that use it.) In terms of flexibility and ease of source maintenance (e.g. maintaining one set of source for both the archive and the shared versions of a library), dynamic shared libraries are far superior to static shared libraries. Disclaimer: I worked on shared libraries when I was at AT&T. -- ___ / __\ U N S H I N E DaviD W. Sanderson | | | I N E dws@cs.wisc.edu _____| | |_____ ________ \ / \ |__/ /////__ Fusion Powered Locomotives Made to Order \____/ \__|_/ \\\\\______ (TARDIS model available at extra cost)
cedman@golem.ps.uci.edu (Carl Edman) (03/25/91)
You did not mention one of the greatest advantages of shared libraries
, IMHO:
3. Library bugs can be fixed and even the functionality of a program
extended without requiring recompilation.
Carl Edamn
"We hold that what one man cannot morally do, a million men cannot
morally do, and government, representing many millions of men, cannot
do." -- Auberon Herbert
Send mail to Carl Edman <cedman@golem.ps.uci.edu>varney@cbnewsd.att.com (Al Varney) (03/25/91)
In article <1991Mar24.172224.4514@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: >myamin@cbnewsm.att.com (m.yamin) writes: > >>In fact, the UnixPC may have had the first released UNIX implementation >>of shared libraries. > >Which brings up a historical question I've wondered about: was the unix pc >the first unix machine to feature dynamically loadable device drivers? Answer to the "device driver" question: Nope. These references are from memory, if you really want facts give me a holler (and some time). There's UNIX(tm) and there's stuff that's close. For real UNIX, there was a version called UNIX-RT (real time) that briefly lived under the name MERT (multi-execution real time??). It died for many reasons.... In life, it was a 3-level OS (user, supervisor and kernel) that implemented process-to-process communication via message passing. The kernel implemented a very simple process manager, with swapping. The visible part of UNIX was really a File Manager process and a Task Manager process running as "supervisor"-level processes. Device drivers were loaded dynamically, when the File Manager (or someone) opened them. If there were no active open()s, the device driver could be replaced without a reboot. If the devices were never opened, the drivers just took up space on the system disk. The system also supported real asynchronous I/O direct to user memory, allowing (for example) a double-buffered tape-to-tape copy with huge block sizes to really fly -- but the CPU slowed to a crawl because of memory bandwidth problems. An offshoot of MERT lives on in the 5ESS(tm) Switch. At one time, a UNIX lived on top of the core of IBM's TSS (Time Sharing System) on System 370s, etc. TSS lived a long but totally ignored life as the "real" OS for System 360/67 multiprocessors. It featured many of the time-sharing benefits of UNIX before UNIX existed. Unfortunately, while the features of file-sharing, page swapping, automatic file allocation, shared read-only text, etc. were all there, the implementation was the usual IBM monolith that combined task control, file management and command line interpretation into one unbreakable whole. BUT it did, I'm told, allow for on-the-fly replacement of some portions of the OS, including device access control (or whatever it was called). On the dynamic library topic: TSS implements (it still lives!) a very dynamic form of library loading/sharing. If you incompletely link-edit a module, the unresolved references show up as address FFFFFFFF. When you execute the module, it gets paged in as needed and, if you reference any of the unresolved addresses, the Paging Supv. looks at the symbol table for you module to find the desired name, then looks at all the entry points of all modules on the JOBLIB chain, looking for that name. If the name resolved to a module that could live as shared text, it would attempt to load/use a shared reference. Obviously slow for production stuff, but great for development!!! It has limitations I don't recall, due in part to the "segment table" limits of the paging architecture. So, if you allow a UNIX implemented on "top of" TSS to count, then a System 370 might well have been the first to implement both UNIX shared libraries and UNIX loadable "device drivers".... And for the programmers that got dedicated system time, a sort of BIG UNIX PC... Additional info. on the MERT/UNIX-RT system was in (I believe) the second all-UNIX issue of the Bell System Technical Journal, around 1982?? Al Varney, AT&T, Lisle, IL
dlb5404@tamuts.tamu.edu (Daryl Biberdorf) (03/26/91)
Excuse my naivete, but can anyone tell Brent (Burton) and me how to
use the shared libraries? I'd love some smaller executables.
--Daryl Biberdorf, dlb5404@{tamuts,rigel}.tamu.edu
Texas A&M Universitydws@margay.cs.wisc.edu (DaviD W. Sanderson) (03/26/91)
cedman@golem.ps.uci.edu (Carl Edman) writes: >You did not mention one of the greatest advantages of shared libraries >, IMHO: > >3. Library bugs can be fixed ... > without requiring recompilation. Yes, this is certainly a property of shared libraries, both static and dynamic. However it can be tricky to do, since a program may depend on a bug in the library. Validating that the new library won't break old programs is a hard problem. The same problem exists with ordinary archive libraries, but at least installing a new archive library won't break existing programs linked with an older archive library. My impression is that this property is only periperally an advantage, and mostly a cost, when using static shared libraries. This is because of the difficulties I have already alluded to in creating new, backward compatible static shared libraries. This is not as much of a problem in dynamic shared libraries. >3. and even the functionality of a program >extended without requiring recompilation. A program using static shared libraries can't do anything more than if it weren't using static shared libraries. It just starts faster. So the ability to extend the functionality is limited to what you could do with archive libraries. Of course, if you had your main processing loop as a library function, then you could arbitrarily change what your program did by changing the library. But I don't think this is a typical use. On the other hand, the ability to truly extend the functionality of a program in certain ways without recompilation is entirely within the capabilities of dynamic shared libraries. For instance, a graphics program could have an abstract plotter interface. When the program was about to produce output, it would determine which plotter driver it needed to use, dynamically link it in, use it, and then unlink it. Support for new output devices could be added without recompiling the program. It would certainly be possible to get this particular functionality with separate, specialized i/o programs for each output device, using some sort of communication protocol (temp file, IPC, whatever) with the main program. But it would (I think) be harder to do than simply writing a set of subroutines. -- ___ / __\ U N S H I N E DaviD W. Sanderson | | | I N E dws@cs.wisc.edu _____| | |_____ ________ \ / \ |__/ /////__ Fusion Powered Locomotives Made to Order \____/ \__|_/ \\\\\______ (TARDIS model available at extra cost)
yarvin-norman@cs.yale.edu (Norman Yarvin) (03/26/91)
dws@margay.cs.wisc.edu (DaviD W. Sanderson) writes: > The BIG disadvantage relative to dynamic shared libraries >is that source code maintenance is a headache if you want to create >a new version of the library that can be installed and used by >programs already linked with an older version of the library. The Unix PC ameliorates this difficulty using stub routines. The address to which a call to a shared library function is linked is the address of a jump statement which jumps to the real function. All these jump statements are grouped together at the start of the shared library. Thus programs compiled under any version of the Unix PC shared library run under any other version. Clearly this makes things slightly slower. Also, it still isn't as easy to add new functions to the shared library; for programs that use new shared library functions to be portable between two machines, entries must have been added to the jump table in exactly the same places. -- Norman Yarvin yarvin-norman@cs.yale.edu "Praise the humanities, my boy. That'll make them think you're broadminded!" -- Winston Churchill
clewis@ferret.ocunix.on.ca (Chris Lewis) (03/27/91)
In article <1991Mar24.172224.4514@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: >myamin@cbnewsm.att.com (m.yamin) writes: >>In fact, the UnixPC may have had the first released UNIX implementation >>of shared libraries. >Which brings up a historical question I've wondered about: was the unix pc >the first unix machine to feature dynamically loadable device drivers? Nope. Coherent had 'em back in '81-'82. Or, at least, our port did. (Well, you could argue that Coherent's not UNIX, but it was a lot closer to UNIX then than it is now). -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!
bruce@balilly (Bruce Lilly) (03/27/91)
In article <1991Mar25.063654.23229@cbnewsd.att.com> varney@cbnewsd.att.com (Al Varney) writes: > Additional info. on the MERT/UNIX-RT system was in (I believe) the >second all-UNIX issue of the Bell System Technical Journal, around 1982?? ``The MERT Operating System'' appeared in BSTJ Vol. 57, No. 6 July-August 1978, and is reprinted in ``UNIX(R) SYSTEM Readings and Applications, Volume I'' pp. 142-179 (pub. Prentice-Hall, ISBN 0-13-938532-0). -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
rbj@uunet.UU.NET (Root Boy Jim) (03/28/91)
In article <1991Mar24.172224.4514@yenta.alb.nm.us> dt@yenta.alb.nm.us (David B. Thomas) writes: >myamin@cbnewsm.att.com (m.yamin) writes: > >>In fact, the UnixPC may have had the first released UNIX implementation >>of shared libraries. Gee, um, isn't the kernel a shared library? At least the syscall part. >Which brings up a historical question I've wondered about: was the unix pc >the first unix machine to feature dynamically loadable device drivers? No way! Remember that the PC was a step backward in computing; everything that PC designers had to contend with had already been done years ago. DEC's RSX-11D and IAS (later merged) both featured loadable device drivers. They were actually run as tasks, and a magic system call installed them into the moral equivalent of [bc]devsw and attached their interrupt vectors. RSX also featured shared librarys too. -- [rbj@uunet 1] stty sane unknown mode: sane