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.)