🚀 go-pugleaf

In article <313CA521.13D8@mediamatic.nl>,
Pascal Haakmat  <pascal@mediamatic.nl> wrote:
>Gregory L Hansen wrote:
>
>> Well... if the Blue Box crashes and is restarted, chances are the program
>> will receive a restart Blue Box event.
>
>Then the blue box would have to restart all the applications that were
>running at the 
>time the blue box crashed. While I certainly consider this a feasible
>sort of thing, 
>re-loading every application sure does kill the prospect of 'shorter
>startup times'.

I have no idea how Apple is going to do it.  But how would I do it?  If 
it alerts the program that the Blue Box was restarted, maybe you could 
keep a copy of the GUI in memory somewhere and stick it in the Blue Box?  
Or maybe put the startup and GUI in a seperate resource.  When it 
crashes, the program can reload (or the OS can load) the startup section 
with a pointer to the data if it's a restart and with a null pointer for 
a fresh start.  That way the data is easily found and you don't have to 
reload the whole friggin' thing.

But, like I said, I don't know how Apple is going to handle it.

>Hmmm. The program must check upon startup whether it has crashed and re-collect at 
>least some system state from various assorted places. I do not consider this a 
>trivial matter. Which makes me think about where the spawned threads are going to 
>store their results (in their own part of protected memory?) and how 'the UI engine' 
>is going to retrieve it. This would require some PPC toolbox mechanism I suppose? The 
>whole concept of 1 single program having to set up all sorts of communication 
>channels with other parts of ITSELF just does not appeal to me at all. It sounds like 
>consulting yourself on whether you want ice-cream or not.

If the program can detect the crash and restart the UI section, passing a 
pointer to the data, then the problem is easily solved.  It might work 
that way, since Copland is redoing the MacOS, and it doesn't have to 
restrict itself to System 7 standards.

But again, just as a disclaimer, I can only speculate.

Keeping track of the system state should not be a problem, either, since 
you have to do that anyway.  You have to keep track of which menus are 
highlighted and which are dimmed, which window you're in, where the 
windows are and how big they are, how the documents are positioned in 
them and where the cursor is.  It's like when you load a word processing 
document and it loads up just the way you left it, except you'll also 
have to keep track of which documents were loaded and which one was 
active.  It'll be a little extra work, you might have to be a little more 
careful.  But it sure isn't worth mentioning compared to something like 
developing the graphics engine of a game like Descent.  I think for any 
useful or entertaining program, the UI part will be the least of your 
worries.  Once you understand how to use it in the first place.