cs421317@umbc5.umbc.edu (cs421317) (05/22/91)
I spoke to a techrep at Connectix today (05/21). He said that MODE32 is designed to be a 'drop in the System Folder' fix for dirty ROMs and that it will allow full 32 bit addressing and everything else we have wanted from Apple. He said that the product, due to be shipped on May 30th, is supposed to make the SE/30, IIcx, IIx and II fully 32 bit clean. He also said that MacWarehouse is taking orders now for $99. It'd be nice if we had a hardware solution, but at least this may be a solution. I still agree with every argument that has gone down the pike about this problem, but this may be the best we get. Will this always work? Who knows? Is it a slower solution? Maybe. Why should we pay for this fix? I wish we didn't have to, but it seems to me there have been lots of inits that were designed to fix problems, like HeapTool. Just now they're making us pay to fix them. (heavy sigh of frustration) - Gary Goldberg Census Bureau/DIR/SIRS AOL:OgGreeb cs421317@umbc5.umbc.edu - but not for long :(
mike@odgate.odesta.com (Mike J. Kelly) (05/24/91)
In article <1991May21.215839.20198@umbc3.umbc.edu> cs421317@umbc5.umbc.edu (cs421317) writes: >I spoke to a techrep at Connectix today (05/21). He said that MODE32 is >designed to be a 'drop in the System Folder' fix for dirty ROMs and that it >will allow full 32 bit addressing and everything else we have wanted from >Apple. > >It'd be nice if we had a hardware solution, but at least this may be a >solution. I still agree with every argument that has gone down the pike about >this problem, but this may be the best we get. Will this always work? Who >knows? Is it a slower solution? Maybe. Why should we pay for this fix? I >wish we didn't have to, but it seems to me there have been lots of inits >that were designed to fix problems, like HeapTool. Just now they're making us >pay to fix them. I don't mind paying (new ROMS won't be free). What worries me is how Connectix does it (and I haven't heard anything but generalities here). My uniformed guess is that they simply replace the dirty ROM code with RAM-based versions. That makes me nervous because at least ROM-based code can't be overwritten or destroyed. If this is in fact what Connectix is doing (and I repeat: I don't really know), I believe having key system routines in unprotected RAM would make the Mac even more of an unstable development platform than it already is. -- -- Mike Kelly Odesta Corporation, Northbrook, Illinois, USA ...!clout!odgate!mike - Until odesta.com is registered. odgate!mike@clout.uucp - From the Internet.
Adam.Frix@p18.f20.n226.z1.FIDONET.ORG (Adam Frix) (05/27/91)
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?
--Adam--
--
Adam Frix via cmhGate - Net 226 fido<=>uucp gateway Col, OH
UUCP: ...!osu-cis!n8emr!cmhgate!20.18!Adam.Frix
INET: Adam.Frix@p18.f20.n226.z1.FIDONET.ORGhp48sx@wuarchive.wustl.edu (HP48SX Archive Maintainer) (05/28/91)
In article <1991May23.192221.21509@odgate.odesta.com> mike@odgate.odesta.com (Mike J. Kelly) writes: >>It'd be nice if we had a hardware solution, but at least this may be a >>solution. I still agree with every argument that has gone down the pike about >>this problem, but this may be the best we get. Will this always work? Who >>knows? Is it a slower solution? Maybe. Why should we pay for this fix? I B >>wish we didn't have to, but it seems to me there have been lots of inits >>that were designed to fix problems, like HeapTool. Just now they're making us >>pay to fix them. > >I don't mind paying (new ROMS won't be free). What worries me is how >Connectix does it (and I haven't heard anything but generalities here). >My uniformed guess is that they simply replace the dirty ROM code with >RAM-based versions. That makes me nervous because at least ROM-based >code can't be overwritten or destroyed. If this is in fact what >Connectix is doing (and I repeat: I don't really know), I believe having >key system routines in unprotected RAM would make the Mac even more of >an unstable development platform than it already is. >-- >-- >Mike Kelly Odesta Corporation, Northbrook, Illinois, USA >...!clout!odgate!mike - Until odesta.com is registered. >odgate!mike@clout.uucp - From the Internet. If MODE32 uses the PMMU, then it can write-protect its own code, and thus still have a safe life. -- ******************************************************* Povl H. Pedersen hp48sx@wuarchive.wustl.edu HP48sx archive maintainer
stanfiel@testeng1.misemi (Chris Stanfield) (05/29/91)
I heard last night at our Mac users' group meeting, that Apple are supposed to be buying 4000 sets of Code32 for in-house use. Anyone at Apple care to comment on the validity of this statement? Chris Stanfield, Mitel Corporation: E-mail to:- uunet!mitel!testeng1!stanfiel (613) 592 2122 Ext.4960 We do not inherit the world from our parents - we borrow it from our children.
russotto@eng.umd.edu (Matthew T. Russotto) (05/29/91)
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.
thomas@duteca (Thomas Okken) (05/29/91)
From article <270790.2841D1A9@cmhgate.FIDONET.ORG>, by Adam.Frix@p18.f20.n226.z1.FIDONET.ORG (Adam Frix): > > 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? > > --Adam-- The Mac ROM consists of the Operating System and the Toolbox. The Toolbox is a set of convenience routines that run on top of the OS. When you run A/UX, the OS is replaced by Unix. That is, Mac OS calls are intercepted and passed on, after appropriate translation of parameters, to Unix system calls. The reason that the Mac II/IIx/IIcx/SE30 can't use 32-bit mode under System 7 is that the Memory Manager is faulty - but since the Memory Manager is part of the OS, which is not used by A/UX, the entire 32-bit clean ROM question is irrelevant for A/UX users. BTW, if the vulnerability of RAM-based ROM patched worries you: no Mac System version uses memory protection to protect system globals or ROM patches. Since day 1, it has been possible to crash the Mac by corrupting the trap dispatch tables or patch code. The only way I know of to prevent this is to use Steve Jasik's "The Debugger", which can use the MMU to write-protect the system globals and system heap. (The is, of course, a catch: this feature cannot be used simultaneously with VM. Sigh. Looks like A/UX is the only way to go if you want both at once.) - Thomas (thomas@duteca.et.tudelft.nl)
philip@pescadero.Stanford.EDU (Philip Machanick) (05/30/91)
In article <8063@testeng1.misemi>, stanfiel@testeng1.misemi (Chris Stanfield) writes: |> I heard last night at our Mac users' group meeting, that Apple are |> supposed to be buying 4000 sets of Code32 for in-house use. Anyone at |> Apple care to comment on the validity of this statement? I'm not at Apple, but this doesn't sound likely. Surely they would get a site licence. -- Philip Machanick philip@pescadero.stanford.edu
tgoose@eng.umd.edu (Jason Garms) (05/31/91)
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? > > --Adam-- > > -- > Adam Frix via cmhGate - Net 226 fido<=>uucp gateway Col, OH > UUCP: ...!osu-cis!n8emr!cmhgate!20.18!Adam.Frix > INET: Adam.Frix@p18.f20.n226.z1.FIDONET.ORG A/UX loads a ROM image into RAM. This is perfectly safe because as someone mentioned a few posts ago, a PMMU chip will prevent obnoxious programs from attempting to write into space that doesn't belong to them (namely shadowed ROM image). Jason Garms tgoose@eng.umd.edu
lemke@radius.com (Steve Lemke) (05/31/91)
philip@pescadero.Stanford.EDU (Philip Machanick) writes: >In article <8063@testeng1.misemi>, stanfiel@testeng1.misemi (Chris Stanfield) writes: >|> I heard last night at our Mac users' group meeting, that Apple are >|> supposed to be buying 4000 sets of Code32 for in-house use. Anyone at >|> Apple care to comment on the validity of this statement? >I'm not at Apple, but this doesn't sound likely. Surely they would >get a site licence. A "site license" is not just a generic "copy as much as you want" sort of thing. Large companies will often negotiate a large quantity purchase, but it is just that - a purchase, and not a site license. Thus, it is entirely possible that Apple negotiated to purchase 4000 copies of Mode32 rather than obtain a site license for it. Note that I have no idea whether or not they DID do this, but was merely pointing out that they often do quantity purchases rather than site licenses. -- ----- Steve Lemke, KC6QDT - Software Engineering, Radius Inc., San Jose ----- ----- Reply to: lemke@radius.com -- U.C. Santa Barbara ECE Class of '89 ----- ----- "I'm not a UNIX wizard, but I play the Postmaster at radius.com." -----