Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!ucbvax!UIAMVS.BITNET!AWCTTYPA
From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons")
Newsgroups: comp.sys.apple
Subject: GS Switcher ideas
Message-ID: <8904052024.aa25892@SMOKE.BRL.MIL>
Date: 6 Apr 89 01:22:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 62

>Date:         Wed, 5 Apr 89 12:47:59 GMT
>From:         "David Wood (CS472226"
>              <haven!umbc3!umbc5.umbc.edu!cs472226@AMES.ARC.NASA.GOV>
>Subject:      Re: Multitasking, IIgs etc
>
>[...] Do you HAVE to close the NDAs before swapping direct page
>information? If the NDA is an entity in and of itself, you don't
>really have to worry about losing information to a DPswap, and I
>don't know of many NDAs that save information on an application's
>direct page.

The application's direct page is not the problem (a DA would have a
very hard time finding the application's direct page even if it
wanted to).

The direct pages being hypothetically fiddled with are really the
WAPs (work area pointers) for the toolsets.

The problem is that an NDA is exactly ONE entity in and of itself, so
it can't be open in two separate environments at the same time. A
typical NDA keeps a pointer to its own window somewhere in its global
variables (no way to write a program to determine where).  That
window will be part of a window list for the current environment.
When you change the window manager's direct page to switch to a new
environment, you've switched to a new window list where some open
NDAs may have pointers to things that are no longer valid windows.
That would be messy.

My solution is to unlink the windows from the current window list
and then re-link them into the new window list.  (But WHERE do you
put them in the new list?  At the front?  The back?  The middle?  As
close as possible to where they were in the old list?  Don't ask
hard questions.)

There would be other details, like what to do when the new
environment doesn't support NDAs (might actually have to close the
suckers in that case...they could have installed heartbeat interrupt
tasks that call toolsets that are required to be available for NDAs,
but which are not started in the new environment...ick).

And the Apple menu should be rebuilt in case more NDAs have been
added since the last time that environment was active (this probably
means the switcher needs to remember the ID that was fed to
FixAppleMenu for each environment, but there are alternatives, I
think).

>On another point, we're assuming that the applications that we start
>under this theoretical multiple personality environment will follow
>Apple's guidelines for tool use, memory requesting and allocation,
>etc. [...]

Allowing for future enhancements (like Switcher, MultiFinder, or
things nobody's thought of yet) are exactly why there _are_
guidelines.  COMPLAIN when developers don't follow them. (Unfortun-
ately, it's not usually easy to see which applications break the
rules until you actually try to enhance the system...then you see
which applications break.)

 --David A. Lyons              bitnet: awcttypa@uiamvs
   DAL Systems                 CompuServe:  72177,3233
   P.O. Box 287                GEnie mail:    D.LYONS2
   North Liberty, IA 52317     AppleLinkPE: Dave Lyons