🚀 go-pugleaf

Joseph Crowe <jcrowe> writes:

>nevin@CS.Arizona.EDU (Nevin ":-]" Liber) wrote:
>>Of course it is the issue.  Programming is a contract between the
>>programmer and the OS.  If the programmer breaks the rules, bad things
>>happen.  I have yet to use a system that has absolutely no rules at all.

>   Here you hit on the one essential issue that probably causes all of the
>conflict in the PMT vs. CMT debate.  Essentially, with PMT, the OS controls
>what the app can do, such that the writer of the app should not have the
>capability of "taking over the machine".  The issue may be a little deeper but

A PMT OS doesn't control what an app can do.  Even with a PMT OS a badly 
written program can still hog the OS (like many Amiga games do, or you 
can do with OS/2 just by calling one function), corrupt your hard drive,
crash your system etc. If a programmer doesn't know how to do a simple 
thing like call WNE to enable multitasking, they don't need to be using C 
they need to be using something simpler like HyperCard.


>   Yeah, but not all.  Think about this....you know all of those annoying
>alerts that essentially allow the user no alternative but to respond before
>doing anything else on the Mac?  Let's see, dialogue boxes in MacSpeak.  These
>are the indication that the underlying multitasking mechanism needs rework.  I

Why?  the other programs are still getting CPU time.  Not only that, most 
programs now are moving toward dialog boxes that let you move them to the 
background.  Even if the Mac was to get a real rime preemptive 
multitasking OS tommorrow, Apple couldn't just redefine what happens when 
the program calls routines to show a modal dialog box.

It's up to the programmer to take advantage of whats already there.  
Sloppy programming is sloppy programming.