Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Standard File and Desk Accessories
Message-ID: <13870@dartvax.Dartmouth.EDU>
Date: 9 Jun 89 22:30:48 GMT
References: <50967@tut.cis.ohio-state.edu> <7547@hoptoad.uucp> <4972@umd5.umd.edu> <51276@tut.cis.ohio-state.edu> <2015@husc6.harvard.edu> <1241@speedy.mcnc.org> <2024@husc6.harvard.edu> <13855@dartvax.Dartmouth.EDU> <7610@hoptoad.uucp>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 56

In article <7610@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <13855@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu
>(Earle R. Horton) writes:
	[This is in reference to using location zero as a scratch area.]
>>Aesthetically, however, it's a real bad
>>idea.  It produces the same problem that you get using ToolScratch,
>>ApplScratch, or any other lowmem location--conflicts with other pieces
>>of code.
>
>Unless, as I pointed out when I proposed it, you save the old state and
>restore it before anyone else gets a chance to use it.  If you save the
>value, call Standard File, extract the value stashed by your filter
>procs, and restore the old value, there's no way any code that would
>use the scratch storage will be interfered with.  Only system software,
>interrupt driven code, and trap patches would have a chance to see it,
>and it's clear that such software is not allowed to use the scratch
>areas.

  "Scratch20, Scratch8, and ToolScratch will not be preserved across
   calls to the routines in the Macintosh ROM.  ApplScratch will be
   preserved; it should be used only by application programs and not
   by desk accessories or other drivers."
                     Phonebook: Assembly Language Programming Chapter

     Standard File makes a whole bunch of ROM calls.  This means that
the three scratch areas dedicated to tool use cannot be used.  Saving
and restoring the value at location zero (an interrupt vector) will
not work across Standard File, because background tasks are allowed to
run while Standard File is active, and lots of tasks will have a
chance to see it.  (I'm assuming MultiFinder here.)

     It's not nice to use ApplScratch, even though you think it
extremely unlikely that the application will need it during the
Standard File call.  What if the call to Standard File causes the
application's grow zone function to be called, and the grow zone
function uses ApplScratch?  Grow zone functions are just an example;
my point is that it is possible for the code of the current
application to get control in the midst of a call to Standard File.

>Like storing the information in the refCon of the DA window, using
>ApplScratch or ToolScratch with a state save/restore seems to have been
>a useful and *easy* technique that was dismissed out of hand for some
>unknown reason.  It's stuff like this that makes me wonder why I put so
>much work into this newsgroup.  It's frustrating.

     ToolScratch is definitely out, given what IM says about its
volatility.  ApplScratch is out, too, because it is just barely
possible for the application code to need or modify it during the call
to Standard File.  Murphy's Law equates "just barely possible" with
"will happen," as I am sure you know already.  There are aesthetic
problems with the use of low memory globals for this sort of thing,
too.  Many people will just not use them if there is another method.

Earle R. Horton
"People forget how fast you did a job, but they remember how well you
did it."  Salada Tag Lines