info-mac@uw-beaver (info-mac) (11/07/84)
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
No. 1 September 30, 1984
The Macintosh Developers Newsletter
Welcome...to our first newsletter for Macintosh(TM) software developers!
We're going to use this forum every few weeks to tell you about all sorts of
stuff, such as hot technical info, new product introductions, and anything else
interesting we can find. Have fun!
Macintosh 512K...is the big, big news from Apple. On Monday, September 10,
Apple introduced the new Macintosh with 512K bytes of RAM, beating the
estimated ship date by about 4 months! The quadrupling of RAM is the only
difference in the new machine: same ROM, same everything else. All that's
changed is another 384K bytes of muscle --- and no "Fat".
You can order your Macintosh 512K and 512K upgrades for 128K systems at great
prices on the certified developer program.
Don't lock yourself out of the 512K market. Make sure you test your
applications in both the 512K and 1 Megabyte (with MacWorks) environments
before shipping. Both the 128K and 512K Macintosh systems will continue to be
popular. The ideal application will run on a 128K, with both faster
performance (due to less segment loading) and larger data space when run on a
512K or 1M. This is the case, for example, with our forthcoming MacDraw and
MacProject applications. In some cases, your data structure will be fixed and
won't grow with memory size. Still, you should be able to get better
performance with the proper use of segmenting and calls to UnloadSeg. This is
how MacPaint works. For information on segmenting, see Cary's immortal File
example program.
As you know, you can assure yourself of compatibility with present and future
Macintosh environments by following a few simple guidelines: don't hard code
to memory addresses; don't depend on the location of routines in ROM; don't
depend on a maximum of two drives, each holding 400K; don't assume a screen
size of 512 by 342 (the MacWorks screen is 720 by 364). If you have any
questions about what's "legal" and what's not, just ask your friendly Tech
Support folks.
We've been telling you all along not to hard-code for specific memory sizes,
to use the low-memory globals for things like the screen size and location, and
we've supported those globals in the 512K and MacWorks. For example, if you
want to know where RAM ends, look at MemTop ($108); ScrnBase ($824) points to
the beginning of the screen, etc.
Compiler and code generator options...may be causing you problems. You
probably know that the compiler option $R- turns off range checking, but you
may not know that you should always use $R- for now, since the range checking
code sometimes trashes registers. This is a bug in MacPasLib, which is
undergoing a complete overhaul and should be ready before the end of the year.
We won't have MacPasLib to kick around much longer...
The mysterious $M+ is a code generator option which is absolutely required.
It generates code to preserve D3 and A2, which the compiler normally thinks are
trashable. Since those registers are the last to be used by Pascal, your
application may run for a while (or even forever!) without any problem even if
you don't use $M+, so this is a particularly insidious problem. One sure
symptom of a program that wasn't generated with $M+ is a scroll arrow which,
when the mouse button is held down in the arrow, scrolls once, unhighlights the
arrow, and stops scrolling. (I'll bet at least one of you out there just said
"Aha!"...)
Software Supplement info...Here's the scoop on the Macintosh Software
Supplement. When you buy the supplement ($100 from Apple Computer, 467
Saratoga Ave, Suite 621, San Jose, CA 95129) you get three MacStuff disks
(Macintosh-based utilities, examples, and debuggers), and five MacSupplement
disks (Lisa-based tools, examples, Pascal interfaces, and assembly language
equates). You also get updates to both the supplement and Inside Macintosh,
and a copy of the final Inside Macintosh when it's published next year (if you
also bought Inside Macintosh). The most recent supplement update is dated
July, and it's the first version that had eight disks (the previous releases
had less).
"My code generator is broken"...has become a common complaint on the ol' Tech
Support phone lines. I think we've answered this one about a thousand times
already, but just in case you haven't heard: the replacement compiler,
generator, and linker that we send on the Software Supplement try to be real
nice and talk to each other about errors that occur in the development cycle.
For example, if you get an error when compiling, then press "E" to go to the
editor, the compiler writes a communication file (COMMFILE.TEXT) to the disk
and expects the editor to read it. Unfortunately, the present editor is
dumb...it doesn't look for COMMFILE.TEXT. So, the next time you run the
generator, it reads the commfile, doesn't understand it, and refuses to play.
The fix: delete COMMFILE.TEXT, and don't press "E" when you get a compile error
(it doesn't work yet anyway).
Pascal routines passed by pointer (@)...are used in lots of places in the
Macintosh Toolbox: controls' action procs, dialogs' useritems and filter
procs, and so on. These routines must be declared at the highest lexical level
in the source; that is, they cannot be declared within other procedures or
functions, as in this example:
program certainDeath;
procedure callDialog;
var bo3b : integer;
procedure myFilter (theDialog : DialogPtr; var theEvent : EventRecord;
var itemHit : integer) : Boolean;
begin
{body of filter proc}
end; {of myFilter}
begin {procedure callDialog}
ModalDialog (@myFilter, itemHit); <------Ka-boom!
{more statements in callDialog}
end; {of callDialog}
begin {main program}
CallDialog;
end.
This problem occurs because the compiler pushes an extra long word as a static
link when a procedure or function is declared nested. The Toolbox ROM routine
that sets up the stack before calling the Pascal routine doesn't know about
this extra long, of course, so the Pascal routine pulls too many parameters off
the stack and croaks when it tries to return to the ROM (if not sooner).
September's Scientific American magazine...is entirely devoted to computer
software. The issue's first three articles are written by Alan Kay, Niklaus
Wirth, and Larry Tesler. Alan and Larry work at Apple, and you've probably
heard of the other fellow too...
PBGetVInfo...There's a file system trap called GetVolInfo which tells a bunch
of important stuff about a volume, and another called GetVol which returns
information about the default volume. The Pascal covers for file system calls
attach "PB" to the trap name; but if you try that with these two, you get
PBGetVolInfo and PBGetVol, and Pascal only looks at the first eight characters,
making them identical; so the Pascal cover for GetVolInfo is PBGetVInfo. Note
that if you mess up and use PBGetVolInfo, you're gonna get PBGetVol, which has
virtually identical parameters and a similar function but will return
information only about the default volume! Also, please note that the File
Manager manual (page 32) gives the call the wrong name, so you'd better go
correct it right now...I'll wait...
Type coercion...Type coercion is a way of defeating Pascal's strong type
checking conventions by allowing a variable that's declared as one type to be
used as another type. Writing Pascal programs that work with the Macintosh
User Interface Toolbox requires a lot of type coercion; for example, if you
create a StringHandle and want to lock it, you have to coerce it to type
Handle, since the HLock procedure requires its argument to be of type Handle.
Of course, no real conversion is taking place here, since both Handle and
StringHandle have the same internal structure. All you're doing is telling the
compiler "I know what I'm doing --- leave me alone."
Well, the Lisa( Pascal compiler provides a very neat, clean way to accomplish
the necessary coercion. It works like this: any type identifier can be used
like a function call to coerce a variable's type. For example, if you had
declared a variable fred of type StringHandle, you could lock it by writing
Hlock (Handle (fred))
The Handle (fred) business tells the compiler to treat the identifier fred as
if it were of type Handle. Since the format of Handle and StringHandle is the
same, the Hlock works fine. You can use this explicit type coercion feature
anywhere you need to "convert" one type of argument to another. See the File
example for more info.
"254 highlighting" in controls...If you've read the May 30 update of the
Control Manager manual (if you haven't, you should!) you know that it documents
a special way of highlighting controls called "254 highlighting." When a
control's highlight field is set to 254, it will be drawn inactive, but will
still report when the user has hit it. At least, that's what the manual says,
but in reality, the control definition functions for both scroll bars and
buttons have a bug which prevents 254 highlighting from working. There's no
workaround right now.
MoreMasters...It seems like most of you good folks have picked up on this one
already, but it's important enough to say here. A call to the memory manager
procedure MoreMasters at least once at the beginning of your program will help
guard against nasty heap fragmentation. That's because MoreMasters creates a
block of master pointers. A master pointer is used up whenever a new
relocatable memory block (a thing pointed to by a handle) is created. This
happens behind your back a lot, since most objects that the system creates are
relocatable (regions, code segments, controls, etc.). If the system needs a
master pointer and none are free, it calls MoreMasters for you, but if you wait
until the system runs out of free master pointers, the new master pointer block
(a non-relocatable object) will clog up the heap. By forcing more master
pointer blocks to be allocated right after the program starts up, they'll be
low in the heap and will not cause fragmentation. MoreMasters is a procedure
and takes no parameters.
Using pictures...When you create a QuickDraw picture, remember that the state
of the grafPort will be saved when the picture is created and scaled to fit the
new frame when it's drawn. One of the things that's saved is the clipRgn,
which is typically set to "wide-open" (-32767, -32767, 32767, 32767). If you
then try to redraw the picture in a larger frame, the clipRgn will be scaled
"larger" --- which, due to overflow, will turn it into an empty region, thus
clipping out the entire picture! The solution is to set the clipRgn to
something smaller, such as the portBits.Bounds rectangle, at the time the
picture is being recorded.
Double-dereferencing in routine calls...When you make a procedure or function
call with a double-dereferenced handle as an argument, such as
procInOtherSeg (aStrHandle^^); {aStrHandle is a StringHandle}
remember that although you're referencing the string directly, the compiler
always passes objects larger than four bytes by address, not by value, so if
the heap is shuffled by memory allocation (as when a segment is loaded), the
compiler's pointer may be invalid! The moral to this story is: don't use this
construct unless you lock the handle first. A method that's less detrimental
to your heap would be to copy the dereferenced object into a local variable,
then call the procedure with that local.
Using MacNub and DB...If you've been having problems trying to get set up with
the two-Macintosh debugger (MacNub and DB), remember that the cable must run
between port B (the inside port) on both Macintoshes. Port B is the one with
the printer icon on most Macintoshes (all those built since last January). If
you're running from a Lisa to a Macintosh, port B on the Lisa is the outer
port, as marked.
Remember that you can change the printer port with the Printer application,
which comes on MacStuff 1. Just run the application and select the port you
want the printer to use from the menu. The Macintosh will remember your
selection even after it is turned off, thanks to battery-powered parameter RAM.
That's it...our first newsletter! Hope you liked it. If there's anything in
particular you'd like to know about, or some interesting tidbit you've
discovered, please let us know (preferably in writing...we already get about 8
zillion phone calls a day). Watch for us again in a few weeks.
Floating in the Heap, Number 1, September 30, 1984, the newsletter for
Macintosh software developers. Published every so often by Macintosh Technical
Support, 20525 Mariani Ave MS 2-T, Cupertino, CA 95014. Printed by MacWrite
on an insanely great, unannounced Apple printer. Macintosh is a trademark
licensed to Apple Computer, Inc. Lisa is a registered trademark of Apple
-------