Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!voder!apple!dgold From: dgold@apple.UUCP (David Goldsmith) Newsgroups: comp.sys.mac Subject: Re: Should we support 64K ROMs anymore? Message-ID: <360@apple.UUCP> Date: Fri, 5-Dec-86 14:02:58 EST Article-I.D.: apple.360 Posted: Fri Dec 5 14:02:58 1986 Date-Received: Fri, 5-Dec-86 21:32:46 EST References: <385@runx.OZ> <1366@hoptoad.uucp> <342@apple.UUCP> <1411@hoptoad.uucp> Reply-To: dgold@apple.UUCP (David Goldsmith) Organization: Apple Computer Inc., Cupertino, USA Lines: 89 In article <1411@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Well, the best estimates I've seen were that 50% of the existing >applications either broke under HFS, or just barely limped along under it, >so that new versions were neccessary.... If you look at the most popular commercial applications, this wasn't true; most worked without modification. It's possible that as an absolute fraction of ALL Mac applications, it might well be true. >...I think you're overestimating the market power of >your ill-defined compatibility hacks. I can't agree. I think the fact that a majority of existing applications continued to run with new releases of the ROM was vitally important to keeping Mac attractive in the marketplace. >Finally, this attitude seems like it must itself be rather a large drag on >OS improvement. Why not just say that you will continue to be compatible >with correct applications? If you can't re-implement, then you can't find >and implement faster and/or smaller algorithms, for instance. It IS a drag, but it's not an insurmountable problem. Solving it involves 1) educating developers as to the right thing to do, 2) as you say, giving developers as much advance warning as possible, and 3) making changes carefully to give people time to react. >There are low-memory globals defined and even recommended in the Tech Notes >that are not mentioned in Inside Macintosh. So this is not quite true. Of course, I never meant to exclude the Tech Notes; I consider them an extension of Inside Macintosh. Sorry. >In any case, I don't see this as a problem. If one developer could figure >out the low-memory global's use using the list in the Software Supplement, >then the re-implementer can figure it out and use it the same way. That may be true, but then you're no longer talking about an easy project. >>- Rely on behavior specific to the ROM's implementation rather than its >> interface. >This is a serious programming error. If someone does that, then tell them >to take a hike. they are risking their future compatibility; you don't make >guarantees about future behavior of this sort, so for all they know you >could blow them away with the next System file. The problem is that people don't do this intentionally; their programs just happen to work -- until we change the ROMs or System file, that is. The Clint Eastwood attitude is unacceptable: if we blow away these applications, some of which are extremely popular, the losers are our customers, whose software doesn't work -- not the developers, who can always come out with a new version. Even in cases where people did incorrect things deliberately, we can't shaft all of our users because of that. >Still, thanks for your quick and well-informed reply. You brought up some >interesting points. There are some things on the Mac that just can't be >done within the bounds of the future compatibility guidelines, Inside Mac, >the Software Supplement, and the Tech Notes. I'd like to hear more >discussion of these things here. To start off, has anyone discovered a way >of accessing globals at the interrupt level without using writes into code >resources (which may be marked read-only in a hypothetical memory-managed >Mac)? There are tricks if you are running inside a completion routine >(putting the globals register in an unused field) or a vertical retrace task >(stick it in the VRQ element), both involving the semi-documented fact that >the address of the parameter block or retrace task will be in a0, but this >trick is not available in every case where code runs at the interrupt level. Thank you for bringing these points up. I disagree emphatically that Inside Mac, the Software Supplement, and the Tech Notes are insufficient. I have very rarely seen something done outside the bounds of what we say is OK which couldn't have been done the "right" way. For example, if you want to access application globals, the low-memory global CurrentA5 (documented in IM) contains the value of the application's A5 register (although naturally you have to worry about concurrency when accessing you own globals from interrupt level). When people do run into these problems, our Developer Tech Support department tries to come up with a "correct" way of doing it, which then winds up in a Tech Note. You should certainly bring these things up for discussion. Apologies to all for the length of this message. -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY