Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!jade!lapis.berkeley.edu!oster From: oster@lapis.berkeley.edu (David Phillip Oster) Newsgroups: comp.sys.mac Subject: Re: Should 64K ROMs be supported? Message-ID: <1935@jade.BERKELEY.EDU> Date: Mon, 15-Dec-86 00:23:28 EST Article-I.D.: jade.1935 Posted: Mon Dec 15 00:23:28 1986 Date-Received: Wed, 17-Dec-86 05:29:30 EST References: <476@runx.OZ> Sender: usenet@jade.BERKELEY.EDU Reply-To: oster@lapis.berkeley.edu.UUCP (David Phillip Oster) Organization: University of California, Berkeley Lines: 95 As a professional developer, anything that I release to the public has been tested on every hardware configuration I can get my hands on. Unless it uses fancy sound stuff, I make certain it works on a Lisa, (Which uses MFS and the old ROMs.) I do this because: 1.) I want to be compatible with future Macs, being compatible with all past Macs makes this a safe bet. 2.) It helps me catch bugs that fortuitously happen to work on my personal, development configuration. Now how do I handle the increased functionality that the new ROMs provide? I check for the presence of the old ROMs and provide my own replacement behavior. Here is an example from Calendar 1.5 (Written in LSC.) /* do right thing for new and old ROMs * new Rom Resource manager calls */ pascal int Count1Resources() = 0xA80D; pascal Handle Get1IndResource() = 0xA80E; pascal int Unique1ID() = 0xA810; /* WhichRoms - returns version number of ROMS * $FFFF=inRoms64k $7FFF=inRoms128k */ #define WhichRoms *((int *) 0x28E) #define inRoms64k 0xFFFF xCountResources(res)ResType res;{ if(WhichRoms == inRoms64k) return CountResources(res); else return Count1Resources(res); } /* This routine depends on the caller checking for a return value * of NIL some of the time, and the resource file in question being in the * global variable rsrc. */ Handle xGetIndResource(res, i)ResType res;int i;{ Handle h; if(WhichRoms == inRoms64k){ h = GetIndResource(res, i); if(HomeResFile(h) != rsrc) return NIL; else return h; }else return Get1IndResource(res, i); } int xUniqueID(res)ResType res;{ if(WhichRoms == inRoms64k) return UniqueID(res); else return Unique1ID(res); } Notice that I am not re-implementing the new ROMs with my own C code. I am just making certain that my programs work (even with reduced functionality) for all Mac owners. I even try to make my things work on a 128k Mac - This is a good exercise in making your things compatible with the Switcher. When I can't get access to a 128K mac (which is often) I have to settle for making it run in a small switcher partition. Software is important. People depend on the work of my hands. They depend on my work to do what it is advertised to do. People depend on software to be: 1.) reliable (that is, always working.) 2.) correct (that is, producing the right answer when it does work.) 3.) polite (that is, treat them and their intelligence with repect, neither belittling them nor expecting too much of them.) 4.) gregarious (that is, behaving well in crowds.) The Mac is a complex environment. It is important for a piece of software to run well with other software and to clean up after itself so that software that runs after it will work well. These are goals, I don't always achieve them but I try. Making sure it works on the old ROMs helps with reliability, correctness, and gregariousness. My good name is important to me. My good name depends on my software being good. (For example, I care less about my writing than my software - as proof, I have my compiler syntax check all my software but little of my writing.) If you don't start from my assumption, you won't reach my conclusion. But please, as a favor to me and to all of us out here on the net, label your software as "personal, experimental software Note: this software has not been tested except on a a Mac+ with 1 floppy, System 3.2 and Finder 5.3." (or whatever.)