Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!media-lab!adam
From: adam@media-lab.MEDIA.MIT.EDU (Adam Glass)
Newsgroups: comp.sys.mac.misc
Subject: Re: System Errors, MF --> Why???
Message-ID: <2545@media-lab.MEDIA.MIT.EDU>
Date: 28 May 90 16:22:10 GMT
References: <6364.266023a1@umiami.miami.edu> <16795@phoenix.Princeton.EDU>
Reply-To: adam@media-lab.media.mit.edu (Adam Glass)
Distribution: na
Organization: MIT Media Lab, Cambridge MA
Lines: 64

bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
> gross@umiami.miami.edu writes:
>> Apple is coming up with version 7 of their OS.  When are they
>> going to make it stable enough so that the least little problem
>> doesn't bring up those system error messages and crash your system.
>
> When they release it, of course.  You can't expect alpha software to
> go for long periods of time without running into problems; if it did,
> then it would be beta or release.

I doubt that's what he meant. I believe he was asking when they were
going to fix the problem with the OS, not the new release. And if you
really think that system errors are going to disappear entirely with
System 7, you're more than just a little bit naive.

> And as for the bad system bombs: if you use well-written software,
> then you shouldn't have problems with system errors.

That's a good defense. ("The bombs shouldn't be happening in the first
place.") Is MacWrite well-written software? It crashes with ATM and
Switch-A-Roo. I mean, you can't assume that all software will be
written perfectly. There are always going to be conflicts and rare
crashes. Saying that the problems shouldn't have occurred in the
first place is not a solution. The original poster was looking for a
way to recover from the *inevitable* crashes.

> What I *would* like to see is another button in the system error
> dialog box that would attempt to clean up the system heap and abort to
> the Finder.

Now that's a good idea. I've found that doing this with MacsBug works
more often under MF than it does without MF.

Is the RAM cache written out in the event of a crash? The program
should in some way be told that it's crashed so that it can do
something about it. Even in the case of fatal errors, the application
should be able to make a last-ditch effort to save any data that would
be lost.

> The way the Macintosh handles multiple processes (by letting the one
> in the foreground pretty much have as many cycles as it wants while
> other applications lie dormant) is fine for my uses.

That's great. Just because it's fine for you and you haven't had a
crash for a month and a half means that these are non-issues, right?

> It's different from Unix

No kidding. Unix is true multitasking.

> if I'm working in my draw program, why should the machine be paying
> any attention to that word processor and hypertext program over there?

It should be paying attention, but as word processors basically don't
have to do anything unless there's an event, practically speaking it
wouldn't be paying attention. And who says we're using multiple
programs? What if a game wants to start a process to play a theme? How
about a 3D program that could render a complex object (or scene) in
the background while you work on a program that doesn't need much CPU
power (like a word processor) in the foreground?

Adam
--
"Fathers and teachers, I ponder 'What is hell?'
 I maintain it is the suffering of being unable to love." - Dostoyevsky