Xref: utzoo comp.sys.mac.programmer:6268 comp.sys.mac:31887 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!polya!shap From: shap@polya.Stanford.EDU (Jonathan S. Shapiro) Newsgroups: comp.sys.mac.programmer,comp.sys.mac Subject: Re: System 7.0 Q & A Message-ID: <9171@polya.Stanford.EDU> Date: 14 May 89 00:34:54 GMT References: <30353@apple.Apple.COM> <4666@okstate.UUCP> <1787@internal.Apple.COM> <7266@hoptoad.uucp> Sender: Jonathan S. Shapiro Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro) Followup-To: comp.sys.mac.programmer Organization: Stanford University Lines: 24 In article <7266@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Since low-memory globals are not >being eliminated and the system heap is not being made read-only to >applications, then one program can still crash either the OS software >or other applications. Double plus ungood. I'd prefer that Apple just >go ahead and break the programs that ignore the guidelines on low >memory and the system heap, rather than leave us all floundering about >having to reboot the system constantly during early development. > >Oh well, I thought I was going to have to wait for 8.0 for this anyway.... >-- >Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim Actually, the right thing to do here is have the relevant places start out as read only, and have them become read/write when it is necessary, such as the first time page 0 is written (for a few select pages) and have things like inserting trap handlers cause traps and run in priviledged mode so they can replicate the handler pages apropriately. It shouldn't be hard to make all of this relatively transparent to high-level languages. The problem would be with assembly code, which has traditionallya ssumed the right to touch anything. Jon