Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!husc4!hadeishi
From: hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi)
Newsgroups: comp.sys.amiga
Subject: Re: Run-time named library vectors... suggestion for 1.3
Message-ID: <2215@husc6.UUCP>
Date: Sat, 6-Jun-87 12:16:39 EDT
Article-I.D.: husc6.2215
Posted: Sat Jun  6 12:16:39 1987
Date-Received: Wed, 10-Jun-87 04:15:43 EDT
References: <8706060558.AA04607@cory.Berkeley.EDU>
Sender: news@husc6.UUCP
Reply-To: hadeishi@husc4.UUCP (mitsuharu hadeishi)
Organization: Harvard Univ. Science Center
Lines: 61
Summary: Neat idea, some comments

In article <8706060558.AA04607@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>
>	Here is a neat little tidbit which came out of an operating
>systems project I'm working on:  Named library vectors, initialized on
>program startup.  It would make a *GREAT* addition to 1.3 (can somebody
>give me Dale's email address?).
>
>	It's really simple.  The executable has a new hunk type which is
>basically a table of the names for all unresolved symbols the linker found
>when the program got linked.  The loader would then fill in a vector table
>with the function vectors specified BY NAME in this hunk type.
> . . .
>
>	* making stdio and other routines run-time libraries becomes trivial

	What about load speed?  AmigaDOS is already pretty slow at loading
executables, and doing run-time linking would presumably make it slower.
You'd probably want to make a trade-off between putting things in
run-time libraries and in regular libraries.

>
>	* executables are even SMALLER
>
>	* You needn't link with large static libraries... or any at all.

	Again, for the sake of saving disk space, you probably want to
make a tradeoff between putting stuff in these libraries and in regular
compile-time libraries.  You wouldn't, for example, necessarily put
the entire ANSI C standard library in one of these things; it would
take up a chunk of the Workbench disk with many functions never being used.

>	* by providing an interface to the original library types via this
>	  new scheme, you would simply relink existing object with a 
>	  link-time library which *doesn't* contain the library routines to
>	  make it work with the new libraries (assuming you have a new linker
>	  which supports the new hunk type).

	Or you could implement the new scheme on top of the old library
scheme, which would mean old object would remain compatible.  This would
probably be the ideal way to do it.  The loader could allocate the library
base vectors and open the libraries; there would be a new Exec call
something like "close loaded libraries" which would be the compiler's
responsibility to put in the exit() code, which would close all
libraries opened by the loader (something like the MemList scheme which
no one uses.)  Old code would simply not call "close loaded libraries", and
would close it's libraries manually.  (Of course with resource tracking
the compiler wouldn't have to do this.  Resource tracking, please, please!?
UnLoadSeg() or something would deallocate resources attached to the task,
including libraries.)

	Another point: the new linker should also check the resultant
executable to make sure unresolved function calls would actually be
resolved by existing library functions (presumably the linker could
get a list of names of library functions from Exec somehow).  If the
function would not be resolved in this fashion, then an unresolved
linker error message should be printed.  This is not really necessary,
since the loader would do the same thing, but it would be a handy
service (since the linker could provide more complete information
about where the symbol was unresolved than the loader.)

			-Mitsu