Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!husc6!endor!siegel
From: siegel@endor.harvard.edu (Rich Siegel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Standard File and Desk Accessories
Message-ID: <2024@husc6.harvard.edu>
Date: 8 Jun 89 19:20:36 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>
Sender: news@husc6.harvard.edu
Reply-To: siegel@endor.UUCP (Rich Siegel)
Organization: Symantec/THINK Technologies, Bedford, MA
Lines: 63

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;
>	
>Why not? All applications should avoid writing into NULL location, so
>your data should be perfectly safe there (However, standard file dlogs
>used to dump 0x00FFFFFF into *NULL in older Sysytem versions)

	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.


>>	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.

>> [Two procedures in assembly]
>
>It seems to me that what Rich wrote is essentially equivalent to the following:
	[An incorrect translation of my assembler source into C].

	Taken literally, you're correct; the saved-away handle IS known
to more than one routine. However, the routines that DO know about the
handle are exactly two in number, and any other routine which wants the
handle must access it as an argument to a procedure.
	
	Furthermore, "true" global variables are accessed as offsets from
a globals base register, such as A5. The saved-away handle is not a global
in this sense, since it's accessed via PC-relative offsets, which means
that it's independent of the value of ANY base register, which provides
an easy and reliable to fetch and store the value. 

	Which was the problem in the first place: not that ANY globals
weren't allowed; the code just couldn't use "True" globals (ones that
would be addressed relative to a base register).

		--Rich





~~~~~~~~~~~~~~~
 Rich Siegel
 Staff Software Developer
 Symantec Corporation, Language Products Group
 Internet: siegel@endor.harvard.edu
 UUCP: ..harvard!endor!siegel

 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.

~~~~~~~~~~~~~~~