Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!unmvax!sugar.cs.unm.edu!ctm From: ctm@sugar.cs.unm.edu (Clifford T. Matthews) Newsgroups: comp.sys.mac.misc Subject: Message-ID: <1990Oct5.000936.2420@unmvax.cs.unm.edu> Date: 5 Oct 90 00:09:36 GMT Sender: news@unmvax.cs.unm.edu (The News service) Reply-To: ctm@sugar.cs.unm.edu (Clifford T. Matthews) Organization: University of New Mexico, Albuquerque Lines: 249 Greetings ARDI watchers, This post is a briefly annotated set of notes that we are using at ARDI to keep track of how well which applications run under Executor. They may appear a bit incoherent because most of our notes are kept on hard copy (yellow legal pads; ooh, ick but it is important to have a paper trail). In case you came in late: Executor is a program that runs Macintosh binaries on Sun3 machines. One copy is given away with each copy of ROMlib we sell. ROMlib is the product, Executor is currently just for laughs. (ROMlib is a UNIX ARchive and some tools that allow you to recompile C source with embedded Toolbox calls and run the resulting executable as an X application). Please do not consider buying ROMlib to get Executor unless you want a "toy." Even if you see something that you would desperately like to run on your Sun3 and we say it runs there is no guarantee that the copy of Executor that you'd get would run the application since it's not a product and the latest copy could conceivably work worse that a previous copy. Note as long as we have a sufficient number of mystery bugs to work on we will not be adding applications to the list below. When we do, we will most likely add applications from either the BCS or BMUG PD ROMs. The lack of full versions of big name applications is due to our cheapness. We do not pirate software so if we are busy testing a non Publically Distributable piece of software then that means that the owner of said software is not using it. Before we release Executor as a product we will go on a shopping and testing spree. ***************************************************************************** G R E E N The following programs are considered "green"; they run without error under Executor. I don't think there has been much change in the green directory since most of our time has been spent getting programs to move from "red" to "yellow". macyahtzee: stomps location 0xe (It does this on a Mac+ too) eartrainer (not useful: no sound) backgammon hearts1.6 stuntcopter1.2 reversi MotorBike: after a crash it does a spooey copy (on the Mac+ too) 1000miles canfield2.0 klondike3.3 deckedit vp units Y E L L O W The basic definition of Yellow is those programs that are between "Red" and "Green". In the best case they are applications that may work perfectly but haven't been tested enough to be sure. In the worst case (e.g. 4DDemo) they may be applications that absolutely can't run because they call something that we don't support (e.g. ScriptUtil) but they aren't placed in Black because they run with enough interaction to look neat. The majority of the apps here run but with some known glitches (which are noted). Since we have been spending most of our time moving apps from Red to Yellow, the glitches don't get worked on much right now. blackjack2.0: uses outline on black background to write white text DialogEditor: does own dragwindow and leaves stuff in menubar Hypercard1.2.2: writes directly to screen (requires -clock -refresh) hasn't been tested much (is probably very buggy). Works well enough on Stack-O-Dead to be amusing to deadheads (no sound though). lazlife2.0c: writes directly to screen (requires -refresh) Picks up mystery value from 0xA7C (in ApplScratch) and stores funky value at 0x18 off it. I think other apps do this before they leave as well. macdraw sampler: text isn't clipped macpaint sampler: writes directly to screen and hasnt' been tested much (requires -refresh) macproject sampler: doesn't write dates in boxes Fontographer Demo: needs testing supermandelzoom1.0: a touchy program. Limps. Doesn't see mouse stuff as it occurs (waits to draw the entire "bug") GrapherDemo: doesn't redraw graphs always 4Demo2.0: Uses ScriptUtil. Limps otherwise Multi-AdCreatorDemo: needs testing. MultiFlow: needs testing ParadigmDemo: No known bugs. Should be tested. Pleides: appears to have problems w/funky control Synchronicity: No sound SonarDemo: Places a button in the wrong place. Margins don't seem to be set quite right. They try to go 4 off of a nil pointer. DungeonofDoom4.0: requires -clock -refresh -nbitsinaddr 24 but seems to work (have only played a few levels) R E D The applications below are totally unusable. Some of them decide something is amiss and then just exit. A couple decide we don't have enough memory (even though the obvious calls are returning correct values), some bugs are a total mystery; luckily there aren't that many totally mysterious bugs around. 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. This can be avoided by saying we using processor 0xffff or something like that. Then Excel claims we don't have enough memory Much work has gone into tracking this down. No clue. SuperPaint 2.0: Plays with RomMapInsert Thinks we don't have enough memory (foo!) Wingz: OpenDeny call HACKED. Wingz now just exits... wizardsfire: Wants to ExitToShell, although does movl 0xA7C, A0 movw sp@(4), a0@(0x18) trick just like lazlife hangman-9.0: Exits of its own accord (uses FCBSPtr which isn't tested much) Stella: Exits normally without doint anything. Word: Calls NewCWindow, even though SysEnvirons has already returned that we don't support Color QuickDraw MYSTERY macwrite sampler: requires -nbitsinaddr 24 deb#232 GetResource('CODE', 2) 233 BlockMove 234 EmptyHandle 235 CompactMem 236 BlockMove (this is called with a dest/count that trashes a block header... foo!) DrwTable: Memory problems when calling R_Unlock (deb#405) Peculiar code: link fp,#-8 ... tstl fp@(-4) /* check for non-zero retpc? */ beq 1f movel fp@(-4),sp@- /* push the retpc on stack? */ jsr /* glue to do an HUnlock */ 1: unlk fp rts I just checked: This spooey code gets executed on the Mac and the Mac has the good sense to blow off the call to do the HUnlock. We could get by it if we were to do a sanity check (address has to point into stack or to memory below brk) before converting the Handle to a block (which is necessary to detect nilHandle and WZErrors) lunarlander: counts on SetPortBits not munging d0. This bites. It will limp under executor-O, since executor-O:SetPortBits doesn't touch d0. It still writes directly to the screen and because it uses scaled text, the text is placed too low on the screen. Buick: Expects patching "GetResource" to trap calls to GetPicture so that they can translate 'PIT' into PICT (appears to be huffman encoded). Will require internal use of traps. (of course we could do it just for GetPicture and get further into Buick) MYSTERY BusWeek: Requires file names to be lower case, then gets an illegal instruction. DblHlxEngn: Some sort of problem with non-existant MDEF (may require more files); should be looked into. DiskRanger: Doesn't find any files when cataloging. FullWrite demo: Checks out KbdType which we don't yet support (why not?) Mystery blow up; reads what should be a small number from fp@(8) and gets large number (0xBDC8). No idea who is calling whom. FullWrite: Blows up early on. Probably decompression stuff related to traps (should check by watching which traps are patched) BDSDemo: Can't open file I/O (because UNIX files can't have '/' in their name) so we can't do anything with any of the simulations. Uses Hierarchical menus so we're fried there as well. Leppy: Calls SndNewChannel Nisus: Release resource pukes. NoteWrit: About box not placed properly. R_HLock blows up. Shanghai: splodes big time (color problems?) Silver Fingers: Blows up assigning the title to a dialog window... on Mac it probably doesn't give a damn. Telewarp: starts up then hangs. B L A C K These apps require something we don't support (but we know what it is, otherwise it would be in Red as a mystery). Currently we don't put apps that user hierarchical and pop-up menus here because the rest of the app is runnable. Because of the prevalance of hierarchichal and pop menus and TEStyleNew we have boosted the priority of implementing them. Hypercard1.2.5: requires Sys 6.04. (Can't lie, it uses new traps) MathReader: uses TEStyleNew ActaAdvantage: Uses TEStyleNew. FreeHand demo: Jumps to 10 off ROMBase expecting it to do something Mustang: Uses Lvl1DT. ***************************************************************************** That's the current state of Executor. Everyone at ARDI appreciates the encouragement we've been receiving. Clifford T. Matthews Abacus Research and Development, Inc. 1650 University Blvd. NE Albuquerque, NM 87102 (505) 766-9115 [ARDI is not associated with the University of New Mexico]