Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!cert!netnews.upenn.edu!msuinfo!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.sys.mac.programmer Subject: Re: A use for protected mode after all Message-ID: Date: 3 Dec 90 17:30:24 GMT References: <1990Nov28.031713.14035@maverick.ksu.ksu.edu> <2382.2754d79e@waikato.ac.nz> <1990Nov29.025924.7662@maverick.ksu.ksu.edu> <1990Nov29.201754.10384@midway.uchicago.edu> Sender: news@msuinfo.cl.msu.edu Organization: UW-Madison CS department Lines: 61 In-Reply-To: francis@magrathea.uchicago.edu's message of Thu, 29 Nov 90 20:17:54 GMT In article <1990Nov29.201754.10384@midway.uchicago.edu> francis@magrathea.uchicago.edu (Francis Stracke) writes: >How are you going to get around it? Either the debugger is locked out >or it isn't. If the debugger's running as a separate application, it shouldn't be able to get at another application's address space, by default. There should be a trap which attaches the debugger to another application, or some mechanism like that. Low-level debuggers are special, of course. Since, as Rich pointed out, the machine state is unknown, they basically need to be able to get at everything and can't rely on using OS calls for much. >>Further, and more importantly, applications should not be able to write >>in OS memory space. > >The fact is, though, that there are Mac apps that *do*. Worse, >there are gazillions that depend on being able to *read* low RAM, >given that Apple describes low-memory globals in Inside Mac. There's an easy way to fix this for the most common cases. Trap all attempts to read and write to low memory, and emulate them. For the cases where the application is only affecting itself, this will work fine, and the performance hit is unlikely to be too bad if the most common cases are optimized. It's tougher for INITs, CDEVs, DRVRs, etc. which want to live in the operating system. I haven't had enough experience writing these or playing with the very low-level OS routines to know how hard it would be to let some of these live happily in the system. Most likely, the best solution would be to provide a supported interface for dumping code in (e.g. a way to do a SetTrapAddress that will function globally and a way to install a chunk of memory as shared). >>There is no excuse for not utilizing modern (and abundant!) memory >>protection hardware. >How about "most Macs don't have it"? Pluses, SEs, Classics, LCs, most IIs. Yup, real problem. Hopefully, though, this can be integrated into the VM stuff, which won't be around on the low-end machines anyway. I only have an SE, but I'd really like to see memory protection on a Mac II-series machine if I buy one, anyway. >Don't be so sure. Most people aren't going to be affected by (let >alone understand) preemptive multitasking & memory protection. Well...not affected much, maybe. There are some problems, though, that I run into, even when I'm not programming. * It's difficult to write file transfer programs so that they'll keep going while something else has control of the computer. I've had "Mirror" abort a file transfer because the remote end is unhappy with the computer stopping for 60 seconds. * If one of my applications has a bug (and there's plenty, even in "well-written" software), I'd like to be able to abort it without needing to reboot. I really hope that Apple gets this right. :-) Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+