Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.hardware
Subject: Re: SE/30 -> 32 bit clean ROMS?
Message-ID: <1990Oct25.183759.10653@eng.umd.edu>
Date: 25 Oct 90 18:37:59 GMT
References: <2899@bridge2.ESD.3Com.COM> <625@nrcvax.NRC.COM>
Sender: news@eng.umd.edu (The News System)
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 28

In article <625@nrcvax.NRC.COM> neg@nrcvax.UUCP (Neal Goldsmith) writes:
>In article <2899@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman Goodger) writes:
>>In article <1990Oct23.032953.16860@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes:
>
>It is my understanding (as told by an Apple Engineer at MacWorld) that the
>Macintosh OS Memory manager MUST load from the ROM.
>
>This is why there is both a 24-Bit and a 32-Bit memory manager in the ci and
>newer ROMS. A/UX has some other way of handling a 32-Bit memory manager for
>the multifinder session.
>
>I don't know why this is, just repeating what I was told by Apple. This is why
>I want a new set of ROMS. I would be happy with software however if it is
>possible.

Patching the memory manager 'on the fly' would be impossible-- you would end up
invalidating the structures in the system heap.  In order to install a
32-bit memory manager, Apple would probably have to put the new routines into
high memory (above BufPtr, and therefore outside of the memory manager's
control).  The patch routine would then have to essentially restart the system
(reloading the system heap and all).  It would be very difficult, but if Apple
doesn't want to do it, they ought to release new ROMS (and require return of
the old ones, just as is done with logic board replacements, FDHD and IIfx
upgrades, SE upgrades, etc)

--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
Tax the rich, and feed the poor -- until there are, rich no more.