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