sane@m.cs.uiuc.edu (Aamod Sane) (03/16/91)
I would like to know if shared libraries are a SunOs feature or are available on most flavors of Unix (BSD, SysV)? Please reply by mail if possible, I do not read this group often Thanks Aamod Sane sane@cs.uiuc.edu
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/21/91)
As quoted from <1991Mar16.073109.30717@m.cs.uiuc.edu> by sane@m.cs.uiuc.edu (Aamod Sane): +--------------- | I would like to know if shared libraries are a SunOs feature | or are available on most flavors of Unix (BSD, SysV)? +--------------- System V has shared libraries, but you have to design your libraries for them --- they are *not* trivial to set up. I know little about the SunOS implementation, but it looks rather easier to use. (Has this been addressed in SVR4?) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR on 2m, 220, 440, 1200 Internet: allbery@NCoast.ORG (QRT on HF until local problems fixed) America OnLine: KB8JRR // Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
iain@estevax.UUCP (Hr Iain Lea) (03/22/91)
Shared libs are available on SysV machines from R3 (?) onwards. Not available on BSD normally but SunOS uses a lot of features from SysV.
vinoski@apollo.HP.COM (Stephen Vinoski) (03/22/91)
In article <14503@ulysses.att.com> cjc@ulysses.att.com (Chris Calabrese) writes: >sVr4 has both sVr3 and SunOS style shared libraries. It is assumed >that the SunOS style ones will be the standard, but I don't know of >any plans to get rid of the older ones. On the other hand, I'm >neither a sVr4 guru nor a shared lib guru. Yes, Sun invented shared libraries, even though Apollo has had them since 1980 or 1981... :-) -steve | Steve Vinoski (508)256-0176 x5904 | Internet: vinoski@apollo.hp.com | | HP Apollo Division, Chelmsford, MA 01824 | UUCP: ...!apollo!vinoski | | "The price of knowledge is learning how little of it you yourself harbor." | | - Tom Christiansen |
ldg@drywit.ATT.COM (XGPB30000-GibbonsD(DRR6702)262) (03/23/91)
From article <1991Mar21.035115.21842@NCoast.ORG>, by allbery@NCoast.ORG (Brandon S. Allbery KB8JRR): > > System V has shared libraries, but you have to design your libraries for them > --- they are *not* trivial to set up. I know little about the SunOS > implementation, but it looks rather easier to use. > > (Has this been addressed in SVR4?) > > ++Brandon > -- SVR4 has indeed addressed this question. The implementation of shared libraries, or "shared objects" in SVR4 is based upon the Sun design. The SVR4 shared object is easier to make and use than its SVR3 counterpart, and the performance issues are similar. A good treatment on this subject can be found in the "UNIX System V Programmer's Guide: ANSI C and Programming Support Tools. This book is shipped with the AT&T ANSI C compiler software. Also, see the "System V Application Binary Interface" - ISBN 0-13-877598-2. -- -------------------------------------------------------------------------------- -- Doug Gibbons | ldg@druhi.ATT.COM or att!druhi!ldg -- AT&T Bell Laboratories -- Denver CO
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (03/23/91)
In article <5084a913.20b6d@apollo.HP.COM>, vinoski@apollo.HP.COM (Stephen Vinoski) writes: > > Yes, Sun invented shared libraries, even though Apollo has had them since > 1980 or 1981... :-) Not to mention Multics.... ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau Research Triangle Park, NC 27709, USA
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/23/91)
In article <1991Mar21.035115.21842@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: > As quoted from <1991Mar16.073109.30717@m.cs.uiuc.edu> by sane@m.cs.uiuc.edu (Aamod Sane): > +--------------- > | I would like to know if shared libraries are a SunOs feature > | or are available on most flavors of Unix (BSD, SysV)? > +--------------- SunOS doesn't have shared libraries - yet. (As of 4.1, that being the latest I've worked on to any extent.) It does have shared objects; they are not libraries except in the broad sense of the term. When ld.so brings in a .so file, you get the whole thing.... Vanilla 4.3BSD does not have anything of the sort. I don't know about more recent versions (eg, 4.3-tahoe, 4.3-Reno...). der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dwn@swbatl.sbc.com (David Neill-OKCy Mktg 405-278-4007) (03/24/91)
In article <2172@estevax.UUCP> iain@estevax.UUCP (Hr Iain Lea) writes: >Shared libs are available on SysV machines from R3 (?) onwards. > >Not available on BSD normally but SunOS uses a lot of features from SysV. And the 3b1 (aka UNIX-PC, AT&T 7300), a SYSVR2 (approximately) machine has 'em. -- name & address (this account) -> dwn@swbatl.sbc.com David Neill office -> 405-291-1990 -> ..texbell!oktext!mktco Mgr - Mktg.(SWBTCo) home -> 405-843-4464 -> ..texbell!oktext!frodo!david
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
urban@cbnewsl.att.com (john.urban) (03/26/91)
In article <13727@helios.TAMU.EDU> dlb5404@tamuts.tamu.edu (Daryl Biberdorf) writes: >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 University In UNIX System V/386 Release 3.2 the C Issue 4.1.5 or 4.1.6 uses Static Shared Libraries. The default compiler/linker/loaded option is to NOT use them. Therefore to link-edit with the static shared libaries use: cc -O -o foo foo.c -lc_s -lnsl_s In UNIX System V/386 Release 4.0 the C Issue 5.0 uses Dynamic Shared Libraries. The default compiler/linker/loader option is to use these libraries. Therefore to link-edit with out the dynamic shared libraries use: cc -O -o foo foo.c -dn cc -O -o foo foo.c -dy <- Dynamic Yes is the default UNIX System V/386 Release 4.0 distributes the 3.2 Static shared libraries (/shlib) so applications using 3.2 Static shared libraries will run on 4.0 as they did on 3.2 Other Operating Systems/Compilers that offer Shared libaries will be probably be different. Sincerely, John Ben Urban
chughes@maths.tcd.ie (Conrad Hughes) (03/26/91)
Acorn's Unix workstations (R140, R225, R260) use shared libraries, as do all their Archimedes range of microcomputers.. The workstations also automatically use an invisible compress on executables. Conrad -- Will you sell me one of those if I shave my head Get me out of town is what Fireball said Never trust a man in a blue trench coat Never drive a car when you're dead Tom Waits
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!
dws@margay.cs.wisc.edu (DaviD W. Sanderson) (03/27/91)
In article <29682@cs.yale.edu> yarvin-norman@cs.yale.edu (Norman Yarvin) writes: >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. Yes, it is relatively easy to deal with functions in static shared libraries. However, persistent data is a different story. There is no (supported) equivalent concept of a "junk table" allowing an indirection in access to data (that is transparent to the source code). You have to guarantee that your new data structures sit at the same place in memory and have the *same size* as in the earlier versions of the library. One concrete example where this comes up is upgrading the stdio part of libc (or any other part that uses persistent data). It was a real pain (so I heard, I didn't do it) to upgrade the shared libc to handle multibyte characters (and thus multibyte pushback) for ANSI C support, because the composition of the existing _iob[] array could not be changed. In order to make the guarantees about the external data you have to separate out all the declarations of *any* persistent data into source files separate from where the functions are defined, so that you can group the corresponding object files at the beginning of the static shared library. Then whenever you add new persistent data you add the corresponding object file onto the end of the existing data object files. You cannot alter the composition of the preexisting persistent data without risking breaking compatibility with older versions of the library. Dynamic shared libraries impose none of these silly source code conventions. -- ___ / __\ 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)
guy@auspex.auspex.com (Guy Harris) (03/27/91)
>System V has shared libraries, but you have to design your libraries for them >--- they are *not* trivial to set up. I know little about the SunOS >implementation, but it looks rather easier to use. > >(Has this been addressed in SVR4?) Yes. S5R4's shared library implementation is derived from SunOS's (and also includes the run-time dynamic linking routines "dlopen()", "dlsym()", etc. that showed up in SunOS 4.1).
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
dws@margay.cs.wisc.edu (DaviD W. Sanderson) (03/27/91)
In article <6835@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > S5R4's shared library implementation is derived from SunOS's >(and also includes the run-time dynamic linking routines "dlopen()", >"dlsym()", etc. that showed up in SunOS 4.1). This is not entirely true. Yes, the SVR4 dynamic shared libraries began with the SunOS shared libraries. But the programming interface (dlopen() et al) and many performance improvements were done at AT&T for SVR4. These additional features were then adopted by Sun for later versions of SunOS. I don't know for sure how much of the AT&T code Sun wound up using, since I don't know if the latest SunOS shared libraries are in ELF format, as the AT&T ones are. -- ___ / __\ 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)
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
guy@auspex.auspex.com (Guy Harris) (03/28/91)
>Not available on BSD normally but SunOS uses a lot of features from SysV.
And System V uses a lot of features from SunOS as well; in particular,
the S5R4 shared library implementation is derived from that of SunOS 4.x.guy@auspex.auspex.com (Guy Harris) (03/28/91)
>Yes, Sun invented shared libraries, even though Apollo has had them since >1980 or 1981... :-) He didn't say Sun had, he was just noting that SVR4 picked up the SunOS implementation. Who knows, perhaps they would have picked up the Apollo implementation, had Apollo been smart enough to license it for UNIX systems (the same could be said for a number of other aspects of Apollo's systems...). (Apollo, of course, didn't invent them, either.)
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (03/28/91)
In article <1991Mar23.000143.3652@dg-rtp.dg.com> goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes: >In article <5084a913.20b6d@apollo.HP.COM>, vinoski@apollo.HP.COM (Stephen Vinoski) writes: >> >> Yes, Sun invented shared libraries, even though Apollo has had them since >> 1980 or 1981... :-) > >Not to mention Multics.... Or RCA TSOS, which had 'em in 1971. The booger could support 55 users in 1 meg of memory. (Of course the users were using ASR-33s for the most part). ---------------------------------------------------------------------------- Warren Tucker, TuckerWare, Mountain Park, GA wht@n4hgf.Mt-Park.GA.US "The computer can't tell you the emotional story. It can give you the exact mathematical design, but what's missing is the eyebrows." -- Frank Zappa
oz@yunexus.yorku.ca (Ozan Yigit) (03/28/91)
In article <1991Mar23.000143.3652@dg-rtp.dg.com> goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes: >In article <5084a913.20b6d@apollo.HP.COM>, vinoski@apollo.HP.COM >(Stephen Vinoski) writes: >> >> Yes, Sun invented shared libraries, even though Apollo has had them since >> 1980 or 1981... :-) > >Not to mention Multics.... Indeed. Organick's 1972 book does talk about shared procedures and dynamic loading. DEC's VMS had sharable libraries since about 1979. Everyone knows that Sun invented shared libraries. ;-) --- Yellow pages is evil. All traces of | Internet: oz@nexus.yorku.ca it must be vanguished from the face | Uucp: utzoo/utai!yunexus!oz of the earth. -- Eriks Rugelis | Phone: 1+ (416) 736 5257 ..
rminnich@super.ORG (Ronald G Minnich) (03/29/91)
In article <1991Mar23.000143.3652@dg-rtp.dg.com> goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes: >> Yes, Sun invented shared libraries, even though Apollo has had them since >> 1980 or 1981... :-) >Not to mention Multics.... Well, lets face it: the idea is only slightly younger than Fortran, as these things go. Burroughs had them in the first half of the decade of the 60s. ron -- "Socialism is the road from capitalism to communism, but we never promised to feed you on the way!"-- old Russian saying "Socialism is the torturous road from capitalism to capitalism" -- new Russian saying (Wash. Post 9/16)
martin@adpplz.UUCP (Martin Golding) (03/30/91)
In <387@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >In article <1991Mar23.000143.3652@dg-rtp.dg.com> goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes: >>In article <5084a913.20b6d@apollo.HP.COM>, vinoski@apollo.HP.COM (Stephen Vinoski) writes: >>> >>> Yes, Sun invented shared libraries, even though Apollo has had them since >>> 1980 or 1981... :-) >> >>Not to mention Multics.... >Or RCA TSOS, which had 'em in 1971. The booger could support 55 users >in 1 meg of memory. (Of course the users were using ASR-33s for the most part). I have remained silent for too long, I can't stand it any more, How about Reality, where all the binaries are one shared library, and there is NO static linking. WE could support 64 users in 1 meg of memory, nyah nyah nyah... (Until our application programmers found structured methodologies) And Reality's zero date is before unix's zero date. Martin Golding | sync, sync, sync, sank ... sunk: Dod #0236 | He who steals my code steals trash. A Poor old decrepit Pick(tm) programmer ... Sympathize at: {mcspdx,pdxgate}!adpplz!martin or martin@adpplz.uucp
guy@auspex.auspex.com (Guy Harris) (03/31/91)
>This is not entirely true. Yes, the SVR4 dynamic shared libraries >began with the SunOS shared libraries. But the programming interface >(dlopen() et al) and many performance improvements were done at AT&T >for SVR4. The implementations of "dlopen()" and company were, as I remember, a bit different, even though the interfaces were compatible. Was the interface was originally done by AT&T? (I've asked Rob Gingell as well....) >I don't know for sure how much of the AT&T code Sun wound up using, since >I don't know if the latest SunOS shared libraries are in ELF format, as >the AT&T ones are. SunOS 4.1 doesn't use ELF.
bennett@mp.cs.niu.edu (Scott Bennett) (04/03/91)
In article <6926@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>This is not entirely true. Yes, the SVR4 dynamic shared libraries >>began with the SunOS shared libraries. But the programming interface >>(dlopen() et al) and many performance improvements were done at AT&T >>for SVR4. Well, to add one more to the list that beat out SunOS, I'd like to point to OS/360, which always had both statically and dynamically linked libraries. MVS/XA still does. > >The implementations of "dlopen()" and company were, as I remember, a bit > [text deleted --SJB] > >>I don't know if the latest SunOS shared libraries are in ELF format, as >>the AT&T ones are. > >SunOS 4.1 doesn't use ELF. And now, to return to the subject line ;-), we should note that, among computers currently being sold, the NeXT software also has both statically and dynamically linked libraries. Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************