joel@gould9.UUCP (02/20/87)
The MacInTouch article noted compatibility problems with a number of pieces of software. Now Apple has sent out a packet to certified developers, all but announcing a new machine "soon" and a 68020-based product under development: Macintosh Compatibility Alert -- February 1987 (stop sign icon w/hand) Stop! Do not throw this away. Contains important compatibility information. (OK) This is a special compatiblity mailing to all Macintosh Certified Developers. We're not trying to limit its distribution, so copy any and all of this information and distribute it freely (and for free). You've seen some of these technical ntoes before, but we've included them for emphasis. THE FUTURE IS CLOSER THAN YOU THINK Apple Engineering has been working on variations on the Macintosh theme. They've gone to great lengths to make sure that existing software will continue to work when the changes hit the streets, but they can only go so far. Now it's your turn. We've put together this mailing to give you an idea of what things may cause you trouble in the near future. The compatibility issues you've been putting off until later need to be looked at NOW. We're not just telling you it's a good idea to stay in the crosswalks, we're telling you there's a truck on its way and it's headed straight for you (and your applications). This mailing includes the following: Technical Note #2A--Compatibility Checklist (2/9/87) Development System Compatibility Note Technical Note #117--Compatibility: Why and How (DRAFT, 2/9/87) Technical Note #7--A Few Quick Debugging Tips (4/16/86) Technical Note #83--System Heap Size Warning (6/21/86) Technical Note #100--Compatibility with Large-Screen Displays (11/15/86) Technical Note #2--Macintosh Compatiblity Guidelines (2/9/87) [ 2A is a summary of 117. I'll present 2A with paraphrase of 117 as background, and my own comments in [] -jww] <117: Bad Things "These are the current top ten commandments: I. Thou shalt not assume the screen is a fixed size. II. Thou shalt not assume the screen is at a fixed location III. Thou shalt not assume that rowBytes is equal to the width of the screen. IV. Thou shalt not use nil handles or nil pointers. [ Did this ever work? ] V. Thou shalt not create or use fake handles. VI. Thou shalt not write code that modifies itself. VII. Thou shalt think twice about code designed strictly for copy protection. VIII.Thou shalt check errors returned as function results. IX. Thou shalt not access hardware directly. X. Thou shalt not use any of the bits that are reserved (unused means reserved.) " > #2A: Macintosh Compatiblity Checklist ... If you do not follow the guidelines in this note, your software is virtually guaranteed to fail on future Macintosh computers. * Do not hard-code for a screen size of 512 by 342 pixels. Get the size and memory location fo the screen from the QuickDraw global screenBits. * If you're creating an offscreen bitmap, do not assume that the entire screen image is smaler than 32K bytes (that is, don't assume a short integer) <117: use screenBits.bounds for the size, screenBits.baseAddr for the location. Use mBarHeight on 128k ROM and later for menu bar height, instead of a constant 20. Do not assume that the screen bitmap is rowbytes wide. "With an Ultra-Large screen, the number of bytes used for screen memory may be in the 500,000 byte range...a 16 bit Integer will not be able to hold the 500,000 number, so a LongInt would be required." > [ 500,000 bytes ~~ 1,024 x 1,024 x 4 bit planes. The universities have said they want Megapixel machines, so presumably Apple will get there before Steve Jobs' non-competition agreement runs out this summer, although Jobs is said to be behind schedule. ] * Do not hard-code the addresses of the SCC, VIA, or IWM chips. Get the addresses of these chips from the low-memory variables SCCRd, SCCWr, VIA, and IWM. <117: you can use the hardware directly, but use the indirect address > * Avoid using the TRAP instruction, since exception frame formats vary on different members of the 68000 microprocessor family. Also, avoid using the RTE instruction except as a true return from exception. <117: Don't write self-modifying code, such as copy-protection code. "There are third-party upgrades available that add a 68020 to a Macintosh. Because of the 68020's cahce, programs that modify themselves stand a good chance of having problems when run on a 68020. This is a compatiblity problem that should not be missed. (nudge, nudge, wink, wink.)" > [ The TRAP is why MacWrite crashes on the Levco Prodigy or any 68020 or later. Using RTE for a subroutine return is lazy or foolish or both; it fails on a 68010 or later. RTD is much better and safer, but requires >= 68010.] * When your application opens a file ... do not repeatedly open and close the file. Instead, leave the file open until the user [closes the window]. This will prevent unwanted shared access if the document resides on a shared volume, such as a file server. * If you application creates temporary files, be sure that the filenames are unique... * Do not assume there is a maximum of 1 megabyte of RAM, or that the only valid RAM sizes are 512k and 1M, or even that 512k is available (you may be running under Switcher.) * Do not directly manipulate a master pointer's flag bits... [ I.e., we plan to make addresses in the master pointer 32 bits, not 24 bits as at present ] <117: Don't use bits that are reserved... only the top bit of ROM85 ($28E) refers to the 128K ROM. "This means the rest of the bits in that word are reserved, since nothing is described about any further bits... An example of a bad way to do the comparison is: ... IF Rom85Ptr^ = $7FFF THEN RomsAre 128 := True { Bad test. } ELSE RomasAre128 := False; "> [ from MacInTouch 'Mac II First Look': "Cricket Draw gives a message saying it's only compatbile with 128K ROMs and quits to the Finder."] * Do not assume the system [sic] application heaps start at a fixed address...use SysZone and ApplZone. <117:"It is still your choice whether you will be concerned with compatiblity or not. Apple will not put out a warrant for your arrest. However, if you are doing things that are specifically illegal, Apple will also not worry about "breaking" your program."> -- Joel West MCI Mail: 282-8879 Western Software Technology, POB 2733, Vista, CA 92083 {cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel joel%gould9.uucp@NOSC.ARPA