Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!amdahl!dlb!dana!rap
From: rap@dana.UUCP (Rob Peck)
Newsgroups: comp.sys.amiga,comp.sys.atari.st,comp.sys.m6809
Subject: Re: True Multitasking, and some history lessons
Message-ID: <178@dana.UUCP>
Date: Mon, 8-Jun-87 13:01:28 EDT
Article-I.D.: dana.178
Posted: Mon Jun  8 13:01:28 1987
Date-Received: Thu, 11-Jun-87 06:28:49 EDT
References: <8706040024.AA10895@cogsci.berkeley.edu> <2194@husc6.UUCP>
Organization: Dana Computer, Inc., Sunnyvale, CA
Lines: 26
Summary: Yes, shared libraries...
Xref: mnetor comp.sys.amiga:5537 comp.sys.atari.st:3903 comp.sys.m6809:331

In article <2194@husc6.UUCP>, hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) writes:
> Things would be even better if someone wrote a shared run-time stdio
> library and other Sys V function library; then multiple executables, even
> totally different executables would have shared text automagically.
> 
> 				-Mitsu
I agree.  Using shared libraries can significantly reduce the size of the
code that any program needs to have.

I have, for example, suggested to the JForth folks that it might be useful
to create a version of JForth that was actually a library rather than
a program so that calling a version of JForth would be a small program
that opened the library effectively passing to the library a new stack
frame and local variables for HERE and so on.  (BTW, they listened with
interest, but are busiest writing the standalone environment compiler
and may not be able to tackle this sort of thing for a while.)

This would place the entire of a forth kernel accessible on a read-only
basis, so to speak, to many programs, with their own individual extensions
accessible on a per-application basis.  Other programs could do the same.
The main limitation, as I see it, is the need to always write reentrant
code (as is necessary for libraries for libraries anyway).

Library of stdio ... good idea, anyone want to tackle it?

Rob Peck	...hplabs!dana!rap