Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cca!mirror!rayssd!brunix!nancy!omh From: omh@nancy.UUCP Newsgroups: comp.sys.mac Subject: Re: Possible LSC improvements Message-ID: <20092@brunix.UUCP> Date: Sun, 1-Nov-87 17:18:20 EST Article-I.D.: brunix.20092 Posted: Sun Nov 1 17:18:20 1987 Date-Received: Tue, 3-Nov-87 03:19:04 EST References: <6523@prls.UUCP> <9370001@hpfclp.HP.COM> <1365@elrond.CalComp.COM> <2354@mulga.oz> <21529@ucbvax.BERKELEY.EDU> Sender: root@brunix.UUCP Reply-To: omh@nancy.UUCP (Owen M. Hartnett) Organization: Brown University Computer Science Dept. Lines: 81 In article <21529@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <2354@mulga.oz> jteh@mulga.oz (J.T. Teh) writes: >>One flame that a friend of mine has for LS_Cv2.11 is that it does not >>support MFS. He says it bombs without any messages on Finder 4.1 (MFS). >>Perhaps Richard Siegal may have something to say about that. > > >The actual problem is bad, but not quite this bad. LSC V2.11 does support >MFS, what it does not support is running a program: >1.) compiled with LSC V2.11 >2.) running under a System file of version 2.0 or _older_ >3.) on a machine with 128K ROMs or newer > Actually, the problem is pretty bad, if you're trying to ship a product. > >The cause: LSC inserts preamble code before your main procedure, that >initializes your initialized data. It uses a memory manager call, HGetState() >to determien whethe a handle is locked or not. On some macs this trap >does not exit. Instead of directly comparing the trap address with that of >the UnImplemented() trap, the preamble code looks at the version number of >the ROM. If you are running on a 128K ROM or newer machine, it assumes the >trap is there and calls it. In fact, if you are using old system software >on a new machine, that trap is a direct branch to SystemAlert(). > >The fix: this would be easy to fix, just change that preamble code to make >the correct check. > >The excuse: So far, each of my complaints has been answered with: >"Apple does not recommend the use of System files older than version 3.2 >on machines with 128k ROMs." > >This means that if you want to test your programs under the old, MFS only >versions of Apple's system software, you must buy an old, unenhanced Mac >to test on. (Natural this is a problem only for programmers trying to do >high quality work. My standard testing procedure is to thoroughly test under >_every_ version of Apple's system software, starting with the current >version and working backwards.) > > >--- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. >Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. >Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu I heartily echo David's sentiments (and predicament). An additional problem, What version of the System/Finder are you supposed to ship with? My software works on all versions (128K to II) of Macs. So, I ship with System2.0/Finder4.1. This breaks (as outlined above) on every machine with new Roms. My software program is educational software for pre-schoolers, which means I am going to get a lot of naive users as customers. (By naive, I mean people who don't regularly keep up with all the developments in the Mac world.) Think's response: Ship the program with no system. Great, now it won't even boot. I don't think a slip of paper shipped with the program saying "please copy over an appropriate system and finder from the disks you got when you bought your computer" would be an appropriate thing to do, not to mention Apple's penchant for preferring you to ship a bootable disk. (they like to have you under licensing!) When you write educational software, you really have to design the system to accomodate the most computer illiterate user. It is also against our Macintosh programmers unwritten philosophy of "write the software so that you don't have to read the manual first" to require System/Finder changes. I realize that Apple hasn't made it easy with all the System Finder changes. But this really seems to be an easy thing to catch. My solution: I ported over to MPW. Didn't like it, but I had to in order to support the full gamut of machines (128K to II). Owen Hartnett Brown University Computer Science omh@cs.brown.edu.CSNET omh%cs.brown.edu@relay.cs.net-relay.ARPA {ihnp4,allegra}!brunix!omh