lsr@apple.UUCP (05/11/87)
I just got a copy of the new batch of Tech Notes, and as promised, here is
the information contained therein about sublaunching. (It is Tech Note
#126.)
First, the Tech Support groups says that sublaunching should be left out of
applications for future compatibility reasons. The Tech Note begins with a
warning that the Launch trap will change "in the not-too-distant future,"
and that when that happens, "programs which launch other programs will
break."
System file version 4.1 or higher includes a sublaunching mechanism. The
patched _Launch trap will accept an extended parameter block of the form:
TYPE LaunchStruct = record
pfName: ^Str255;
param: Integer;
LC: Packed Array [0..1] of Char;
ExtBlockLen: Longint;
fFlags: Integer;
LaunchFlags: Longint;
end;
The _Launch trap takes a pointer to this structure in A0. The first 2
fields are documented in Inside Mac and were the one orginally used.
If the LC field contains the characters 'LC', then the trap assumes that the
extended parameters are present.
The fFlags field is the Finder's info flags, that you can get from a call
to the File Manager (PBGetCatInfo or PBGetFInfo); bit 6 of the low-order
byte should be 1 to get a read-only launch. (This corresponds to the
shared bit in the Finder's info flags.)
If bit 31 of LaunchFlags is 1, then a sublaunch is indicated.
Note that the extended parameter block was implemented in the 128K ROMs.
The 128K ROMs will respond to the read-only bit; the sublaunch bit is
implemented in a ROM patch in System 4.1.
Ignoring the issue of future compatibility, there is still another
unresolved issue. This involves the use of working directories.
_Launch expect to find the application on the current volume. Unless the
application is at the root of an HFS volume or on an MFS volume, you will
have to create a working directory that refers to the folder containing the
program.
If you get the name of the program by using Standard File, then Std File
will take care of allocating a working directory. You only have to call
SetVol, to make it the current volume.
If you don't use Std File to get the application name, then you will have
to call OpenWD youself to create a working directory. If you do this, you
should make the WDProcID 'ERIK' so that the working directory can be
deallocated by the Finder (or another shell), when it is not needed.
You might easily run out of working directories if you are writing a shell
program and do not manage them. (There is a limit of 40 simultaneous
working directories.) Also, if your shell sublaunches a program that in
turn sublaunches a program, etc. you could run out of working directories
sooner.
The ideal thing to do is for a shell program to make a list of all the
working directories with WDProcID 'ERIK' when it first starts running
(using indexed calls to GetWDInfo). When a sublaunched program returns, it
would again sequence thru all the working directories and throw away the
ones with WDProcID 'ERIK' that weren't on the original list. (If the
WDProcID is not 'ERIK' then it should be left alone.)
So that's the word on sublaunching. If you plan on implementing this, I
recommend that you get a copy ofthe actual Tech Note, just in case I made a
mistake typing this in.
--
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET