Path: utzoo!attcan!uunet!husc6!rutgers!apple!rpd From: rpd@Apple.COM (Rick Daley) Newsgroups: comp.sys.mac.programmer Subject: Re: Multifinder: how do I patch GetNextEvent? Summary: Apple can't supply come-from patch list Message-ID: <18969@apple.Apple.COM> Date: 18 Oct 88 18:07:13 GMT References: <747@ttrdf.UUCP> <10050025@eecs.nwu.edu> <2456@spray.CalComp.COM> <5677@hoptoad.uucp> Organization: Apple Computer Inc., Cupertino, CA Lines: 30 In article <5677@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > It seems that what you're saying is that the only safe kind of patch is > one that does its stuff, clears the stack back to the return address, and > then does a JMP.L to the old trap. Ick. Most trap patching applications > I've seen or speculated on just can't be done that way. Could we at least > get a list of "where-from" traps to make things a little less awful? Sorry, but it's not possible to predict which traps may get come-from patched in future system releases. These patches are there to fix bugs, and there wouldn't be any bugs if we knew where they all were. There are only three ways I know of for Apple to fix bugs in ROMs that have already shipped: 1) We can use come-from patches that work, but make us forbid tail-patches. 2) We can use patches that replace the defective routine, but waste lots of memory. New system releases already use up alot of the memory on a mac plus. 3) We can send out new ROMs. Assuming that the bug fixes and new features would all fit in the mac plus ROMs, this still means someone has to install them. If you take your own mac plus apart, and touch the wrong thing, you will be very dead and unlikely to buy Apple products in the future. Basically, the choice is somewhat like voting for the president. None of the choices are any good, but some seem to be even worse than others. Come-from patches seem to be the least of the evils. Rick Daley rpd@apple.COM These opinions were actually conveyed to me by each and every Apple employee and stock holder.