Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!emory!gatech!rutgers!maverick.ksu.ksu.edu!castor!jxf
From: jxf@castor.cis.ksu.edu (Jerry Frain)
Newsgroups: comp.sys.mac.programmer
Subject: Re: A use for protected mode after all
Message-ID: <1990Nov29.025924.7662@maverick.ksu.ksu.edu>
Date: 29 Nov 90 02:59:24 GMT
References: <2371.27539d74@waikato.ac.nz> <1990Nov28.000542.21632@verity.com> <1990Nov28.031713.14035@maverick.ksu.ksu.edu> <2382.2754d79e@waikato.ac.nz>
Sender: news@maverick.ksu.ksu.edu (The News Guru)
Organization: Kansas State University
Lines: 53

ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

>Excuse my previous cryptic comment, let's try again.

>In <1990Nov28.031713.14035@maverick.ksu.ksu.edu>, jxf@castor.cis.ksu.edu
>(Jerry Frain) says,

>"A debugger is just an application, after all, whose data
>space is no more important (even less important, in most cases)
>than the space claimed by other applications."

>What do you mean by "just an application"?

I am not sure what you are asking here.  The debugger is an application
like any other, I hope you agree.  Quite often, ensuring the integrity
of the debugger is not as important as protecting the data of other
programs running on the system (e.g. - the OS).

>                                            Are you perhaps implying
>that the OS (and other applications) may need protection from the debugger?

Yes!  All applications, your precious debugger included, should not be
able modify the memory space of *other* programs.  You will note that
this should not encompass the development-time debugging involved in
creating programs (but, I am unfamiliar with the way that Mac debuggers
are implemented).

Further, and more importantly, applications should not be able to write
in OS memory space.

In a generic sense, there exist circumstances where it is necessary to
use a debugger to read/write to kernel memory (take it from someone who
is not a stranger to using adb on a running Unix kernel), however I am
not sure that this is ever necessary in the case of MacOS.

There is no excuse for not utilizing modern (and abundant!) memory
protection hardware.

Simple, basic, controls for protecting system integrity.  That's not too
much to ask now, is it?  IBM will soon make OS/2 their standard.
Preemptive multitasking, memory protection, etc.  With the advent of
window systems that rival the Finder, coupled with the power of a
command shell, Apple will be left out in the cold if it does not pick
up on these very important concepts, soon.

But I digress...

--
Jerry Frain -- Systems Programmer               Kansas State University
                                        Department of Computing & Info Sciences
Internet : jxf@cis.ksu.edu                         Manhattan, Kansas
UUCP     : ...!rutgers!ksuvax1!jxf