hamilton@uxc.cso.uiuc.edu.UUCP (07/13/87)
scott norton says: > Hacking one evening with the AmigaMonitor, I noticed that the > dos.library had an Open count over 10, where other libraries had > 2 at most Opens. After calling up a few programs I noticed that > this open count was never decremented. What is going on? ... dos.library is "special". it doesn't follow all the conventions other libraries are expected to honor. in particular, it doesn't decrement its lib_OpenCnt upon close (the WB1.1 version, anyhow). > 1. What really opens the dos.library? The loader, or is there > an some OpenLibrary() incorporated in the programs' startup code? > ( The AmigaDOS manual says something about the linker fiddling > with the _LVO symbols, but it is not very clear. The manual also > assumes use of the Lattice linker, and I've got Manx. ) both are possible. lattice and manx open it in the runtime support code. if your executable exploits the object format's resident library feature, i think the dos loader will open it for you. > 2. If the loader is opening dos.library, I would expect it to > close it when the program terminates. As I read the manual, the > loader _will_ close dos.library. Is this behavior a loader bug? > Should I close dos.library myself? ( Can I even get the value of > DosBase if the loader opened it for me? ) if the loader opens it for you, you _don't_ get DosBase, so you can't close it. only the loader can, and in that case, should. > 3. Similarly, if the program's startup code is where dos.library > is really opened, why doesn't the termination code close it? > Again, should I close the library myself before I exit? the Astartup.asm i have handy does close dos.library; my manx _main.c doesn't. i think Lstartup does close. > 4. Does it really matter? Since the dos.library is almost as > fundimental as the exec.library, I don't expect it will drop to > an OpenCount of 0 and be unloaded. I assume it is a resident > library and part of the Kickstart memory. true. > The only drawback I > can see of not closing this library is that it is not possible to > move or replace a library as long as it is open. So, I can't > replace the dos.library with one of my own without altering the > kickstart disk or some non-dos code that executes right at > startup. well, you can steal the library's vectors piecemeal. dos does this to exec. a more complete replacement of dos would involve a new kickstart or boot disk. dos first gets opened by the small piece of code in the workbench's boot block. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
andy@cbmvax.UUCP (Andy Finkel) (07/17/87)
In article <172200078@uxc.cso.uiuc.edu> hamilton@uxc.cso.uiuc.edu writes: > >scott norton says: >> Hacking one evening with the AmigaMonitor, I noticed that the >> dos.library had an Open count over 10, where other libraries had >> 2 at most Opens. After calling up a few programs I noticed that >> this open count was never decremented. What is going on? ... Some of the standard 'exit' routines don't close the dos.library. So, it a program is compiled with one of those, and you use the program, your count will tend to increment. > > dos.library is "special". it doesn't follow all the conventions >other libraries are expected to honor. in particular, it doesn't >decrement its lib_OpenCnt upon close (the WB1.1 version, anyhow). Actually, it does decrement its use count on a Close. > >> 1. What really opens the dos.library? The loader, or is there >> an some OpenLibrary() incorporated in the programs' startup code? Most of the startup code opens the dos.library for you. (Which was a good thing, as many of our early examples used DosBase rather than DOSBase as the global). >> 4. Does it really matter? Since the dos.library is almost as >> fundimental as the exec.library, I don't expect it will drop to >> an OpenCount of 0 and be unloaded. I assume it is a resident >> library and part of the Kickstart memory. The current DOS library won't let itself get expunged in any case. (Even if it was in RAM rather that in Kickstart RAM) >> The only drawback I >> can see of not closing this library is that it is not possible to >> move or replace a library as long as it is open. So, I can't >> replace the dos.library with one of my own without altering the >> kickstart disk or some non-dos code that executes right at >> startup. Exec has the means to replace any of the libraries entirely, through the (underdocumented in a major way) RomTag facility. The replacement library can sit in RAM. andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "The goal of Computer Science is to build something that will last at least until we've finished building it." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.