Path: utzoo!attcan!uunet!wang!bu-tyng!three!cory From: cory@three.MV.COM (Cory Kempf) Newsgroups: comp.arch Subject: Re: Macintosh OS Message-ID: <369@three.MV.COM> Date: 13 Jun 90 03:03:51 GMT References: <8767@odin.corp.sgi.com> Organization: Three Letter Co. Nashua, NH. Lines: 72 jdarcy@encore.com (Mostly Useless) writes: >This brings me to my next point, which I would have let slide if I weren't >posting already. I've heard a lot from the Mac interface folks saying how >"the user is in control". However, long experience with the Mac has taught >me that the application can do pretty much what it damn well pleases. It >would take me all of two minutes to write a Mac program that will spin in >an infinite loop without calling GetNextEvent, forcing the user to reboot. >Hell, I'll save them the trouble; I can just as easily write a program that >immediately reboots the machine. But wait a moment to consider... why would a user buy such a broken program? And, assuming that the user has purchased the program (or otherwise acquired it), and has found out about this antisocialness, why would they continue to run it? Personally, I would send it back. Which brings up a point that *I* was going to let slide... I made a post suggesting that a well written *USER* oriented program would check for events frequently (btw, this is just as true for Unix/X as it is for MacOS). No sooner had the post cleared my modem then several people posted such fine examples of *USER* oriented programs as Ray Tracers and Compilers. Give me a break! The user interface to 90% of the compilers out there has not changed since the days of punch cards!!! Most would not notice the difference between running on a Mac and running (walking?) on one of the old IBM batch mode thingies. And I have yet to see a shrink wrapped ray trace program. A nice toy for academics, but a waste of disk space to the avarage user. And they do not have much of a UI either. There is no real qualitative improvement over: $JOB RAYTRCE $INPUT = FOO.RT $OUTPUT = CONSOLE Something else to consider: Preemptive Multitasking is a time slicing POLICY. it is not the only one. It does, however, have the distinction of being the easiest for an application programmer / compiler writer to deal with, as well as giving the best OVERALL average wait time in the general case. It is by no means the best policy in ALL cases. And one further thing: people who buy computers don't give a ****** about what hard work programmers have to do. They couldn't care less where the line is drawn between OS and Application. A well written set of cooperating tasks will run at least as fast as a set of preemptively scheduled tasks. On a GUI based system, they will run (as perceived by the user) better. The Current Application will complete actions for the user and then, while the user is thinking (i.e. the CPU is idle) do other things. Swapping at event time when there are no pending events is the best time for such things. There is no way that a purely preemptive MT system can always preemt at such times. > With the application >in such complete control, I don't see how anyone can say this gives more >power to the user. My only guess is that the people saying such things >have been fortunate enough to use well-behaved Mac applications and have >never lifted a finger in an effort to write one. Consider: the USER is PAYING for the PROGRAMMER to do things right. They are always free to find a programmer (company, actually) that does. > The OS turns around and basically yanks the >application's cord without so much as a please or thank you. "Sorry, bub. >Yer outta here." Thus can even the most ill-behaved applications be tamed. >If you ask me - which you didn't - this is the way to keep control in the >users' hands. It would seem that Apple (finally) agrees with you... In System 7, the user can press CMD-Option-ESC and terminate a task. +C -- Cory Kempf I do speak for the company (sometimes). Three Letter Company 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory