Path: utzoo!attcan!uunet!cs.utexas.edu!usc!elroy.jpl.nasa.gov!jarthur!nntp-server.caltech.edu!tybalt.caltech.edu!toddpw
From: toddpw@tybalt.caltech.edu (Todd P. Whitesel)
Newsgroups: comp.sys.apple2
Subject: Re: Argh! That blasted StartUpTools()!
Message-ID: <1990Jul7.044559.4967@laguna.ccsf.caltech.edu>
Date: 7 Jul 90 04:45:59 GMT
References: <9005291535.AA26340@apple.com> <42396@apple.Apple.COM> <1417@madnix.UUCP> <42637@apple.Apple.COM>
Sender: news@laguna.ccsf.caltech.edu
Organization: California Institute of Technology
Lines: 69

dlyons@Apple.COM (David A. Lyons) writes:

[ in reply to ]
>>Has engineering given much/any thought to adding something to the
>>Desk Mgr to coordinate the way that NDA's use tools? It seems that NDA & tool
>>interaction is a source of a major amount of confusion, and, as such, a cause
>>of problems.

>I believe this is an area where your input would be helpful.  I am
>interested in making it easier to use tools from NDAs, but I don't have
>all the answers.

I came up with a simple solution to this problem because I am working on a set
of graphics tools and I want them to be able to run in the desktop environment
without any of these silly problems. The Tool interface in the GS does not
exploit the power of the UserID system enough, and the UserID system allows
us to solve this resource arbitration problem by rewriting certain tools. There
are kludge ways to do what I am about to propose, but the tools for which it
will hurt badly need replacement anyway... In my view, system software
integrity and robustness is more important than backwards compatibility,
especially now when the only serious developers left are dedicated enough to
happily revise their software in order to make everyone's life easier.

I know that Apple has always been a stickler for backwards compaitibility, but
their are times when you have to make a choice between two worthy goals, and
the future of the machine is ALWAYS more important than its past. (The recent
extensions to ProDOS -- lowercase filenames and dual-forked files -- were
implemented in a manner which insults the original designers of ProDOS. ProDOS
directories allow you to specify the length of a directory entry and a version
number which would have allowed for an orderly addition of case and resource
fork information. I would love to hear why this was not done.)

Multi-Client tool usage procedure:
	Call tool Status. If it is inactive, you load it or restore it from a
purged state (If possible. Does the standard tool startup procedure do this for
you already?)
	Start up the tool and hand it a derived UserID. Any blocks allocated by
the tool set for your program will carry this ID. You may start it up again
with a new ID if you wish (one ID per open document, perhaps); so may an NDA or
CDA. The Tool will keep track of every ID it has been started up with, but will
not accept a MasterID as a startup argument. If you use the ID for other data,
be careful (see shutdown, below).
	Use the tool for whatever evil purposes. Mine initially will be GIF
decoding, palette crunching, and fill mode animation experiments.
	When you are finished using the tool, Shut it down with the ID you gave
it in the startup call. If you hand it a MasterID then the tool will treat it
intelligently, i.e. all derivatives of that ID which have been used to start
the tools will be shut down. Shutdown MAY call DisposeAll so don't allocate
anything else with an ID passed to the tools unless you are ready to accept the
consequences.
	Check the tool's status. If it is no longer active then you should
unload the tool or mark it purgeable or something. If the Tool Locator doesn't
already do this then I would like to mark the tool purgeable and leave
a Message telling where to find it if it hasn't been purged, but I don't know
of any way to get a Message Type (other than calling DTS).

Can anybody blow holes in this? All programs must follow the same algorithm
for it to work, and now that I think about it the Tool Locator probably does
the load/unload stuff for you, and the only change I am suggesting to the
normal tool procedure is in the Tool itself -- the Tool does not actually shut
down until all its users have shut down.

Matt/Dave: what's the official word on Tool management? Can an application
explicitly dispose of a Tool or force it to be reloaded from disk even if it
is active or restartable? I sincerely hope not, because it endangers this
scheme and puts serious dampers on any hope for a multitasking yet robust GS.

Todd Whitesel
toddpw @ tybalt.caltech.edu