maclab@reed.UUCP (Mac DLab) (08/20/87)
I have spent some time recently with sublaunching, and have
a few comments and a question which may be of interest to
other sublaunchers.
Option-Sublaunch
After using my sublaunch implementation for a couple of weeks, I noticed an
undocumented system "feature." Holding the option key down
during a sublaunch nullifies the sub-launch in the sense
that quitting the sublaunched application returns you to the Finder,
not the launcher. Holding the option key down while quitting
a sublaunched application also returns you to the Finder.
And, in fact, if you have several sublaunches stacked up and option-key
abort to the Finder, opening up another application from the desk-top
puts you back into the launch chain. I.e. when you quit the application
you clicked on from the finder, control returns to the last application
that did a sublaunch.
Although I can see some utility to this, it can really cause trouble for
applications that do sublaunches, especially when the developer
doesn't know about the option-key trick. If, for example, you leave
ERIK wdrefnums allocated (expecting them to still be good when your
sublaunch returns), you get screwed by the Finder since it dumps all
of the ERIK's.
I might also note the option-key trick is a drag when you are trying
to sublaunch applications that assign special meaning to being booted
with the option held down (e.g. Font/DA Mover).
I sent a letter to tech support asking why this "feature" was not
documented, and they gave me the uncharacteristically annoying reply that
(and I am paraphrasing here) 'we aren't documenting option-sublaunch
since we're not sure if we're going to leave it in the
next system.' !!?? I don't know about you, but this strikes me as a
rather dangerous attitude toward documentation in general.
Returning from a Sublaunch
When I return from a sublaunch, I want to know about it: my program
needs to set up the same environment that the user left at the
time of the sublaunch. If booted from the Finder, I obviously want
to just start up in a normal configuration.
My first thought was, "Well, how does MPW do it?" Unfortunately, the
answer is that MPW uses low-memory globals of some sort to store
information. Hey, I'm not that desperate!
Use a file or resource to save the information? That's no good, since if the
sublaunched application crashes, the next time my application is booted
from the Finder, the file will still be there and I will think I am
returning from a sublaunch.
It turns out that a nice solution is to save a system heap handle in a
resource each time you sublaunch (either in the application resfile,
or some other resfile that the application can always get to).
In the handle, you put a string (say, "sublaunch in progress"). Whenever
your application boots:
1) Get the handle from the resource.
2) Make sure it is non-zero (see step 6).
3) Make sure that it is a valid handle.
4) See if it points to the "sublaunch in progress" string.
5) If so, zero the string in the system heap, then dispose of the handle.
6) Put a Nil handle in your resource.
You can of course keep whatever sublaunch information you want in the
handle also (filenames, wdrefs or dirids, etc.) that can be used on
return from the sublaunch.
There is one catch -- what happens if you sublaunch yourself, or if
a sublauchee sublaunches you? Well, nothing bad happens. Your
application will start up thinking it has returned from a sublaunch,
with no harm done. However, when you return to the original launcher,
the handle will be cleared and it will think it has booted from the
finder.
Question:
What I would like to see is an infinite number of sublaunches
with proper return from each one -- I haven't figured out a bullet-proof
method for doing this yet. Tech Support is silent on the possibility of
examining whatever structure keeps track of the sublaunch history -- I'm
sure this could be discovered with a little bit of debugger work, but
would be a suicidal path in terms of being compatible with future systems.
Any suggestions?
Scott Gillespie
Reed College
{decvax, and a host of others}tetronix!reed!maclab