Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!ittatc!dcdwest!sdcsvax!ncr-sd!hp-sdd!hplabs!pyramid!amiga!skipper!cbmvax!higgin
From: higgin@cbmvax.cbm.UUCP (Paul Higginbottom)
Newsgroups: net.micro.amiga
Subject: Re: Libraries
Message-ID: <452@cbmvax.cbmvax.cbm.UUCP>
Date: Wed, 25-Jun-86 12:41:46 EDT
Article-I.D.: cbmvax.452
Posted: Wed Jun 25 12:41:46 1986
Date-Received: Sat, 28-Jun-86 05:20:36 EDT
References: <552@3comvax.UUCP>
Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom)
Organization: Commodore Technology, West Chester, PA
Lines: 80

In article <552@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes:
>... Everyone typically thinks
>of a "library manager" as a program that builds/extracts/adds binary object
>modules to a collection of modules (the Library), which the linker can use
>to link with.  However, the Amiga supports a different kind of library, which
>can be loaded and used by many programs at the same time (i.e.
>translator.library).  These libraries are much more impressive and powerful
>than the standard libraries, yet it seems near impossible to make use of this
>power by simply generating new libraries as applications demand it.
          ^^^^^^

          HA HA HA!

>The problem is that these libraries are not 'C' oriented and have a lot of
>BCPL type of things in them.

	WRONG.

>To me, it seems obvious that a librarian that
>allowed for the addition, removal, etc., of modules from LOADABLE libraries
>would radically change the way we develop programs and would not only make
>Amiga programs smaller (one copy of the library for all programs who use
>it, instead of each program having it's own copy of the required routines),
>but would also take more advantage of the Amiga's software design.

	Ya don't say?  Well, it just so happens, the myself and two colleagues
have written our own loadable-(shared)library to do what you say, and it was
a REAL PAIN IN THE BEHIND.  The idea of loadable libraries certainly isn't
unique to the Amiga, either.

>So, what would such a librarian be used for?  Well, let's see, if you put
>printf() and the rest of the Lattice library into a runnable library, evey
>'C' program instantly becomes 10K shorter (or is it 15K:)...

	We did this.  Under Aztec C though, printf( only accouts for about 4K.

>OK, so what is involved in making such a librarian?

	Lots! believe me.  Look at appendix K in the Rom Kernel manual volume
2, and you'll see what Amiga calls a "skeleton" library.  There is NO
EXPLANATION of this anywhere except for the comments in it.  Good luck, Mr.
Phelps.

>Well, at least there is the BCPL environment stuff that must be maintained
>as well as jump tables, linking in new modules,
>removing old modules, etc.

I'm not sure that you're clear on how PROGRAMS call library routines.
When you link your C programs together, your calls to RK routines are actually
calls to "stubs" extracted from the link-library (e.g. lc.lib, or c.lib,
whatever).  These stubs use the pointer you initialize when you open a
library (e.g, IntuitionBase) and offset from there to call the appropriate
routine indirectly through a vector table.  You may have wondered why when
you open a library, you HAVE to use the variables in the examples.  That's
because they're referenced by the stubs.  Also, that's why they HAVE to be
global to your program.

>Then there is the problem of letting the ROM
>Kernel know that there is a new library.

This happens automatically when a program tries to open the library.  If it
already open, Exec's OpenLibrary() simply returns a pointer to the RAM
resident copy.

>Also, there might need to be more
>information kept about the library than the library allows for (and still is
>recognized as a library) - this stuff can be kept in a separate file with
>a special dot extension or something.

Huh?  A library can keep track of whatever it pleases.

>And when the library maker is done, there is always a device maker to do...

Once you've done one, the other is a piece of cake.

	Here speaketh a weary man of experience in this department,

		Paul Higginbottom

Disclaimer: I do not work for Commodore, and opinions expressed are my own.