Path: utzoo!attcan!uunet!lll-winken!ames!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
Keywords: Globals in DAs, Party, Enough!
Message-ID: <13855@dartvax.Dartmouth.EDU>
Date: 9 Jun 89 00:24:22 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>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 65


     This looks like fun!  May I throw in my two cents worth?

In article <2024@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>In article <1241@speedy.mcnc.org> kk@mcnc.org.UUCP
	(Krzysztof Kozminski) writes:
>>BTW, an idea that I had at 3:15 am was to use the NULL location:
>>	*((Handle*) 0L) = HStorage;
...
>	Some Radius products do (or used to, at least) use location zero
>for their own purposes. On the memory map, location 0 is noted as being
>"part of the system heap", and is usually smashed by applications, whether
>they're supposed to or not.

     The 68000 reference I use says location zero holds the initial
supervisor stack pointer when the machine is first powered up.  This
makes it a theoretically safe location to use for temporary storage
from within a desk accessory.  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.

>>>	Define a 4-byte spot in your code where you can store a handle.
>>
>>Yeeechh.  A "spot in your code"? Tim Maroney also suggested writing into
>>the code space ... Is self-modifying code OK nowadays? Anyway, I have this
>>impression that a spot in memory, the address of which is known to more
>>than one routine, is called a global variable ...
>
>	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.

     Aha!  So one of you A4-relative types admits that the trick will
fail someday!  This makes my day.  If Apple is real careful about
compatibility of OS releases and the Toolbox, then much current
software will still be in operational condition when separate code and
data spaces are implemented.  It would be real sad for any software to
fail then, JUST BECAUSE it writes to its own code space.

     It's just not real nice to write computer software which has a
shorter lifetime than it could have, had you coded it differently.
Modifying code space to store variables or Handles to variables seems
to save a lot of work in writing code for desk accessories and other
code resources today, but is the work saved worth the inevitable
aggravation that users will experience if and when the OS makes that
technique invalid?  Will you be around to make sure the software you
have written gets re-coded properly at that time, and will you be able
to make sure that users receive upgrades in a timely manner?  Perhaps
not...

     Please think carefully before using any technique which can be
demonstrated to have a high probably of failure under a future
operating system, no matter how convenient it might be to use it
today.
...
> I classify myself as a real developer because my desk is hip-deep in
> assembly-language listings and I spend more than 50% of my time in TMON.

     84+ hours a week, wow!

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