4526P@NAVPGS.BITNET (LT Scott A. Norton, USN) (07/10/87)
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?
I looked at my programs. None of them open or close dos.library.
They rely on the AmigaDOS loader's automatic opening of
dos.library, and the AmigaDOS manual says that the loader will
also close the dos.library when the program terminates. (
Incidentally, the BCPL programs don't leave dos.library open.
I'm not sure if they open it at all. )
Here are my questions:
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. )
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? )
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?
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 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.
LT Scott A. Norton, USN
Naval Postgraduate School
Monterey, CA 93943-5018
4526P@NavPGS.BITNET
---
"George took the mouse and threw it across the pool to
the other side, among the brush. 'What do you want of a
dead mouse anyways?'
'I could pet it with my thumb while we walked along,'
said Lenny."
-John Steinbeck, "Of Mice and Men"
higgin@cbmvax.UUCP (Paul Higginbottom SALES) (07/14/87)
LT Scott A. Norton, USN writes:
$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 opened by the Manx startup code (_main()), but is not
closed in exit().
$Should I close dos.library myself? ( Can I even get the value of
$DosBase if the loader opened it for me? )
DOSBase is created and set in the startup code, so it would be a global
variable for you if you wanted it. Not a good idea to close it though
since the exit() code may need to do DOS functions after you've closed
it (can you say "boom boom"?).
$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.
No, but it's bad practice that it doesn't get closed.
Paul Higginbottom.scotty@l5comp.UUCP (Scott Turner) (07/17/87)
Having ripped apart alot of code I've noticed several things that cause the above "behavior": One cause is hidden setup code. Lattice is a perfect example here, the default C startup code automagically opens dos.library and assumes that a program will exit by returning from the jsr which the startup code uses to call it. However, if a programmer uses EXIT to terminate his/her program the program will NOT return to the startup code. And the code downstream of the startup code has no idea that the startup code opened dos.library! Ooops! That's one cause, another is legitimate. Take for example a "Hot Key" program like PopCLI. PopCLI uses the execute function in dos.library when Left-Amiga-Esc is pressed. Since it will be calling dos.library from time to time it MUST leave dos.library open. Some device drivers use global variables in dos.library for various reasons. Thus they must leave dos.library open as well. Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan Disclaimer? I own L5 Computing. Isn't that enough?
ford@crash.CTS.COM (Michael Ditto) (07/19/87)
In article <0274526P@NAVPGS> 4526P@NAVPGS.BITNET (LT Scott A. Norton, USN) writes: >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? There is a bug in the C runtime startoff routines that open dos.library and never close it. Most likely, you have a few programs that were compiled with Aztec C. The OpenCount will go up by one each time you run such a program. >1. What really opens the dos.library? The loader, or is there >an some OpenLibrary() incorporated in the programs' startup code? The latter. >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? ) > >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? As far as I know, the problem is only a bug with Aztec. I have mentioned it on BIX, I will make sure Manx knows about it. >4. Does it really matter? Probably not, since the only potential problem is that, after running 65,536 such programs, the count will wrap back to zero, at which time the library could theoretically be "unloaded." But since rom libraries do not seem ever to be unloaded, I don't think it will ever be a real problem. -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu