Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!xylogics!merk!alliant!linus!think!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.sys.mac.system Subject: Re: Protected-mode snake oil Message-ID: <41588@think.Think.COM> Date: 16 Aug 90 00:09:16 GMT References: <8099@jarthur.Claremont.EDU> <1990Aug14.010751.20050@NCoast.ORG> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 34 In article <1990Aug14.010751.20050@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/KT) writes: >As quoted from <8099@jarthur.Claremont.EDU> by wilkins@jarthur.Claremont.EDU (Mark Wilkins): >| You're obviously missing the point. What he meant to point out is that in >| a protected-mode environment it is very difficult for a user process to >| directly patch operating system calls, and he is arguing that the capability >| makes the Macintosh a much more easily customizable system. >The point *he* was making is that all of this is done with USER-mode code and >therefore can't crash the system.... I think the Mac is currently more customizable, because it can be customized at any level the programmer is willing to deal with. Protected systems generally limit the places where customization may be applied. However, enabling memory protection doesn't mean that the system has to be fascist. There could be a system call that allows a user process to write anywhere in system memory. In this way, you don't prevent applications from customizing the system, they are simply forced to do it explicitly. This way, program bugs are unlikely to *accidentally* modify memory belonging to the kernel or other processes. The decision on whether to provide calls like this must be based on the intent of the memory protection. If it's just to keep applications from accidentally interfering with each other, this would work. On multiuser systems, however, memory protection is usually also intended to prevent malicious users from bothering other users, in which case such a system call is not usually a good idea (and then you start getting more complicated, by defining privilege levels and allowing some users to do it while preventing others). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar