Path: utzoo!attcan!uunet!samsung!rex!ames!sun-barr!newstop!sun!amdahl!key!sjc
From: sjc@key.COM (Steve Correll)
Newsgroups: comp.arch
Subject: Re: Macintosh OS
Message-ID: <1943@key.COM>
Date: 8 Jun 90 01:46:45 GMT
References: <1990Jun6.222126.2888@midway.uchicago.edu>
Organization: Key Computer Labs, Fremont, CA
Lines: 41

> In article <:SY35CD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes...
>How about the fact that programmers may have better things to do with their
>time than warp code to fit into the windowing universe? I realise that on
>the mac 90% of the programs are 90% user-interface, but that's not always
>the best way to do things. A compiler, for example, really has no business
>calling GetNextEvent *ever*.

In article <1990Jun6.222126.2888@midway.uchicago.edu>, gft_robert@gsbacd.uchicago.edu writes:
> And if the user wants to interrupt the compilation mid-compile?  You'd better
> have some way of finding at least this out.  GetNextEvent (or WaitNextEvent)
> seems the proper way to do this to me.
> 
> You may indeed have to change some of your code to run properly on the Mac.
> Or put another way: you may have to change some of your code to put the user
> in complete control...

I think you both want to be able to interrupt a compilation; you differ on
whether to provide this service within the OS or within the application. Many
operating systems (Unix, for example) provide the service in a fashion that
requires no change to the user's code: in fact, when you port an application
to Unix, the user is in complete control unless you take steps to prevent it.

The Mac approach simplifies the OS. But consider porting a large, compute-bound
Fortran program. In any OS, you will have to understand and convert features
dependent on the operating system, such as subroutines which read single
keystrokes without requiring you to hit the return key. But you will often not
have to understand the inner workings of the program: you can move somebody
else's semiconductor simulator to your machine and use it to model a flip-flop
without becoming an expert on how to write semiconductor simulators.
Ironically, this is the "appliance" paradigm claimed for the Mac itself: you
shouldn't have to understand how to build a microwave oven to reheat pizza.

With the Mac, however, to make the application run in the background and share
cycles, you must understand the control flow of the program (which loops are
executed how often, and how that varies according to the input data you give
it) before you can decide where to insert the GetNextEvent calls. Sometimes
that's not easy.

This discussion should probably decamp from comp.arch.
-- 
...{sun,pyramid}!pacbell!key!sjc 				Steve Correll