🚀 go-pugleaf

In article <20320@uflorida.cis.ufl.EDU> mfi@beach.cis.ufl.edu (Mark Interrante) writes:
>In article <492@iisat.UUCP> mackay@iisat.UUCP (Daniel MacKay) writes:
>>> 
>>> In article <17148@usc.edu> papa@pollux.usc.edu (Marco Papa) writes:
>>> >
>>> > [stuff about System 7.0 multitasking]
>>> >
>>
>> - a soft power switch that suspends all Multifinder processes and brings them
>>   all back up when you power back up the next day, exactly as you left 
>>   them.
>
>I like this is idea.  Since VM is part of 7.0, it seems very easy to leave
>disk based memory alone during shutdown so that your applications are still
>active next time you restart the machine.  If there is a reason to close all
>files then it is still reasonable to leave the aaplications turned on (save
>time), in fact since the live cut/paste turns on applications often why not
>leave them active?  Boot time for applications is a nontrivial amount of time
>this would save lots of time.

One problem with this, and perhaps the reason why a "soft power" feature
isn't being implemented with System 7.0, or perhaps under the Virtual VM
system from Connectix, is that there are too many things going on within the
computer's memory at any given moment that CAN'T be "frozen" (or stored) and
then restored indiscriminately into the system memory.  You wouldn't be able
to expect it to "hit the ground running," as it were.

Maybe if you restored the entire memory exactly as it was at some instant
in the past, the system might be able to handle it.  The internal clock
would be slapped in the face and would quickly need to reassert the NEW
correct time (the way it does when the user changes the time while running
several programs under MultiFinder already).  Any inits that had installed
themselves in the system before you restored memory as a block would be
wiped out; many of them wouldn't go cleanly, I suspect.  The inits that HAD
been installed when your memory chunk was recorded would be reinstated in
the vertical-trace loop... and many of them might not handle THAT well, 
since some of them depend on disk files that may well have changed since
the memory was recorded.  For that matter, what if the init's file is gone?
Heck, for that matter, what if an APPLICATION file is gone?  Should all of
your applications check every n ticks to see whether they still exist, and
if they don't, quietly say "Later, dude" and attempt to quit gracefully? :-)

Basically, for something like this to work, it would depend on there being
NO changes to your system between shut-down and re-injection of that block
of memory.  That would include remote volumes like file servers, though,
and you just can't count on those remaining static for you.

The whole idea sounds pretty dangerous, and while it would be nice, I just
don't see it happening workably in the near future on today's multiprocess,
multimedia, networked Macintosh.

Please feel free to prove me wrong!  I'd love to hear some ideas about
solving these problems.


-- 
Mark H. Anbinder                                ** MHA@TCGould.tn.cornell.edu
NG33 MVR Hall, Media Services Dept.             ** THCY@CRNLVAX5.BITNET
Cornell University      H: (607) 257-7587 ********
Ithaca, NY 14853        W: (607) 255-1566 ******* "It's not safe out here." Q