Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!uc!noc.MR.NET!msi.umn.edu!umeecs!umich!samsung!rex!wuarchive!usc!apple!bionet!agate!shelby!neon!pescadero.Stanford.EDU!philip From: philip@pescadero.Stanford.EDU (Philip Machanick) Newsgroups: comp.sys.next Subject: Re: Mac emulator Message-ID: <1990Oct26.003926.18669@Neon.Stanford.EDU> Date: 26 Oct 90 00:39:26 GMT References: <656892267@macbeth.cs.duke.edu> Sender: news@Neon.Stanford.EDU (USENET News System) Reply-To: philip@pescadero.stanford.edu Organization: Computer Science Department, Stanford University Lines: 20 In article <656892267@macbeth.cs.duke.edu>, mdl@duke.cs.duke.edu (Michael D. Landis) writes: |> Seems like, if you had a set of routines that did the equivalent of Mac |> things, but in the NeXT environment, and if you knew the entry points |> in the roms, then you could write a program to load a Mac binary file, |> re-link the entry points to transfer control to the new routines, and |> possibly do some other address translation, etc for IO, and then run |> the program. Actually, the ROM addresses aren't built into the code. System/toolbox calls are by invalid instruction traps. The trap dispatcher uses a table of ROM addresses (potentially overwritten for RAM-based patches). The advantage of this approach is there is no load-time overhead (compared with dynamic linking), but at the expense of extra overhead for trap dispatching (if you have performance-critical code, you can dynamically look up the address of any routines used in it to cut out the trap dispatcher). I don't want to get into any debate about whether this is a good or bad technique - just adding a data point. -- Philip Machanick philip@pescadero.stanford.edu