Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!haven.umd.edu!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.hardware
Subject: Re: Connectix MODE32
Message-ID: <1991May28.190524.27231@eng.umd.edu>
Date: 28 May 91 19:05:24 GMT
References: <270790.2841D1A9@cmhgate.FIDONET.ORG>
Sender: news@eng.umd.edu (C-News)
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 23

In article <270790.2841D1A9@cmhgate.FIDONET.ORG> Adam.Frix@p18.f20.n226.z1.FIDONET.ORG (Adam Frix) writes:
>
>mike@odgate.odesta.com (Mike J. Kelly) writes:
>
>MJK> What worries me is how Connectix does it (and I haven't heard 
>MJK> anything but generalities here). My uniformed guess is that they 
>MJK> simply replace the dirty ROM code with RAM-based versions. That 
>MJK> makes me nervous because at least ROM-based code can't be overwritten 
>MJK> or destroyed. If this is in fact what Connectix is doing (and 
>MJK> I repeat: I don't really know), I believe having key system routines 
>MJK> in unprotected RAM would make the Mac even more of an unstable 
>MJK> development platform than it already is. 
>
>Does anyone here know how A/UX handles the problem?

The A/UX memory manager IS in RAM. however, it is certainly POSSIBLE,
under BOTH A/UX and system 7 (at least in virtual memory mode) to
write-protect an area of RAM (I do not know if A/UX does so).  In any case,
a large part of the Mac OS is already (patched) in RAM.  

--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
     .sig under construction, like the rest of this campus.