Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!claris!hearn
From: hearn@claris.com (Bob Hearn)
Newsgroups: comp.sys.apple
Subject: Re: GS switcher ideas
Message-ID: <9513@claris.com>
Date: 5 Apr 89 21:04:08 GMT
References: <9511@claris.com>
Organization: Claris Corporation, Mountain View CA
Lines: 25

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