🚀 go-pugleaf

In article <CMM.0.88.621125609.larserio@kyrre.uio.no> larserio@IFI.UIO.NO (LarsErikOsterud) writes:
>Excuse me !!!
>BIOS, XBIOS and GEMDOS can be called from within themselves !!
>I do this in many of my TSR program (even call GEMDOS inside BIOS !!!!)
>
>  Lars-Erik   /   ABK-BBS +47 2132659   /   ____ ______
>   Osterud   /   larserio@ifi.uio.no   /   /___    /
>____________/  _______________________/   ____/   /

I'd suspect that your TSR has to do something special to do this, no?
You cannot just blindly make GEMDOS calls, while some foreground
program was in the middle of a GEMDOS call.

The standard GEMDOS has one, read one, basepage pointer to the
currently running process.  It resets the stack to a hardcoded address.
GEMDOS also has a lot of static (hardcoded) variables and structures.
This is *not* how you write re-entrant code.   Programs that don't
"know" they might be used re-entrantly cannot be expected to do the
things your TSR must do to save and restore the GEMDOS context.
While this could be done by some scheduler (probably something that
the GEM task switchers must do), it isn't just built into GEMDOS
(not that Atari ever claimed GEMDOS would do this).

GEMDOS keeps one process Pexec/Pterm parent/child linked list.  There
cannot be muiltiple parents without hacking.  You cannot run a program
that makes GEMDOS calls, suspend that program while in the middle of
a GEMDOS call, and run another program which makes a GEMDOS call,
and expect that the first program will still work, unless you know what
context information internal to GEMDOS must be saved and restored.

GEMDOS can be called re-entrantly *if* in my program I remember to save
all important GEMDOS data areas (including the stack), and put it back the
way it was when I'm done.  That's a lot different from saying GEMDOS
is re-entrant.
-- 
David Beckemeyer (david@bdt.UUCP)	| "I'll forgive you Dad...  If you have
Beckemeyer Development Tools		| a breath mint."
478 Santa Clara Ave. Oakland, CA 94610	|    Bart - "The Simpsons"
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|