Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!sun-barr!decwrl!decvax!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: <13944@dartvax.Dartmouth.EDU>
Date: 15 Jun 89 20:29:05 GMT
References: <13855@dartvax.Dartmouth.EDU> <446@cbnewsk.ATT.COM>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 53

In article <446@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes:
>> In article <2024@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>>	This is not self-modifying code, because the location that's modified
>>is never executed. It's actually storing data in code space; this particular
>>trick WILL fail once an OS comes out that has separate code and data spaces,
>>but it's reasonably far off.
>
>From article <13855@dartvax.Dartmouth.EDU>, by earleh@eleazar.dartmouth.edu (Earle R. Horton):
>>      Aha!  So one of you A4-relative types admits that the trick will
>> fail someday!  This makes my day...
...
>Are you having fun, Earle?  Smugness ill-becomes you, unless you have
>a solution to the problem...if you do, please share it.

     I have been accused of condemning the use of A4-based code resource
globals, while providing no alternate solution of my own.  This was not
my intent.  I merely hoped to point out that for any problem, there usually
exist multiple solutions.  In the case of code resources which are not
provided with an external means of keeping global data around, the use
of A4-relative data is only one solution.  The technique, while seeming
to provide a universal solution to the globals problem, has the serious
drawback that it sometimes requires the programmer to write the A4 value
into a part of her code space.

     For many code resources, such as desk accessories and cdevs, there
already exist mechanisms for saving a Handle to data.  My point is that
where such a mechanism exists, it should be used in preference to writing
to code space.  For desk accessories, when it is necessary to reference
A4-based globals from within a routine where the DA's A4 is invalid, it
is preferable to use the driver's dCtlStorage Handle for this purpose,
rather than using Think's SetupA4().  For some applications it may be
possible, or even preferable, to forego globals entirely.

     Rewriting code to accomodate an OS change can be an expensive
proposition.  If you can find a way to avoid doing so, then you may save
yourself or someone else a lot of trouble in the future.  Although I
propose no universal solution to this problem, I do suggest that anyone
who is involved in writing code which writes to code space ("Class II
self-modifying code") make sure that this is the only solution which
is practical.

     If you detect a note of sarcasm in my characterization of
"A4-relative bozos," then it is there.  The reason is that from my
experience with Aztec, I find that the A4-relative method is presented
as a solution to the code resource globals problem, but that the
potential problems which exist are not discussed in the documentation.
I am not condemning the technique, because there appear to be cases
where it is perfectly safe.  It is the one percent or less where it is
not that worries me.  Code with a time bomb in it can blow up anytime.

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