MacHack 87
Volume Number: 3
Issue Number: 8
Column Tag: Conference Report
MacHack '87 
By David A. Feldt
There were twice as many attendees as last year and things were generally more
professional, but the untamed spirit of the original MacHack remained strong. Some of
the best Macintosh programmers like Darin Adler of Icom Simulations and Lutus
Langens of Ann Arbor Softworks were there, as well as interesting and influential folks
like Doug Clapp (MacUser columnist), David Smith (MacTutor editor), and David
Lingwood (Apple Programmers and Developers Association Executive Director ). The
conference was sponsored by the MacTechnics users group, The University of Michigan
School of Education, and Broadacre Network. MacTutor, Odesta, Kinko’s Copies, Rent a
Byte, and Apple Computer also provided important material support. MacHack
provided many opportunities to talk to other Mac programmers and exchange ideas.
Several jobs were offered during the conference and a few unreleased products
benefited from algorithms and data structures gleaned from code bashing sessions and
presentations.
My impressions and recollections of the conference, which are necessarily biased
by which sessions I attended and my own strong personal opinions follow. I will
present events in approximate chronological order and summarize some of the most
important things to emerge from the conference at the end of this article. I would like
to thank Doug Houseman of Small Systems Guild and Aimee Moran and Carol Lynn of
Expotech for their professional and often extraordinary efforts towards making
MacHack 87 a success. I also want to thank Scott Boyd of the MacHax™ group for
allowing me to incorporate some of the contents of his conference description which
appeared on ARPAnet the week after the conference.
Pre-conference Workshop
The week began Monday, June 8th with a two day pre-conference workshop on
Macintosh programming. The plan was to provide new and moderately skilled
Macintosh programmers with an overview of the organization and interactions of most
ROM Toolbox Managers. This required that the philosophy, data structures, routines,
and calling sequences for twenty some major topics be explored in 12-13 hours of
presentation time. The best way to insure the workshops success would have been to
have David Wilson, the instructor and creator of Apple’s Macintosh Programming
Seminar series, serve as instructor. Unfortunately David Wilson had a schedule
conflict, and the best chance for making the workshop worthwhile seemed to require a
practiced presenter and a lot of handouts and sample code.
Since I first took Wilson’s course in 1985 I have taught a similar introduction to
Mac programming in the Ann Arbor area, mostly to people from the University of
Michigan or MacTechnics members. We decided to update the course handouts,
resulting in about 300 pages of material, and to fit three days of instruction into two
days by eliminating all labs and hands on activities. This necessarily limited the
usefulness of the material to those attending, but the idea was to give programmers a
broad understanding of the techniques and issues surrounding Macintosh programming.
To that extent the course succeeded, but I lost my voice and virtually every workshop
evaluation form called for more time and labs. There were also a few glazed eyes
among those attending, but Mac programming can be a little overwhelming at times.
See figure 1, pre-workshop experience.
Forty seven people attended the workshop, and all 50 copies of the course
materials were distributed. The workshop was video taped, and if the 12 hours of
material can be edited into something useful it or a transcript will be made available to
those interested.
Strong demand for a low cost Mac programming class which parallels Apple’s
seminars has been established. The MacHack steering committee has asked for several
quarterly three day Macintosh Programmer Training workshops to be held in
September, January, April, and before MacHack 88 in June. They also requested that
the cost be kept below $300, substantially less than the $1000 that Apple charges,
and a language independent approach will be maintained. David Wilson and David Feldt
will again be invited to participate.
Startup address
Doug Clapp writes a column for MacUser and is a well known Macintosh
commentator and author. Clapp had many things to say, but a few of them made a lasting
impression on many of those attending and set a tone which carried across the
remainder of the conference. He talked about programmers designing software for the
journalists instead of users, emphasizing features that make good ad copy and
comparison charts but provided little or no utility for the user. Clapp suggested
several ways computers were being used to address problems like world hunger, and
challenged programmers to look for ways that they can make positive contributions
whose value is not necessarily measured in dollars.
Clapp also talked about how he became a writer and about the MacBots project. In
reference to his predictions about the potential for the microcomputer revolution
Clapp said; “I thought that when computers were available to new, creative
individuals we would see new insights and solutions to world problems. Instead we
mostly seem to have a lot of public domain and shareware disk utilities.”
Doug Clapp stayed for the entire conference, and at several points exclaimed to
others; “It may seem strange, but I’m really having fun. Really!” We were all
impressed by Clapp, and are wondering if other columnists might also be such nice
people? I’m looking forward to seeing what the slick paper Macintosh press has to say
about hard core Macintosh programmers assembled in large numbers and high
densities.
ROM versions
This session was intended to be a panel of Mac developers and Apple reps
discussing how to achieve application compatibility between 64K, 128K, 162K (Mac
SE), and 256K ROMs. With help from a few knowledgeable individuals in the audience
we discussed the implications of Apple Tech Note #117 (the one with all the “Thou
shalt nots”) and Apple’s official compatibility guidelines.
Several specific steps were offered which could help application developers deal
with the compatibility problem. These ideas included:
• Write ValidPointer() and ValidHandle() routines to check pointers and handles
for reasonability before passing them to a ROM routine. Pointers are reasonable
if they aren’t NULL and point below the top of physical memory. Handles are
reasonable if they are valid pointers and point to valid pointers, (in addition the
most significant byte of a master pointer may have bits set which must be
ignored when testing validity). A code sample of how to do this is given below:
/* Lightspeed C 2.01 source, based on the ValidPointer(), and
Valid handle() routines in the Programmers Extender Vol 1 by Invention
Software Inc. (Note that comments are edited for publication, and
multi-line comments are not LSC compatible.) */
Boolean ValidPointer(P)
Ptr P;
{
if ((P == NULL) || ((long)P & 1L))
/* if pointer is NULL or odd */
return(FALSE); /* then pointer is definitely bad! */
/* In my opinion test for null should be ommitted, indexing into an
array of characters (bytes) could result in a valid pointer to an odd
address */
/* another test which should be added here is a check to see that the
pointer is not above the tom of RAM, but MemTop() does not return the
correct value when running under switcher or servant. */
else
return(TRUE); /* else pointer is potentially valid*/
}
Boolean ValidHandle(H)
Handle H;
{
Ptr P;
if (ValidPointer((Ptr)H)) {
/* the handle dereferenced is OK */
P = (Ptr)((long)(*H) & 0x00FFFFFF);
/* mask off the master pointer status bits */
if (ValidPointer((Ptr)P))
/* the pointer pointed to is OK */
return(TRUE);
/* then Handle is potentially valid */
}
return(FALSE); /* Handle doesn’t point to a pointer */
}
• Use CurrentResFile(), Environ(), and other ROM routines to get information for
an environment data structure which stores information on the applications own
resource fork path reference, Macintosh model, ROM version, top of memory,
CPU, math coprocessor, etc. Use this information in determining which ROM
calls to use to accomplish a task or alternately to disable program features which
cannot work on older ROM machines while leaving users access to those that will
work.
[Note: In MacTutor’s opinion, it is not necessary or desirable to extend this
compatibility to 64K ROMS, as Joel West’s article in this issue makes clear. -Ed]
• Sacrifice speed and elegance for compatibility. Most of the application developers
who have run into trouble got there because they knew a better way and didn’t
want to be limited by the ROM. These folks have been plagued by incompatibility
and user complaints whenever Apple introduces a new machine while those with
greater dependance on the ROM have witnessed their programs grow steadily
faster and smoother as Apple has improved the quality of the ROM code.
• Use GetWMgrPort() to reference into the screen bitmap record to determine
screen size at runtime. This is equivalent to using the screenbits.bounds
rectangle, but works from within code resources and desk accessories where no
global variables are accessible.
• Think about not covering up the 40-50 pixels along the right edge of the screen
with windows, icon pallets, etc. to allow the Finder’s disk icons, trash can, etc. to
show through when an unannounced enhancement to the Finder makes such things
possible.
At the same time a session was taking place where a heated discussion of MacApp,
Macintosh Programmers Workshop, and other topics was fielded by Jordan Mattson of
Apple, Leonard Rosenthal of Davka, David Smith of MacTutor, and Rick Thomas of
Personal Bibliographic Software. Since the conference was attended by mostly
full-time developers, the concerns voiced reflected many of the problems experienced
in the day-to-day process of getting ideas out of programmers heads and into Macintosh
programs. The session quickly moved from discussion of the available tools and
environments to the problems developers have with the tools, and general Apple