Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!usc!snorkelwacker.mit.edu!hsdndev!husc6!endor!siegel
From: siegel@endor.uucp (Rich Siegel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: A use for protected mode after all
Message-ID: <4857@husc6.harvard.edu>
Date: 30 Nov 90 00:39:46 GMT
References: <2371.27539d74@waikato.ac.nz> <1990Nov28.000542.21632@verity.com> <1990Nov28.031713.14035@maverick.ksu.ksu.edu> <2382.2754d79e@waikato.ac.nz> <1990Nov29.025924.7662@maverick.ksu.ksu.edu>
Sender: news@husc6.harvard.edu
Reply-To: siegel@endor.UUCP (Rich Siegel)
Organization: Symantec Language Products Group
Lines: 43

In article <1990Nov29.025924.7662@maverick.ksu.ksu.edu> jxf@castor.cis.ksu.edu (Jerry Frain) writes:

>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).

	I disagree. A debugger is definitely not "an application like
any other". A machine-level debugger functions at a level where the state
of the system is unknown - it may be suspended, crashed, or simply in
some transitional state - and no system services (event and screen management,
for example) may be accessible. Furthermore, a machine-level debugger has
to be MUCH more aware of the system context (e.g. memory addressing spaces,
virtual address mapping, register states) than any "normal" application.

>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).

	If a debugger can't modify other memory spaces, then its usefulness
as a tool is severely limited - a debugger will typically need to set break-
points, and edit memory, as part of the development cycle.

(The average computer user doesn't know a debugger from Shinola, and typically
doesn't use one in his day-to-day use of the machine.)

Memory protection on the Mac is a tricky problem, because the OS, Toolbox,
and application code are so tightly coupled, and applications often have
legitimate reasons to access OS space. That doesn't make it impossible,
though. I agree in principle with the need, but for all practical purposes,
I believe that software that doesn't crash in the first place is the best
way to go - whether it stomps on other parts of the system or not, a
crash interferes with the user's ability to get work done, and therefore
it is a good thing to avoid.

R.

 Rich Siegel	Symantec Languages Group  Internet: siegel@endor.harvard.edu

"...she's dressed in yellow, she says 'Hello, come sit next to me, you
fine fellow..."