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 Validhandle() 
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)
PtrP;
{
 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.

Tools

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 bashing.

It became apparent that MPW is widely used, and as with most development tools, a love/hate relationship exists. Many of the comments involved improvements to MPW. Other comments focused on how to improve the working relationship between developers and Apple’s tech support and system software people. Apple’s only representative at the conference, Jordan Mattson, took careful notes and suggested that an official “Bash Apple Session” on the final day of the conference might provide a better forum for such discussion. The proposal was well received and the session scheduled for 9 AM Friday morning. Mattson displayed quantities of energy, listening, and leadership skills equivalent to several people. His presence at MacHack was so professional and skilled that several conference evaluations indicated that many attendees believed that there were many, not one, Apple representative. We all hope that Apple appreciates this guy.

Wednesday afternoon

The first of the lunches was all right, and most folks fears about the quality and quantity of food were put to rest for the remainder of the conference. Sessions on Marketing aspects where David Lingwood of APDA showed how to prepare a marketing segmentation and marketing plan, Languages, and several case studies went well, but the most interesting and controversial session of the afternoon was clearly Debugging with Steve Jasik of MacNosy fame and Paul Snively of Icom Simulations (TMON). Some said it was a big Nosy commercial, some complained because the session didn’t last longer, others said Paul told them more about TMON than they wanted to hear, but virtually all attendees managed to get themselves worked up about one thing or another.

TMON case study

Waldemar Horwat, the principle author of TMON, presented the TMON Case Study. He was accompanied by Darin Adler, the author of the popular Extended User Area. Paul Snively rounded out the group. Waldemar related some fascinating things about the development of TMON. For instance, he wrote the entire program in assembler on the Lisa. That is to say that he wrote the entire program before he assembled it even once. After every assembly, he advanced the version number. Another interesting fact is that Waldemar was fourteen when he started coding TMON!

The Ann Arbor Softworks party

(Hacker’s version of one-upsmanship)

My vote for funniest hack of the conference goes to some guys from Texas who created a special application with a silver surfer icon and tucked it away in an obscure folder on one of the accessible hard disks. The first to bite were a few ace Mac programmers at Ann Arbor Softwork’s hackers-only party Wednesday night. When launched, the nefarious app would come up with the non-disclosure do not distribute dialog of the real beta Silver Surfer and wait for a mouse down event. No matter where the user clicked, the app would beep three times and put up an alert saying “You didn’t click in the secret spot”. The obvious response to such security measures was TMON! A few minutes later when no rectangles or regions as target areas could be found a second ace Mac programmer was called in. “What if they patched SysBeep()?” he mused. Of course! Sysbeep()! And it turned out that SysBeep() had indeed been patched, plots within plots! It wasn’t until the number of code segments (2) and the size of the app (14K) were consulted that the truth was revealed. The real silver surfer (AKA 4th Dimension) is about 642K. “It’s a hoax! It’s just a hoax!” and poorly stifled laughter were heard for some number of minutes thereafter. During the following days a few other folks who probably should have known better stayed up until 4 AM attempting the same access, but without as appreciative an audience.

4th Dimension database

The author of this article, still hoarse from the pre-conference workshop, presented a two hour overview of the latest high end Macintosh database management system, 4th Dimension. This product is being brought to market by ACIUS (the company Guy Kawasaki and Scott Knaster quit Apple to run) after several years of successful use in Europe and over a year of Apple supported enhancements. The idea presented was that most Macintosh developers would be better off with such a high level development tool and less knowledge of the ROM. This point was hotly debated, as were many of the user interface and implementation decisions of 4th Dimension’s designers. The audience reactions ranged from religious ecstasy to claims that 4D was clearly the most over-hyped product of the year. 4D is an important and complex product which cannot be fully described or appreciated in a period of a few hours, but it was generally agreed that it and enhancements to Helix and Omnis 3 were broadening the tools and options available to Macintosh application developers.

The 4D presentation was followed by a Battle of the Databases panel including Daniel Chiefetz who is the President of Odesta (Helix), David Feldt for ACIUS (4th Dimension), and Tom Gottenheimer for Blythe (Omnis 3+). The comments were basically cordial and positive, but issues of technical support, warrantied performance of development tools, and open disclosure of known bugs elicited some strong opinions from panelists and the audience. Of particular interest to me were the description of a Helix access protocol which would allow microcomputer front ends to communicate with a variety of database back ends over AppleTalk, Ethernet, and other communications media. The evolution of such protocols offers a promise of flexibility and compatibility for all developers while at the same time opening the floodgates of Mac to mainframe communication between information interfaces and servers.

The idea of a bulletin board or computer conferencing system with which developers could communicate and exchange bugs, hints, source code and other information had already been discussed at several previous sessions, but the need and possible structure for such a system crystallized and gained momentum during the discussions arising from this panel. Possible roles for Apple, APDA, and development system vendors such as database and compiler companies were explored, and several individuals such as Jordan Mattson of Apple and David Lingwood of APDA indicated a willingness to work towards a concrete proposal. More on this important topic below.

Bash Apple session

A special ‘What could Apple do better or differently’ session was held bright and early Friday morning. Decorum was maintained by a combination of media intimidation (the session as videotaped for later viewing by Apple) and a moderator wielded baseball bat. I have rarely seen as well behaved a group of Macintosh developers, but important problems and issues came out none the less. The session began with Jordan Mattson of Apple explaining the structure of the developer products group and a few issues he felt were key to Macintosh developers success.

Jordan Mattson (Apple): “Be internationally compatible... I think we have the best software in the world right now. We have an opportunity to go into other countries and sell that software... There is an enormous marketplace there, the trouble is we get fat and sassy. We think we have the solution, we have good stuff, but we don’t go the extra step... Right now we have the best software in the world, but at one time we had the best machine tools in the world, and the best automobiles in the world.”

The issue of quality, on time documentation available at the same time as new development tools was mentioned, and Apples commitment to doubling the size of the Developers Tools group discussed.

Darin Adler (ICOM): “There seems to be a rather informal formula for deciding what kinds of information developers need and what kinds they don’t. I think you need to think more carefully about those decisions.”

David Feldman (ICOM): “Will you (Developers Tools group) act as a court of appeals? Right now we have a problem... If tech support decides not to give a certain piece of information out your kind of stuck.”

Frank Alviani (Odesta): “We live in an uncertain kind of world all the time. Getting tech notes saying ‘Hi! Everything you are doing is about to become illegal is very disturbing. If we were able to be not just in a reactive mode, but in a corrective mode...”

(Feedback before a decision is made, not afterwards)

Jordan Mattson (Apple): “We came up with an idea... to establish a bulletin board or conferencing system where we could have discussions like that. How many people would be interested in such a system?” (Virtually every hand in the room went up). “How many people think that it would be useful and improve the quality of the Macintosh ROM?” (Every hand in the room was raised).

Darin Adler (ICOM): “I have to say that I’m not all that unhappy with the way technical support has been handling things. Unfortunately the kinds of bugs that developers are likely to find require a two way communication and a simple bug report form is able to obscure what is actually there. An engineer will look at it, think that he understands, and say ‘This isn’t really a bug’. I find this happens particularly with the kind of bug a developer finds in a piece of software as opposed to the kind a user finds in a piece of software.

“I would say that the current bug reporting scheme is totally inadequate. If someone at Apple finds a bug it will be corrected because there was two way communication, and when somebody outside the company reports a bug there is a lower chance it will be fixed. Maybe this whole idea of a bulletin board and better communications can be used to address that.”

David Lingwood (APDA): “I named APDA, against the other possible choice which was the Apple Programmers Club, very purposefully. An association pushing for professionalism, and we clearly want to be more than just a distribution house for Apple Computer... The kinds of things your talking about here, developing a professional communications network are the reason I got involved with APDA in the first place. We want to be closely involved in all this development... You folks are on the firing lines and know a lot more about these products than we do. Unfortunately we don’t do technical support for MPW. Unfortunately nobody does technical support for MPW. This is something we and Apple will have to talk about.”

Other important issues were discussed, but the consensus of the group was that an electronic conferencing system allowing Apple and Macintosh developers to engage in a two way dialog on bugs, compatibility issues, system software, and other topics would be of major value. Jordan Mattson proposed a core group of three to make sure that progress was made on this proposal. For further information or to volunteer to help with this important project contact one of the following individuals;

Jordan Mattson, Apple Computer Inc, 20525 Mariani Avenue, MS: 27S, Cupertino, CA 95014 (408) 973-4601 (AppleLink: Mattson1)

David Lingwood, Apple Programmers and Developers Association, 290 SW 43rd St., Renton, WA 98055 (206) 251-6548 (APDA, attention David Lingwood)

David Feldt, Broadacre Network Inc, 24 Frank Lloyd Wright drive, Ann Arbor, MI 48105 (313) 662-3000 (AppleLink: V0218)

The videotape of the session has been sent to Cupertino, where some of the Apple folks will have a chance to hear from MacHack developers first hand.

Third party libraries

Friday, the afternoon of the fifth day for twenty or so of these die hard programmers attendees were still hungry for more. I was unable to attend concurrent sessions on CD/ROM Publishing and Doug Clapp’s MacBots Roundtable due to participation in the libraries session.

Jack Juni of Invention Software lead off the session by discussing some of the implementation decisions facing Macintosh library designers. He contrasted the Programmers Extender and MacExpress implementation and usage, explaining the Extender WData and EventStuff data structures to illustrate various points along the way. The WData record is a relocate data structure whose handle is stored in the RefCon field of a window record. It contains fields for horizontal and vertical scroll bars, pictures, TextEdit records, list manager lists and other potential window contents. By using the information in the WData record the Extender library is able to completely process the majority of events, providing automatic dragging, resizing, scrolling, updating, and editing of multiple windows.

Juni also described mechanisms for allowing programmers to selectively turn off automatic event processing for specific windows, how the Extender’s HandleEvent() routine reports back information to the program via the EventStuff record, and Extender Volume 2 support for custom list defProcs for lists of pictures, icons, and other types. He closed by contrasting the development time for software written with and without third party libraries, concluding that learning, development, debugging, and maintenance costs were all reduced by quality libraries and programming tools.

Friday evening debriefing

An informal conference debriefing took place for Friday evening for those who just had to get it out of their systems. Several suggestions for next years conference were made. Among the most interesting were;

• Sessions shouldn’t start earlier than 10:00 am. (Programmers are night people!) Evening sessions should be added.

• All sessions should be videotaped for later viewing or reference.

• More time needed between sessions, allowing for informal chats and session overrun

• Special sessions for developers under non-disclosure for unannounced products

• Improve support and representation from Apple and other vendors

• Larger machine room, greater participation from women, handicapped and minorities

Awards

The group of twenty or so voted a set of informal awards, with the intention of making them a part of next years conference. The Vaporware award went to FullWrite Professional (“Don’t buy it, cause you can’t!”).

The WordStar user interface award went to Microsoft Word 3.0; (supply your own reasons).

The Pinstripe award for sharpest threads went to Andrew Simms of MacTechnics, while The Kickback award for most casual dress went to both David Feldt and John Allegre, who both made sure formality at the conference was kept in check.

The International award for coming the furthest went to Johan Samuelson of Sweden, the Apple Basher award to Steve Jasik of MacNosy fame, and the Silver Plated Surfer award to Darin Adler and Lutus Langens.

At 10 PM Jordan Mattson was still going strong, assigning a committee to prepare VAX based hardware proposals for the developers conferencing system and fielding questions from the final few. The beer was gone, it had been a long week, and I was supposed to drive Jordan to the airport at approximately six the following morning so I wandered back to my house with a couple of other MacHackers who refused to let it end and we watched the video tape of the mornings Apple Bash while working up some quick and dirty VAX/VMS configurations. Some things just refuse to die, and MacHack proved it was certainly one of them.

MacHax best Hack awards

What’s a hackers’ conference without a forum for good hacks? In the spirit of quick and dirty or simply fun little programs, The MacHax Group sponsored the First Annual MacHack Hack Contest. After hours of careful consideration, the following hacks were selected. All winners received the praise and adulation of untold multitudes of sentients.

From Fritz Anderson came HeapInit, an INIT and CDEV pair which permit you to resize your system heap. It comes complete with source code and all necessary documentation. Since he hijacked INIT 31, he also rewrote INIT 31 in C so Apple couldn’t complain. Looking at the modification dates on his files, it was obvious that Fritz lost some serious sleep over this hack. This is a timely and useful contribution and should hit the networks for downloading asap.

From Paul Snively comes SetPaths. Now, many of you have probably seen this one already. In case you haven’t, SetPaths lets you specify your Poor Man’s Search Path (PMSP). The PMSP is the set of directories your Mac looks through when asked to find a file without specifying a path name. Had Paul known about the contest beforehand, he would have certainly held back on its release till MacHack. So, to be fair, the MacHax folks permitted its entry. Now not everything has to go in the System folder!

Darin Adler, Mitch Adler, Leonard Rosenthal, and Paul Snively created an interesting category with “The Best Hack Implemented in a Nonexistant Product.” It’s simply a small hack that speaks numbers. For example, Macintalk says 1004 as “one, zero, zero, four.” Aesthetics repugnant!. Their hack instead says “one thousand four.” It can handle numbers so absurdly large that it’s quite humorous. They were planning to teach it to say really big numbers like 12443987598745987, 345,983,498,234,897,234 as “twelve grillion and change...”

Mother Nature and NASA won an overwhelming vote for power hack when television and newspapers reported they had jointly launched three missiles due to an unscheduled but highly effective lightning strike.

Conference evaluations

Most attendees heard about MacHack through MacTutor, MacTechnics (Ann Arbor’s 650 member Mac users group), or through the grapevine. In this case the grapevine seemed to consist of equal parts telecommunications and word of mouth. There were many suggestions for possible improvments, but 97% of those completing evaluations indicated their intention to return next year. See figure 2 below.

Other trends which emerge from these evaluation responses indicate that one third of attendees would like more technical material, that the conference facilities would be acceptable for use again next year, and that more information on programming Mac IIs would be appropriate. Comments contained three recurring topics, scheduling conflicts between sessions, the need for a larger machine room, and better organization of moderators and equipment.

In both conference content and opportunity to establish personal contacts with other programmers and developers MacHack was a success, but the ideas and energy generated this time around should insure an even better conference next year. Abstracts should be submitted to Macintosh Technical Conference (MacHack 88), ExpoTech, Inc., 1264 Bedford Rd., Grosse Pointe Park, MI 48230 no later than October 1st, 1987. For further information about next years event watch the pages of APDAlog and MacTutor, or call ExpoTech at (313) 882-1824.