AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (04/05/89)
>Date: Tue, 4 Apr 89 19:34:25 GMT >From: Scott Lindsey <claris!wombat@APPLE.COM> >Subject: Multitasking, IIgs etc > >[...] All switching would go through GetNextEvent (since the GS >doesn't have WaitNextEvent, it's not quite possible to do Multifinder >the way the Mac does). Hey, the Mac didn't used to have a WaitNextEvent, either. MultiFinder works okay (less efficiently) with applications that don't know about WaitNextEvent. >The only things that would have to be switcher aware (read: patched >by the switcher) are the Event Manager, the tool Locator, any >FooStartup, FooShutdown where Foo is a tool used by one of the >applications and the memory manager. Finally, NDA's would have to be >treated specially. Hmmm...I don't agree with your list of things that a Switcher would need to patch. The memory manager shouldn't need any special handling. Sound tools status would have to be preserved, including the contents and status of the DOC RAM. Status of toolsets with no direct pages needs special handling: text tools comes to mind. Ditto for serial port firmware(?). Clipboard (scrap manager) contents would need to be transferred from application to application, including for applications that don't normally keep their clipboard contents in the scrap manager (ya gotta trick 'em into thinking an NDA has been opened so they'll put it on the system scrap for you). Then there are fun tricks to play with $E0 and $E1 vectors that are affected by QD, QD Aux, Event Manager (some of which may not be started in some of the switched applications). By playing with the window lists, you should be able to move the NDAs to the new application's environment. I think. >Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air >Claris Corp. | About an age of power when no one had an hour to spare" >ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, >wombat@claris.com | StyleWare, the author, or anyone else living or dead. --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
wombat@claris.com (Scott Lindsey) (04/06/89)
From article <8904050109.aa01772@SMOKE.BRL.MIL>, by AWCTTYPA@UIAMVS.BITNET ("David A. Lyons"):
> Hmmm...I don't agree with your list of things that a Switcher would
> need to patch. The memory manager shouldn't need any special
> handling. Sound tools status would have to be preserved, including
> the contents and status of the DOC RAM. Status of toolsets with no
> direct pages needs special handling: text tools comes to mind.
> Ditto for serial port firmware(?).
Yeah. The reason I said Memory manager is that who owns what & how
much is allocated of bank 0 will vary from application to application
as you swap them in and out. You either have to make the memory manager
somewhat aware of switching or monkey with the memory data structures
yourself.
>
> Clipboard (scrap manager) contents would need to be transferred from
> application to application, including for applications that don't
> normally keep their clipboard contents in the scrap manager (ya gotta
> trick 'em into thinking an NDA has been opened so they'll put it on
> the system scrap for you).
>
> Then there are fun tricks to play with $E0 and $E1 vectors that are
> affected by QD, QD Aux, Event Manager (some of which may not be
> started in some of the switched applications).
There's all kind of fun things along these lines... I was (for the time
being) just working with the assumption of friendly, lets-run-under-
the-desktop-metaphor-with-the-event-manager type applications.
I think you can get loads more special cases on the GS than on the Mac.
>
> By playing with the window lists, you should be able to move the
> NDAs to the new application's environment. I think.
Maybe. I was assuming total isolation of the applications. Each would
have a "copy" of the state of the tools it used. I guess if you simply
take a window pointer and put it into the other application's WindowMgr
window list it might work...
--
Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air
Claris Corp. | About an age of power when no one had an hour to spare"
ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple,
wombat@claris.com | StyleWare, the author, or anyone else living or dead.hearn@claris.com (Bob Hearn) (04/06/89)
From article <9511@claris.com>, by wombat@claris.com (Scott Lindsey): > From article <8904050109.aa01772@SMOKE.BRL.MIL>, by AWCTTYPA@UIAMVS.BITNET ("David A. Lyons"): >> Hmmm...I don't agree with your list of things that a Switcher would >> need to patch. The memory manager shouldn't need any special >> handling. Sound tools status would have to be preserved, including >> the contents and status of the DOC RAM. Status of toolsets with no >> direct pages needs special handling: text tools comes to mind. >> Ditto for serial port firmware(?). > Yeah. The reason I said Memory manager is that who owns what & how > much is allocated of bank 0 will vary from application to application > as you swap them in and out. You either have to make the memory manager > somewhat aware of switching or monkey with the memory data structures > yourself. Or use memory manager calls to move bank 0 in & out during the swap, handle by handle. This is a lot slower than just doing a blockmove, though... but probably a lot easier than patching the memory manager or playing with its data structures. And much safer. Probably the thing to do is use the mem. mgr. to allocate and deallocate the handles in bank 0 / swap space, then blockmove the image instead of doing a bunch of HandToHands. You won't take too many speed hits from the mem. mgr. doing this; it's fast for fixed address allocation. Bob Hearn hearn@claris.com
AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (04/06/89)
>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
shawn@pnet51.cts.com (Shawn Stanley) (04/09/89)
hearn@claris.com (Bob Hearn) writes: >Or use memory manager calls to move bank 0 in & out during the swap, handle >by handle. This is a lot slower than just doing a blockmove, though... >but probably a lot easier than patching the memory manager or playing >with its data structures. And much safer. Probably the thing to do is >use the mem. mgr. to allocate and deallocate the handles in bank 0 / swap >space, then blockmove the image instead of doing a bunch of HandToHands. >You won't take too many speed hits from the mem. mgr. doing this; it's fast >for fixed address allocation. The only problem I can see in this is possible fragmentation... UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com