erics@eleazar.dartmouth.edu (Eric Schlegel) (12/02/89)
A completely new solution to the tail-patching dilemma: the problem with
tail-patching arises from:
1. There are ROM bugs.
2. Rewriting entire routines take too much memory, and...
3. Releasing new ROMs is impractical for several reasons (cost, user
installation, etc.), so...
4. Apple bug-fixes using come-from patches.
HOWEVER: in this week's Infoworld was an article about Intel's Flash EEPROMs.
These are ROM chips that are easily erasable and reprogramable without any
fancy ultraviolet hardware, etc. Now, would it be feasible for Apple to use
Flash EEPROMs in future machines, and thus a new system release would contain
a 512K ROM image that would be automatically loaded into the system ROMs.
Bugs in ROM routines can be fixed BY REWRITING the routine in the new ROM
image; there's no RAM usage, no come-from patching necessary, no user
installation problems, no muss, no fuss.
This _is_ a serious suggestion. What do you think? Has Apple looked at
this possibility?
-eric
eric.schlegel@dartmouth.edumnkonar@gorby.SRC.Honeywell.COM (Murat N. Konar) (12/02/89)
Tail patching is for quiche-eaters who don't want to learn how
the stack works and how to fix things in assembly. Face it,
programming the Mac is a challange. You have to go beyond
the compiler and really understand what's going on when you
are patching traps. And get this: sometimes you can still
screw things up EVEN USING A HEAD PATCH! For example, there are
times when all registers must be preserved (LoadResource
comes to mind).
If you want to learn more about what the compiler does
and how the stack works, go buy Scott Knaster's "How
to Write Macintosh Software." It even has a discussion
of why tail patching is evil.
I'm sure there are rare cases when only a tail patch will
work (can't think of any though), but I can't belive that all
the whiners out there can't do what they want to some other
way. Just be smarter about it.
Sheesh.
P.S. I don't think that ROM's should be made replacable so that
someone can use a tail patch to make flushing noises when the
toilet (trash) is flushed (emptied).
____________________________________________________________________
Have a day. :^|
Murat N. Konar Honeywell Systems & Research Center, Camden, MN
mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (12/02/89)
erics@eleazar.dartmouth.edu (Eric Schlegel) writes: > [suggests using some sort of new re-programmable ROM in the Mac] Just a quick thought... Could you imagine what a virus could do with just such a ROM. One of the things I like about all the computers I can think of is that if you turn it off and back on then it's "fixed". I wouldn't even want to have to think about the consequences of having my computer re-programmed with re-writable ROM's. But then again I might've miss-understood the ROM's purpose. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | Graduating in March of 1990, with a BS in Computer Science & need a Job. | |_____________________________________________________________________________|
brecher@well.UUCP (Steve Brecher) (12/18/89)
In article <41304@srcsip.UUCP> mnkonar@gorby.UUCP (Murat N. Konar) writes: > Tail patching is for quiche-eaters who don't want to learn how > the stack works and how to fix things in assembly.... > I'm sure there are rare cases when only a tail patch will > work (can't think of any though)... I haven't been able to think of a way to implement Suitcase II without tail patching. By the way, what's a stack? But seriously... there is one technique that sometimes will let one eat one's quiche and have it, too. In some cases it is feasible to JSR to the predecessor trap code, do some processing, and then JMP to it -- i.e., execute it twice. The target of the JMP would invoke the ROM patch, if any. -- brecher@well.UUCP (Steve Brecher)