Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Open Files at AC_CLOSE
Keywords: DeskAccessory, File, AC_CLOSE
Message-ID: <1583@atari.UUCP>
Date: 23 Jun 89 20:27:27 GMT
References: <1158@gmdzi.UUCP> <1574@atari.UUCP> <599@bdt.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 25

In article <599@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes:
> There are a lot of other potential "GEMDOS state" related things
> to consider, like changing directories or wiping out the Fsfirst()
> (DTA) buffer.  This could really screw up the "real" GEMDOS process
> if the ACC doesn't restore things.
> 
> Do I hear you saying "Nah, that probably won't ever happen?"

No, you heard someone say, "If you change something, change it back
before you let the mainline program run!"

The current directory and DTA address can both be saved, changed, and
restored before making any AES call (AES can only change tasks during
AES calls).  And in the serial-to-disk application I was talking about,
you should allocate the memory at accessory-start time, and do the
open-write-close when you need to, without giving the mainline a chance
to terminate during this procedure.  By allocating your buffer at the
start of the world (mainly, when the Desktop is the current process,
because the Desktop never terminates) you know there'll be enough.  Yes,
there might not be any handles available when you want one, but that
*is* unlikely. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt