Daniel_Roedding@fiction.ms.sub.org (03/02/91)
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: > Daniel_Roedding@fiction.ms.sub.org writes: > >I re-disassblemled (ouch!) the DeskTop's media change force routine. The > >DeskTop expects A0 to be zero after a GEMDOS call. Is this always true? > To my knowledge, certainly not. So then I'd say that it is really random whether the <Esc> function works or not. Or is it defined that Fopen() clears A0? If not, the desktop cer- tainly would crash!! (3 Bombs, I tried it by changing A0) Daniel
7103_2622@uwovax.uwo.ca (Eric Smith) (03/03/91)
In article <706256@fiction>, Daniel_Roedding@fiction.ms.sub.org writes: > csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes: >> Daniel_Roedding@fiction.ms.sub.org writes: >> >I re-disassblemled (ouch!) the DeskTop's media change force routine. The >> >DeskTop expects A0 to be zero after a GEMDOS call. Is this always true? >> To my knowledge, certainly not. > > So then I'd say that it is really random whether the <Esc> function works > or not. Or is it defined that Fopen() clears A0? If not, the desktop cer- > tainly would crash!! (3 Bombs, I tried it by changing A0) > In practice, all the trap #1 calls seem to leave A0 alone (i.e. its value on exit is the same as the value on entrance). However, since they are documented as potentially destroying A0-A2 and D1-D2, relying on this behaviour is *very* *very* bad and will break someday (as I've been told when I've done this :-). Since new versions of TOS will presumably include new versions of the desktop, I guess that is one application that can afford to ignore this caveat; it is rather strange that it does, though. -- Eric R. Smith email: Dept. of Mathematics eric.smith@uwo.ca University of Western Ontario 7103_2622@uwovax.bitnet