ctm@russell.cs.unm.edu (Clifford T. Matthews) (09/16/90)
Last week we at Abacus Research and Development announce the release of ROMlib-V1.0. Mentioned in the release was a non-product "Executor" which runs Mac binaries. Enough people have asked for more information about Executor to get me to post this snapshot. We've been using Executor to look for bugs in ROMlib. We have the BCS and BMUG Publicly Distributable CD ROMs and are running as much software as we can through Executor to look for bugs that would affect users of ROMlib. Note many things that will interfere with the execution of a binary will not be trouble when doing a source recompilation (e.g. using undocumented low-memory globals is not a problem since if you have the source you know what should be in them). Now that ROMlib is ready for release we will be turning our attention to bugs in Executor itself. Since Executor is not a yet a real product it is not subject to code freeze, so when you order ROMlib you get V1.0 of it and the most recent stable version of Executor (we average about a new one a week). *************************************************************************** This post shows the current state of Executor as of Thu Sep 13 17:20:50 MDT 1990 If there is interest I will post peridiodically (every two weeks?) noting our progress. GREEN Programs that appear to run perfectly within the constraints of no sound, no desk accessories (although if they are buggy on the Mac they'll be buggy under Executor): macyahtzee motorbike 1000miles Silicon Beach's Projector1.0 backgammon canfield2.0 deckedit eartrainer (not very useful without sound) hearts1.6 klondike3.3 reversi stuntcopter1.2 units vp (locally written video poker program) YELLOW Programs that run with some limitations: blackjack2.0: uses outline on black background to write white text (I didn't realize it when I wrote our Font rendering code but it is possible to write white pixels using srcOr and hilite mode; ours does the whiting out offscreen and then Ors in the final result to the screen). MicroSoft DialogEditor: does own dragwindow and stuff can get left in menubar macdraw sampler: text isn't clipped macpaint sampler: blows up occasionally macproject sampler: doesn't write dates to screen PhrazeCraze: Works fine except doesn't recognize the phraze file initially but after you use standard file things work fine. LawnZapper: Clock Problems (the critters don't attack you quickly enough), cycles through pictures for no reason. WriteIdea: no known bugs but hasn't been tested much. killer frogs: no known bugs but hasn't been tested much, heavy user of animation dogs a bit. Silicon Beach Super3D: Uses hierarchical menus which we don't support but you can create images and rotate them. It is especially fun to bring up the image of the Mac and rotate it on a Sun. Interoperability will be the keyword of the 90s. RED Programs that are unusable but should come up with a little more work. Microsoft Excel: if SysEnvirons says we are on equipment that Excel knows about it starts monkeying with the i/o area just to verify that it knows what's going on. Word: Appears to call NewControl with a bogus storage argument. Wingz: weird HFSDispatch call (d0 contains 0x38) Note, calling sequence is "moveq #0x38, d0; HFSDispatch trap" so they are doing it deliberately. SuperPaint 2.0: stack pointer gets fried after doing HFSDispatch Apple Hypercard1.2.2: Flaky; especially when reading/writing a file. You can use the tear off menu, look at scripts, etc. Requires -refresh option since it writes directly to screen memory macwrite: uses traps (including trap #0) which conflict with UNIX. Our kernel mods theoretically support this but it still doesn't work; hard to figure out what's going on. lunarlander: counts on SetPortBits not munging d0. It will limp under executor-O, since executor-O:SetPortBits doesn't touch d0. This is an example of a program that was probably written in assembly and accidently makes use of knowledge about which registers are clobbered beyond what you are guaranteed. movl 0xA7C, A0 movw sp@(4), a0@(0x18) trick just like lazlife lazlife2.0c: has worked in the past, currently doesn't work; quite possibly problems similar to lunarlander. supermandelzoom1.0: Doesn't appear to see mousedown events during the update of the current mandlebrot, does see the update after the mandlebrot is fully drawn. hangman-9.0: Wants to go ripping through FCBSPtr, which we don't currently support DarkCastle: Dies a horrible death (probably needs it's own Finder and system file that are supplied) FullWrite: Blows up early on. Probably decompression stuff related to traps (should check by watching which traps are patched). STILL RED The following are 'demo' versions of many programs (they can be found in the Demonstrations subdirectory of the "bonus" subdirectory of the BCS CD ROM) 4DDemo2.0: Uses SetItemCmd (perhaps could be faked) ActaAdvantage: Uses TEStyleNew BDSDemo: Uses SetItemCmd (perhaps could be faked) Buick: Expects patching "GetResource" to trap calls to GetPicture so that they can translate 'PIxT' (where x is a capital Pi) into PICT (appears to be huffman encoded). Will require internal use of traps. (Although executor knows what traps are what, GetPicture just calls GetResource directly rather than doint the appropriate a-line trap). BusinessWeek: starts up nicely though we forgot to copy all the files over and haven't tested it yet DblHlxEngn: Some sort of problem with non-existant MDEF (may require more files). DiskRanger: Calls PACK2 early on (perhaps could be faked) DrawingTable: Memory problems when calling R_Unlock (deb#405) could be 24 bit addressing Fontographer: goes until it trys to create a font then gets -36. FreeHand demo: Jumps to 10 off ROMBase expecting it to do something. I doubt this says much about what FreeHand will really do since the demo appears to be just canned graphics. FullWrite demo: Mystery blow up; reads what should be a small number from fp@(8) and gets large number (0xBDC8). No idea who is calling whom. Graph: Appears to make a SANE call with an undocumented print style *************************************************************************** a little history: ROMlib was begun in September of 1986; all the code was written with an eye toward binary compatibility. Work on executor commenced May 7th, 1990. There is little dependence on UNIX or X11 in either; we are in the process of writing filesystem code so that we can do a true Mac filesystem as a big file under UNIX and with direct calls to device manager routines as part of a Mac clone. Although we know some speedups that can substantially enhance our blitter they are being delayed and rolled into color support. p.s. The fee for the educational network license (unlimited # of CPUs but for educational institutions only) for ROMlib will be $1,000 per architecture. Right now all we officially support is Sun3s so $1,000 allows you to run ROMlib (and Executor) on all the Sun3s at your favorite learning establishment. Call if you can't wait for more details. If you work for a hardware company and would like us to port ROMlib to your platform, get us a machine while we're still small; If you're an ISV and you'd like to incorporate ROMlib into a product, give us a call. [no affiliation with the University of New Mexico] Cliff Matthews Abacus Research and Development, Inc. 1650 University Blvd. Albuquerque, NM 87102 (505) 766-9115