Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!bu-cs!dartvax!northstar.dartmouth.edu!earleh
From: earleh@northstar.dartmouth.edu (Earle Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Standard File and Desk Accessories
Keywords: Globals in DAs, Party, Enough!
Message-ID: <13858@dartvax.Dartmouth.EDU>
Date: 9 Jun 89 06:36:19 GMT
References: <13855@dartvax.Dartmouth.EDU> <2026@husc6.harvard.edu>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@northstar.dartmouth.edu (Earle Horton)
Organization: Project NORTHSTAR, Dartmouth College
Lines: 57

I had to hack the references line, because either my news reader or my
news poster had an "interp buffer overflow."  Sorry if this breaks
anyone's train of thought.

In article <2026@husc6.harvard.edu> siegel@endor.harvard.edu
	(Rich Siegel) writes
>In article <13855@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu
>	(Earle R. Horton) writes:
...
>>     It's just not real nice to write computer software which has a
>>shorter lifetime than it could have, had you coded it differently.
>
>	I challenge you to solve this problem for the PRESENT incarnation
>of the operating system, given the contstraints of not being allowed
>to use a base register, and not being allowed to use any low-memory
>system space.
>
>	For example, suppose you have an INIT and a cdev that need to
>share information with one another? How do you propose to have them
>communicate?

     Whoa!  I thought we were talking about desk accessories here!
Desk accessories have an officially sanctioned place where they are
allowed to store information.  This is the dCtlStorage field of the
Device Control Entry.  This field is accessible from anywhere in the
code of the 'DRVR' resource, even in a filterproc (I know how to find
it, anyway).  It is, therefore, not necessary to write to the driver's
code space in order to implement private storage for a desk accessory
or device driver.

     You are quite right in saying that there do exist applications
where writing to code space and low memory seems to be the only
solution presently available.  I don't believe that a Desk Accessory
or Device Driver is one of these.

...
>>     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.
>
>	And please think carefully for attacking proven techniques, without
>also providing a workable solution of your own.....

     There are existing working solutions for device drivers under the
present system, which do not write into the driver's code space.
(Device drivers include Desk Accessories.)  What I mean to say is that
the safe solution should be used for these, even though it is perhaps
more cumbersome than the A4-stashed-in-code method.  Desk Accessories
should not write to code space because they don't really have to, and
because the technique may cause them to break someday.  In regard to
INIT/cdev combinations, well you have to do what you have to do, and I
don't suppose I can argue with that.

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