Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac Subject: Re: Should we support 64K ROMs anymore? Message-ID: <1411@hoptoad.uucp> Date: Thu, 4-Dec-86 21:23:46 EST Article-I.D.: hoptoad.1411 Posted: Thu Dec 4 21:23:46 1986 Date-Received: Fri, 5-Dec-86 05:27:40 EST References: <385@runx.OZ> <1366@hoptoad.uucp> <342@apple.UUCP> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Centram Systems, Berkeley Lines: 93 In article <342@apple.UUCP> dgold@apple.UUCP (David Goldsmith) writes: >You are welcome to try this; however, you will find that 50% of the existing >applications break, because they rely on features of the ROM above and >beyond those documented in IM, including those which are not "features" >but actually implementation details. 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. The conversion process overall took less than six months, and would have taken even less time if Apple had made HFS more widely available for compatibility testing before its release. So this is not really an unsustainable burden. Converting to HFS has, if anything, accelerated the speed at which applications are produced; there has been no perceptible drag. A similar phenomenon might be associated with cleaning up the operating system. In addition, if the re-implementation had available source code, there would be a lot of desire by developers to use it instead, accelerating the conversion process. I think you're overestimating the market power of your ill-defined compatibility hacks. 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. > Many commercial applications: >- Rely on undocumented low memory variables which are in fact internal to > the ROM's implementation. If it's not in IM, you're not supposed to do > anything but look at it when debugging. 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. 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. >- 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. >- Depend on values coming back in registers which are not part of a ROM > call's interface, or depend on the global state (such as current GrafPort) > being set a certain way which isn't part of the interface, and so on. > The 128K ROM has many places where it specifically sets a certain register > to a certain value before returning so a specific application won't break. See previous answer. This will also wind up presenting you problems when you go to multitasking with the 68020 Mac. Furthermore, the Mac documentation has insisted that you not do this for a long time, and again, the person is risking their future compatibility if they do it. The future compatibility notes released (twice) in the Software Supplement say so. >- Some applications do things which are incorrect and just happen to work, > and changing one tiny thing makes them break. There is no way that you can maintain compatibility with every case of doing this and make any improvements to your OS. Once again, I really think that supporting incorrect applications is not a serious problem, because it doesn't have to be done. Anything which breaks under a re-implemented Mac OS might just as easily break in the next Apple ROM release. >Maintaining and enhancing the ROM is hard because so many applications go >beyond IM in what they do. Of course, if you'd rather have a machine which >didn't run any of your existing software, implementing the ROMs would be a >snap. You're welcome to try. I thought you said 50%? If half of those are a result of semi-documented low-memory globals, then the figure is more like 25%, and all those would be applications which contained glaring errors. Given that 50% of applications broke under HFS, this does not seem like such a huge problem; particularly if developers have access to the new system before its release to users. 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. -- Tim Maroney, Electronic Village Idiot {ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp) hoptoad!tim@lll-crg (arpa)