harrow@exodus.dec.com (Jeff Harrow, NCSE BXB1-2/E02 DTN=293-5128) (04/29/87)
In response to my original question regarding the need to write conditional code for use of some new calls/structures (such as color windows, etc), David Goldsmith of Apple replies: >Some of the new features have been backpatched onto 128K ROM machines. >Basically, most of the new functions (TextEdit, Menu Manager, etc) are >available on anything with 128K or later ROMs running System 4.1 or >later. This is not true for any of the color functions; these are >available only on the Mac II, so I'm afraid that "yuk!" is the order >of the day. > >David Goldsmith >Apple Computer, Inc. >MacApp Group David, I'd first like to sincerely thank you, Larry, and others at Apple who respond so promptly to questions posed here on the net; this does a tremendous service to prevent rumors and misinformation. Regarding this issue, however, how about some type of patches in the "lower" systems (non Mac ][ at this point) which will AUTOMATICALLY translate the "color" (and other unsupported calls/structures) into a form which WILL work. Consider, although in the case of the Mac ][ vs. Classic Mac writing conditional code is feasible (although NOT in the spirit of full backwards compatibility that has been maintained in the past), what will happen when the NEXT advance in Mac technology (you ARE working on such, aren't you?) comes along... Will we have to have MULTIPLE levels of conditional code based an a tree structure of growing complexity, just to figure out WHAT calls to issue? This strikes me as a significant burden on developers causing an increase in time/cost of programs, but most importantly probably GUARANTEES that a larger percentage of programs will NOT be fully backwards compatible. You folks have done SUCH a good job on this in the past, and have come SO close even in the Mac ][ world (with as you pointed out backward patches to TextEdit, etc.), why not go that extra mile ONCE so that each and every developer won't have to put the effort in for EACH program? Thanks for your consideration, Jeff Harrow Work address: ARPAnet: HARROW%EXODUS.DEC@decwrl.ARPA Usenet: decwrl!exodus.dec.com!harrow or {allegra,Shasta,decvax}!decwrl!dec-rhea!dec-exodus!harrow Easynet: EXODUS::HARROW Telephone: (617)264-5128 USPS: Digital Equipment Corp. Mail stop: BXB1-2/E02 85 Swanson Road Boxboro, MA 01719
dgold@apple.UUCP (04/30/87)
In article <9575@decwrl.DEC.COM> harrow@exodus.dec.com (Jeff Harrow, NCSE BXB1-2/E02 DTN=293-5128) writes: >Regarding this issue, however, how about some type of patches in >the "lower" systems (non Mac ][ at this point) which will >AUTOMATICALLY translate the "color" (and other unsupported >calls/structures) into a form which WILL work. We have tried to do this where data compatibility is concerned, e.g., there is a patch to DrawPicture on the 128K ROM and SE to be able to play back the new color pictures produced on the Mac II. However, there are two reasons it is not really feasible to go farther than this: 1. The new color traps are in a range which doesn't exist on anything except the Mac II. They are Toolbox traps in the range AA00-ABFF. The Toolbox trap table on the Mac Plus and SE is not big enough to hold these traps. To change this would require patching the trap dispatcher, which would slow things down a bit on those machines. 2. Color QuickDraw represents a large amount of new effort over old QuickDraw. There are many new data structures which would have to be interpreted or converted to process the new calls. In order to fully support color programs, we would have to support the new CGrafPort (color GrafPort) structure, which is laid out differently. Since the GrafPort data structure lies at the heart of QuickDraw, we would have to patch out most or all of QuickDraw, which isn't really feasible (it might take 80K-100K of patches). Finally, color QuickDraw uses 68020 instructions heavily to speed it up, so the be supported on a 68000 it would have to be modified. For MacApp 1.1 we have modified one of our sample programs (DrawShapes) to support color, and it really is not that hard to draw things differently depending on what machine you're running on. The changes to MacApp itself to support color were not that great. It's unfortunate that we can't make the incompatibilities vanish altogether, but in this case it would come at a large cost. Oh well. -- 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 BIX: dgoldsmith