Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!styx!ames!ucbcad!ucbvax!ANDREW.CMU.EDU!rs4u# From: rs4u#@ANDREW.CMU.EDU (Richard Siegel) Newsgroups: comp.sys.mac Subject: Re: Should we support 64K ROMs anymore? Message-ID: Date: Mon, 1-Dec-86 11:10:24 EST Article-I.D.: andrew.MS.V3.18.rs4u.80020c10.mcmurray.ibm032.4598.15 Posted: Mon Dec 1 11:10:24 1986 Date-Received: Mon, 1-Dec-86 20:15:12 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: University of California at Berkeley Lines: 24 Probably the best way to work is to have your program be sensitive to which version of the ROM is installed, and then act accordingly; this is the best of both worlds. I think it is bad practice right now to assume that everyone has the new ROMs, and to ignore the old ROM users... I disagree that it's a bad idea to place so much functionality in ROM. Consider what would happen if the entire OS and Toolbox had to be loaded at bootup. Besides, the System file would be much much bigger than it is now. Also, having a user interface toolbox and operating system in ROM makes life much easier for the user and programmer, by assuring a consistent user interface and selection of tools to help get the job done. Corrections to ROM routines can be written by Apple or the programmer -- these are in the System file (in the case of ROM patches), or else implemented for the duration of the application's execution, as Lightspeed Pascal does. I don't think that Apple's limiting the upgrades to 2 years apart; I think it's a matter of how much programming time it takes to implement the new version....and testing...and so on. Perhaps a user-installable connector (a cartridge?) is a good idea.... --Rich