🚀 go-pugleaf

In article <4066@utai.UUCP> dudek@ai.UUCP (Gregory Dudek) writes:
>
>    How do you determine if a trap is implemented?  You mean check the
>system version? Regardless of whether the traps are there, I need to
>know if MF is running since under MF, I may get very special behavior 
>(concurrent execution) which I want/need to handle specially (see below).

Toolbox trap number $9F is unimplemented on all machines.  You do a
GetTrapAddress on the trap in question and see if the address is the same as
the uninmplemented trap.

The Multifinder Tech Note is out now (#158).  WaitNextEvent is Toolbox trap
number $60.  Multifinder also has a generic dispatch trap (Toolbox $8F).  

Testing to see if WaitNextEvent is implemented is not the same as testing
whether Multifinder is running.  (Future systems may include WaitNextEvent
w/o Multifinder.)

The Tech Note gives the example oftesting for Multifinder temporary memory
calls.  First you test if Switcher is not active (the long word at location
$282 is -1 or 0); then you test if the Multifinder trap exists.  I assume
that this same test would tell you if Multifinder exists or not.

>    Are you sure about that?  This sounds like it would be tricky since
>in the "normal" (old) environment, a launch, even a sublaunch, causes
>the program to exit.  If sublaunching under MF  *DOES NOT* cause the program
>to exit (i.e. the launch returns), programs for the "old" environment
>may bust since they don't expect to execute the code following the
>Launch trap.

The sublaunching Tech Note does mention that the Launch trap might return in
the future, so I believe that what I said before is true.  (It also warns
that applications that call Launch could be broken in the near future.)

>    The reason I would like to be able to detect *IF* MF running is so
>that I know how to resume next time I get control.  If I can "fork" off
>a new concurrent process, I don't have to save the state information I
>would need with an old-style sublaunch.

MPW Shell does this also.  If Multifinder is around, it does not run its
suspend script, since the Shell will not be terminated.  I don't know how it
tests for this case, however.

>    Re. hypercard: if the task exit abnormally (for example a DA is nasty
>enough to call ExitToShell directly) HC does not remove it's trap patches.
>As a well-behaved application, shouldn't HC use that ExitToShell hook that
>allows it to be notified on exit & clean up after itself?

I think this is a bug, although one could argue that ExitToShell should not
normally be called except under application control.  (A DA that does so is
definitely unfriendly, and the next most likely way this could happen is
from a debugger.)

Using the IAZNotify global is problematical (see Tech Note #64).  At the
time it has been called, your program's global variables might have been
wiped out, and the application's resource file has been closed, so you have
to make sure that only resident code does the cleanup.  In MacApp, we
cleaned up after ourselves by patching the ExitToShell trap itself and doing
the cleanup there.  This solves the problem except for Macsbug's EA command,
which does a Launch instead of an ExitToShell.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com