Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!topaz!ll-xn!nike!ucbcad!ucbvax!hplabs!oliveb!3comvax!mykes From: mykes@3comvax.UUCP (Mike Schwartz) Newsgroups: net.micro.amiga Subject: Re: Libraries Message-ID: <559@3comvax.UUCP> Date: Thu, 26-Jun-86 15:06:57 EDT Article-I.D.: 3comvax.559 Posted: Thu Jun 26 15:06:57 1986 Date-Received: Sat, 28-Jun-86 03:34:13 EDT References: <552@3comvax.UUCP> <452@cbmvax.cbmvax.cbm.UUCP> Reply-To: mykes@3comvax.UUCP (Mike Schwartz) Organization: 3Com Corp; Mountain View, CA Lines: 90 In article <452@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >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! What is the laugh about? Read the sentence, it says it seems near impossible to make use of the libraries... Maybe for Paul's sake, I should duplicate all my lines, maybe he'll read what I wrote:) > > >>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. > Well, you proved my point, it's a pain in the behind, so getting the machine to do the work might be a good idea. Your logic is: loadable libraries isn't unique to the Amiga, so that means it is not a feature of the Amiga? Using them does take more advantage of the Amiga's software design. You criticize without reading, chum. >>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. > Some people use lattice, I don't, but 15K is meaningful to those who do. I also mentioned other uses for these libraries, like CLI programs that would save lots of memory with every "newcli" that is run by not having routines that could be in a library duplicated in every instance of the CLI. >>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. > I never said the librarian would be an easy program to write. Give me a break! The trick is to generate a file similar to what the "skeleton" generates when assembled. Computers aren't smart, they are pretty stupid... I hate to break the news to you, but the Amiga will never know that a library was generated by the Assembler, Manx's assembler, or by the librarian I suggest. > >>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. > OK, since I got such a nice lecture about how libraries work (my previous article got merged with one about the DEVICE maker, so it talked about BCPL stuff), I guess I gotta tell you about object module librarians... When you have a runable library librarian, it must be able to remove and add subroutines as you recompile them. You don't need to link everything together all the time to build the library. You keep things like back-patch lists SOMEWHERE (like how about in a different file, now do you understand) so that you can cleanly remove/unlink individual functions from a library and link in new ones. This linkage information is necessary, but is not part of the library file itself. How can the library keep track of this stuff itself? >>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. > Neither is a piece of cake, but either would be very valuble. > Here speaketh a weary man of experience in this department, > > Paul Higginbottom Way to be man of experience... >Disclaimer: I do not work for Commodore, and opinions expressed are my own.