Labels, Corrections, Book Reviews & Update List

Hot Air: The Editor's ViewPoint

Why Macintosh is Not a Business Computer

The Macintosh is a manager's computer. It was designed by middle managers, for other middle managers. It functions best in an environment where a large amount of numbers must be tracked and sorted in a spreadsheet with Excel or, for more technical needs, TK! Solver, plotted with Chart, pasted into reports with Word or MacWrite, and typeset for presentation with Pagemaker, MacPublisher or Ready-Set-Go. Where the data comes from is not the concern of the middle manager. He is only interested in making sense of the information, and in that, the Macintosh, with it's user interface and What-You-See-Is-What-You-Get graphics is unsurpassed. I myself have used the Mac this way while working for Hughes Aircraft. I took transistor test data from the integrated circuit production line and extracted modeling parameters with TK! Solver, plotted trend lines with Chart, and reported on production control versus IC performance with MacWrite and Pagemaker. A typical middle manager's job. But this has nothing to do with running a small business.

To run a small business, you need to be concerned with more mundane things in life. Like entering a customer order, printing an invoice and packing slip, notifying the customer that the red widget will ship this week, the blue widget is backordered until next month, and the yellow widget will ship a week from Tuesday. Then you have to make sure the shipping department gets all that straight! There is no Mac software presently on the market that can adequately keep track of the three widgets from the order entry clerk to the shipping clerk, invoice, packing slip, and all! That application needs the now infamous file server product that Apple never figured out how to make.

One of the things you need to keep track of widget shipping and customer orders is plenty of disk storage with daily back-up. Presently there are few hard disks on the market that meet this need. First of all, you need a SCSI drive that is reliable. And all the SCSI drive manufacturers are too busy debugging Apple's software drivers, and issuing weekly file system software upgrades to take time out to sell their products. However, two drives which may be worth while when the software settles (I advise waiting at least three months), are the AST drive on the high end and the LoDown drive on the bottom end. Both are SCSI drives, with tape back-up capability. The LoDown drive comes in 20, 40 and 80 megabytes with tape units in 20 or 60 megabyte units and the prices are very reasonable. Contact them at (415) 426-1747. The AST drive is a cadallac unit of 75 megabytes and a built-in tape unit. But it's not cheap! Contact them at (714) 863-1333.The Apple drive, and other internal drives like the Micah and Hyperdrive are great for those middle managers we talked about, but no businessman is going to be fool enough to put his customer base, the lifeblood of his business, on an internal drive without back-up and throw the Mac into the car! No, a hard disk needs to be gently laid to rest in a quiet corner of the office, protected from earthquake, flood, fire and small children. And backed up daily. Apple's hard disk product doesn't cut it for this type of use.

But does it do labels?

But enough of all this. Let's take an even more mundane and simple example. The most basic need of any business is to print out a mailing label. This the Macintosh cannot do. The Mac can print in any font, style, size. It can include graphics, produce typeset quality output, you name it. This entire issue of MacTutor was printed on the Mac! But it can't print four lines of simple text, hour after hour. And who can run a small business without mailing labels? Let's look at this example in depth. First you need a printer. Apple doesn't have one. The Imagewriter printer had no tractors to handle the labels correctly without jamming. Every month, we had to dig at least one label out of the inner workings of the thing. They didn't even have the decency to design the roller so that it could be removed for gummed up label removal! The best tool for the job turns out to be one of those flexible nail files your secretary probably has in her purse.

The Imagewriter II has made a small attempt to improve the situation. It has what might be described as micky-mouse tractors. They are at least better than nothing! But the labels still must pass around the roller, which causes them to peel. And worse of all, the metal band that holds the paper against the roller is so tight that it is impossible for the labels to back up out of the printer. Thus the only way to remove the labels when your done is to do it surgically by cutting the labels below the print head, and moving the labels forward.

That leaves the Laserwriter, which isn't worth mentioning because it can't do labels without manual feed. And even if you could find labels that would feed from the tray, you would waste half the labels since all the Mac software available only prints labels one up if they print labels at all. But even in manual feed, the labels sometimes jam up under the rollers that heat-set the toner to the paper. And a gummed up LaserWriter is of much more concern than an imagewriter! I've had it happen just enough to know never to try to do labels on the one piece of equipment that MacTutor cannot do without.

So let's ignore the hardware problem for the moment. What application do you use? The first program was Mail Manager, written by some guy in Germany and distributed by SofTech. The problem is, the guy wrote software for the Mac like it was an Apple II. He ignored the toolbox guidelines, coded specific machine dependent routines so that the program needed an update to run on the 512K Macs, and then another update to run on the Mac Plus. Well, SofTech managed to get the 512K Mac upgrade out as version 1.1, but by the time of the Mac Plus, SofTech had gone out of business, so goodby future upgrades! The product won't work on HFS systems, and is frustrating in its design anyway.

The other mail list program is Bulk Mailer. While this seems at least workable, it too suffers from a frustrating lack of flexibility that makes it a poor choice. No, the only real solution is a data base program. But none of them do labels correctly. And none of them do anything other than one up labels. Still, FileMaker is without question the best data base program on the market, so we went with that one. It is easy to use, works reliably with the LaserWriter and Mac Plus and doesn't require you to learn reformed Egytptian! FileMaker follows the Apple guidelines to the letter, which when it comes to labels, brings us to the print driver problem.

My Kingdom for a Printer Driver!

It is obvious the Mac was designed to print term papers, not mailing labels. When a print file is opened, quickdraw commands entered, and the file then closed, the Mac supposedly composes and prints the desired page. In other words, printing on the Mac is page oriented. Someone along the way decided that after a page is printed, the next page should be brought up ready to print, so someone in the bowls of the ROM issues a page break. On the imagewriter, this advances the paper to the top of the next page. But when you do labels, you don't want a page advance. So, in the new imagewriter drivers, someone put a check box to turn off the page break. Ever watch the imagewriter print? It goes ahead and does the page break anyway and then finds the no page break box checked, so it backs up to the top of the page. But you can't back up mailing labels in the imagewriter without inviting a jam eventually. Catch-22!

Of course the answer is that Apple simply does not make a business printer. The imagewriter is only good for a base for the thunderscan device and the LaserWriter is a superb but expensive typesetter. Apple has no mundane business printer. So the solution is to buy another printer, like a NEC 8810 or some other letter quality printer with large, reliable tractors, and bottom feed that moves the labels in a straight line past the print head. But how do you get it to talk to the Macintosh? Assimilation Process produces a printer driver modification called the Daisy Wheel Connection that patches the Imagewriter file to work with various business printers. But what do you suppose happens when the Imagewriter driver front end does it's silly page break, back-up routine? Of course the command to back-up the imagewriter is not the same command to back-up anybody else's printer, and the result is the page break is inserted into the middle of your label printing causing the label alignment to get off. I have found that when using Filemaker, the only solution is to not check the no page break box at all. Then, if you use 1.5 inch labels, and select international fanfold, behold, like magic, you get a page break exactly equal to the width of a single label, allowing you to print labels correctly, as long as you don't mind getting seven labels and one blank label per page. A mere waste of 12% of your labels! And such is how this issue of MacTutor was mailed. I rest my case. The Macintosh can't print labels. And if it can't do the most mundane of all business tasks, it can hardly be called a business computer. But I'm sure it will do a great job of preparing a report for the Editorial board on how much time and money I've spent trying to get labels printed this month!

The MacTutor Solution

The real solution lies in alternative print drivers. What we need is a variety of print drivers that can be installed from the Chooser desk accessory that can handle a variety of printing needs. When you need mailing labels, you select a label driver that prints labels in draft mode correctly without this page break nonsense. When you do typesetting, you select the LaserWriter driver. When you need some other type of printing, you select the driver best suited for the application. In otherwords, the imagewriter driver cannot be all things to all people. MacTutor is very interested in publishing alternative printer drivers and we invite software developers to help us open up this last great Mac secret by helping us publish more information on how print drivers can be constructed that for one thing, will do some of the more simple mundane things a business needs, like printing mailing labels. That's our opinion. We welcome yours. Write to Letters to the Editor Dept., care of MacTutor, P.O. Box 846, Placentia, CA. 92670.

Letters

Clock DA source correction

Don Melton

For those of you typing in the Clock DA I wrote for the April 1986 issue of MacTutor, be warned, there is a typo in the magazine source listing. It's my fault, not David Smith's -- probably my old brain tumor acting up again. Thanks go to MacScotty of the MouseHole BBS for finding this error. Turn to page 46, and in the 'open' function you'll find it also. Here's the problem line and the correction:

INCORRECT SOURCE:

 drvrID = 0xC000 - (32 * (1 + dce->dCtlRefNum));

CORRECT SOURCE:

 ownedID = 0xC000 - (32 * (1 + dce->dCtlRefNum));

It seems I accidently used an older variable name from a previous version of my source code. This mistake does NOT appear on the source code disk available from MacTutor.

There is also a non-destructive typo later in the same source. It does not cause errors but I thought you all might want to know about it anyway. Thanks go to Katz of the MouseHole BBS for pointing out this one. Turn to page 48, and in the 'doMenu' function you'll find these four lines:

QUESTIONABLE SOURCE:

 dce->dCtlFlags &= 0xFBFF; /* clear dCtlEnable */
 dce->dCtlFlags ^= 0x4000; /* set dNeedLock */
 :
 dce->dCtlFlags ^= 0x4000; /* set dCtlEnable */
 dce->dCtlFlags &= 0xFBFF; /* clear dNeedLock */

BETTER SOURCE:

 dce->dCtlFlags &= 0xFBFF; /* clear dCtlEnable */
 dce->dCtlFlags |= 0x4000; /* set dNeedLock */
 :
 dce->dCtlFlags |= 0x4000; /* set dCtlEnable */
 dce->dCtlFlags &= 0xFBFF; /* clear dNeedLock */

BEST SOURCE (but be careful using it):

 dce->dCtlFlags ^= 0x4400;
 /* clear dCtlEnable and set dNeedLock*/
 :
 dce->dCtlFlags ^= 0x4400;
 /* set dCtlEnable and clear dNeedLock*/

I accidently typed an XOR to manipulate the dNeedLock bit instead of an ordinary OR. An XOR works but it is not what I intended. Of course, as the 'BEST' example shows, you can manipulate both bits with an XOR. However, I did not include this example in the original source because I thought it might be confusing.

Please pass this information on to your local BBS. And feel free to ask me any questions about the Clock DA or the DA Header source via MacTutor, Compuserve (74166,1006) or Delphi (DONMELTON). Thanks.

Ask Prof. Mac Correction for April

Steve Brecher

Please note an error on page 62 in the April 1986 issue of MacTutor (volume 2 number 4) in the example of using JIODone. After testing the "noQueueBit", the next instruction says "Beq.S @0". This is incorrect. It should be "Bne.S @0" instead. If this bit is set, then the branch will be taken and the rest of the code implemented, which is what we want for a "no queued" item. For queued items, the branch will not be taken, and we will exit through JIODone.

Asm Lab Comments for April

Norman Braskat

Thanks Dave for the Mac C (version 4.53); the built-in assembler works like a champ (Apple MDS really sucks). About the DA example in my Asm Lab article in the April 1986 issue of MacTutor, I recommend placing the save and restore graph port trap calls in the launch routine. This not only saves code, but saves and restores the current port during control calls. The other question I have concerns the set port after the beginUpdate call; Dan Weston's new book [see book review, this issue -Ed] shows it outside the update loop for an application, and inside the loop for a desk accessory as you placed it in my DA example on page 37 of the April issue. I think your way works because the current port is the same as the DA's window. But if we had multiple windows in a DA or we added a menu for clearing a window which was not currently selected, we would be changing the port during an update. Would this then be a problem?

Dave, you have a great publication and the only real source of assembly info around! Keep it up. PS. Your right... Dan's book is a real winner! [The Complete Book of Assembly Language Programming by Dan Weston, published by Scott Foresman & Co. due in bookstores next month. -Ed]

HD-20 Problems

Richard Emerson

I have been plagued with all manner of problems when I recently tried to assemble and link Chris Yerga's Icon Converter program. At the completion of the link, my HD-20 Finder (5.1) died with an ID=02 bomb, examining and editing the ICN# resource caused another crash, and attempting to copy the application from an HFS disk to an MFS disk caused a massive failure of the Mac! (To add insult to injury, the program performs rather nicely save for some minor problems with the new HFS Get and Put dialogs - not Yerga's doing.)

Repairing the HD-20

As to repairing the damaged Desktop, the solution is disturbingly simple. All that is needed is to hook the HD-20 to a MacPlus and hold down the TAB, command and option keys while waiting for the Mac to boot up. The first dialog asks if the disk should be initialized. After pressing the cancel button on that dialog, the "Rebuild the desktop" dialog comes up. Press OK and the disk thrashes around for a while and then settles down to a bare desktop save for the trashcan and the HD-20 icon. Double clicking the HD-20 produces an alert to the effect that there is not enough memory to open the folder! After punching the OK button (no other choice) and doing a shutdown, the desktop is back to the state of an HD-20 icon and trashcan. Double clicking the HD-20 this time produces the expected window and life is back to some manner of normalcy. This same cycle, attempted on a 512K Mac does not happen. The attempt to rebuild the Desktop is rebuffed with an ID=02 bomb alert. Obviously the new ROM's include a fix or improvement which by-passes an older problem. It should be noted that this repair process on the Mac Plus works with no diskette in any drives; the code either comes from the ROM's or from the (damaged) HD-20! Moreover, the repairs can be done with either Finder V5.0 or V5.1 on the HD-20. I've enclosed a mailing label and disk for Finder V5.2 and System 3.1.1. Thanks for helping deal with this mystery. [Avoid mixing MFS and HFS volumes, get the new ROM's and latest system software and wait for Apple to figure out how to write a hard disk driver that works! -Ed.]

Desk Accessories Comments

Jan Eugenides

Since writing my article on desk accessories in the March 1986 issue of MacTutor, I've learned a couple of things that should be passed on to your readers.

I stated in the article that by convention, the name of a DA should start with a NUL character (Ascii code zero). This is what Inside Macintosh says on page I-444 of the desk manager manual. However with the new Mac+ system, which displays DA menu items in alphabetical order, I discovered that all my DA's were showing up at the top of the menu. A little poking around revealed that all of Apple's own DA's such as the Control Panel, etc., do not start with a NUL at all. Instead they end with one! Inside Macintosh is wrong on this point.

I failed to make it sufficiently clear what the memory test at the beginning of my DA is for. From the article, it appears as though I am testing to make sure there is enough memory to open the DA. By the time the test is performed, the DA is already resident in memory, so such a test would be superfluous. The idea is to determine if there is enough memory available to open further windows, etc. After some experimentation, I have decided that the memory test at the beginning is uneccessary. It makes more sense to check available memory when you need it, for example before opening a file, or displaying a new window.

More on Jan's DA

Kenneth Bates

I enjoyed the article on desk accessories by Jan Eugenides (March 1986) very much, and have one additional point of information to add which may help others.

Jan mentions (quite properly) that the ID number of a desk accessory may be changed by the Font/DA mover during installation. In addition, he points out that all 'owned' resources of the desk accessory will also be changed. His solution is to access the resources by name (GetNamedResource()).

Although this is certainly possible, there is an easy way to find out exactly what the ID number of the desk accessory is at run time. The device control entry (passed to the DA on entry) has a field named 'dCtlRefNum'. By negating and decrementing this field, the ID of the DA is obtained. As an example:

accopen(dctl, pb)   /* DA Open routine */

dCtlEntry *dctl;
ParamBlockRec  *pb;
 {
 int  id; /* This will be our new ID */

 id=dctl->dCtlRefNum;
 id=-id-1;

Following the execution of this code, variable 'id' will contain the renumbered ID of the desk accessory. From there, it is a small matter to obtain the needed resource. As another example, to get a dialgo which originally had a sub-resource of 2:

mydialog = GetNewDialog(id * 32 -16384 +2, NULL, -1L);

Owned Resoruces with Megamax C

Ronald Parsons

In the March 1986 MacTutor, Jan Eugenides showed a method to handle owned resources in a desk accessory. I have used a variation of that method which is somewhat more general (no resources need be named using ResEdit) and multiple types of resources are supported.

To make creation of DA's easier with Megamax C, I make a copy of the linker, mmlink, re-name it mmlinkDA and use ResEdit to make the default Res Type be DRVR and the default ID be 0031.

Using RMaker, I add a small resource to my DA with an unusual name (I use 'mine' in lower case). I calculate the ID's of all owned resources in the RMaker source asuming an ID of the DA of 31. (See the example code in listing 1 below.)

In the accopen() routine of the desk accessory, I incude the code shown in listing 2. I first make sure there is one and only one resource named 'mine' in the system. For this example, I beep and exit if there is more or less than one. I then get a handle to that resource using getindresource("mine",1). With that handle and the call getresinfo (hndl, &id, &resourtype, &genstr), I get the current ID of the resource "mine" as it has been changed by the Font/DA mover. The ID of the DA DRVR resource can then be calculated by id=(id+16384)/32. This ID can be used in calls using owned resources such as stopalert(-16384+32*id +1, NULL). The resource ID's are thus correctly calculated. With this method I can use many types of resources without having to name each one.

Listing 1

* Tell RMaker what to name the resource file
!DA
DFILDMOV

type mine = GNRL
 ,-15392;; =-16384 + 32*31 + 0; resource ID 0 for DRVR #31
.I
0

Type Alert
 ,-15391(36);; resource ID (SmGenID)  -16384 + 32*31 +1 
260 80 335 430 ;; top left bottom right
-15391  ;;resource ID of item list
4444    ;; stages word in hex

Listing 2

osstr255 genstr; /* General use string */
handle hndl;/* Handle to allocated array */
restype resourtype;/* resource type */
int id, count; /* DA's resource ID, count having type "mine" */

 count = countresources("mine")  /* find DAs res ID */
 if (count !=1 ) {sysbeep(30); return 1;}
 hndl = getindresource("mine",1);
 getresinfo (hndl, &id, &resourtype, &genstr);
 id=(id+16384)/32;

 stopalert(-16384 + 32*id +1, NULL); /* post alert*/

Another Victim!

Paul Sterne

I hope this isn't a trend, but all my Mac equipment (except the laserwriter) was stolen at the end of January. I can't help you with an article right now (no Mac to write it on) but please renew my subscription for a year.

Cheap SCSI Drives Wanted

Steve Crandell

Keep up the good work; your magazine keeps getting better and better! How about a "How to Do it" hardware article for el cheapo SCSI drives for the Mac Plus? [Jeff Mitchell, take note! See the ad for low cost SCSI kits from FastTime in this issue. -Ed]

Postscript Question

Jim Foster

The Laser Print DA published in a previous issue of MacTutor stated that the Laser Prep file was downloaded to the printer so it could interpret quickdraw into postscript. I don't own a laserwriter or any apple talk hardware, but I do have the laserwriter drivers. With this I can create a postscript file (the command-F routine). My question is, why would the laserwriter need to interpret quickdraw if the Mac can send Postscript? [Good question. Mike Schuster, now with Adobe, explains that the print manager calls in the Macintosh are converted into calls to the Laser Prep file when the command-F key is pressed. Hence, the postscript file that is created on the Mac is mostly macros that are expanded by the Laser Prep file, which is down loaded into the Laserwriter. So the answer is that the Mac converts quickdraw into a postscript file that is mostly macros and hence not really "pure" postscript. The resulting postscript file is sent to the LaserWriter, where the calls to the Laser Prep file are expanded and performed, and finally, the low level calls to the postscript interpreter within the Laserwriter are performed, resulting in a page generation. If I count right, that makes three interpretations of the file: quickdraw to Laser Prep macros to postscript to printed page. No wonder the thing is slow! -Ed.]

Cauzin Reader

Murray Foster

I am writing to let you know that I have purchased a Cauzin Reader for use with my Macintosh. The fit and finish of the mechanism are superb. The software is simle and easy to use in the finest Mac tradition. I have used it to read every softstrip I can get my hands on. The reader has performed perfectly, although some strips have required a second try. How about strips in MacTutor?

[One of our contributing editors is working on an encoding program for making the strips on the laser writer. If we publish the strip making program, then we will start using it. The algorithm is fairly simple I am told, and easy to produce. -Ed]

Book Review

by The Editor

Assembly Language Books for Mac

It seems everyone wants to program in assembly langauge these days. At least everyone wants to write a book about programming in assembly language. There must be at least ten new books on assembly language programming on the Mac now, with half of them hitting the book shelves within the last two months. And more are on the way! What has been a drought is now a flood. Before you spend over $200 on all these books, here is my impressions of all the titles I could find locally.

There are three approaches to writing an assembly language book for the Macintosh:

1. Write a book on 68000 programming with no mention of Macintosh specifics.

2. Write a book on 68000 programming with some Macintosh ROM thrown in.

3. Write a book on the Macintosh ROM with a little 68000 instructions thrown in.

I have the following assembly language books and can classify them as one of the above three categories:

A. Programming the M68000 by King and Knight for Addison-Wesley: (1)

B. The 68000 Microprocessor by Triebel and Singh for Prentice Hall: (1)

C. Programming the 68000 by Steve Williams for Sybex: (1)

D. The 68000 Principles and Programming by Scanlon for Sams Books: (1)

E. Programming the Mac in Assembly Language by Coffron for Sybex: (2)

F. Macintosh Assembly Language Programming by Commander for Tab: (2)

G. Programming the 68000 by Rosenzweig & Harrison for Hayden: (2)

H. Assembly Language Primer for Mac by Mathews for Waite: (3)

I. Macintosh Revealed, Vol. 1&2 by Chernicoff for Hayden: (3)

J. Complete Book of Mac Assembly, Vol. 1&2 by Dan Weston for Scott, Foresman: (3)

As this list shows, the number of books on 68000 assembly language has grown considerably in the last few months! The first four books (and I'm sure there are others) are generally older and cover primarily the 68000 instruction set, offering no mention of the Macintosh. I personally prefer the Scanlon book as being clear and concise. Anyone programming the Mac probably should buy a good instruction set reference book from this first category.

The second and third group cover those books now available that deal with the Macintosh programming environment. Some authors have taken traditional 68000 books and added sections, often up to half the book, on the Macinotsh ROM and the programming environment on the Mac. These books usually start out with addressing modes, the 68000 instruction set, the 68000 hardware description, how to use an assembler, and then attempt to apply the first part of the book to the particulars of the Mac, ending up with a short Mac assembly example program to open windows and run an event loop and such by the end of the book. All the books in group 2 start out in this manner. These books in group 2 try to combine group 1 and group 3 into a single book. Generally, this type of book comes out as not a very good reference on the instruction set, and a poor Mac book lacking sufficent depth and detail in covering the Mac ROMS.

Group 3 presents those books which start out right from the beginning to teach the Macintosh technology in assembly language, expecting the reader to pick up the necessary 68000 instructions along the way. Of this group, the books are characterized by which book goes the deepest into the Mac ROMS and provides the most advanced program examples to cover. The two books by Chernicoff cover the Mac very well and are in wide distribution. However, the assembly detail is very sketchy and they can hardly be called assembly language books. The new Waite Group book is very well done and covers a large portion of the Mac ROMS in a clear and understandable manner. However, it does not go nearly into the depth that the first volume of Dan Weston's book covers. And certainly, Weston's volume 2 is far beyond any of the books listed above.

We can measure the depth of coverage of the Mac toolbox by drawing up a list of Mac topics and indicating which books cover the most subjects in assembly language.

Macintosh Programming Topics

1. The event loop

2. A Window

3. Menus

4. Dialog Boxes

5. Multiple Windows

6. Grow Window and update events

7. Scroll Bars and update events

8. Text Edit

9. Cut and Paste

10. Disk I/O

11. Regions and Quickdraw

12. Unique Icons

13. Making Desk Accessories

14. Resources

15. Clipboard, Scrapbook

16. Global Variables & memory management

17. Printing & Serial Ports

18. Sound

19. Speech

20. HFS

21. Appletalk

22. New ROMS

23. SANE & Numerics

24. Using debuggers

Using this list, we can now compare the six Mac assembly language books on the market and find out which ones go into the most depth in covering the Macintosh ROMS. Here is our list of books again with the topics they cover:

E. Programming the Mac in Assembly Language by Coffron for Sybex: (1-12, 14, 16-17)

F. Macintosh Assembly Language Programming by Commander for Tab: (1-4)

G. Programming the 68000 by Rosenzweig & Harrison for Hayden: (1-4,8,12,14,16-17,23)

H. Assembly Language Primer for Mac by Mathews for Waite: (1-6,8)

I. Macintosh Revealed, Vol. 1&2 by Chernicoff for Hayden: [Mostly Pascal]

J. Complete Book of Mac Assembly, Vol. 1&2 by Weston for Scott, Foresman: (1-20, 22,24)

The Macintosh Revealed books by Chernicoff are a kind of Inside Macintosh reference and do not cover assembly language per se. They are very good at describing much of the material covered by Inside Macintosh, especially for Pascal Programmers. They are most recommended for TML Pascal users, and in fact, Tom Leonard is marketing a complete TML version of mini-edit from volume 2. The programs are not LaserWriter typeset, but color is effectively used to highlite trap calls.

The book Macintosh Assembly Language Programming by Commander for Tab can be best summarized as a rush job with very little in the way of Macintosh programming information. It does have a nice calculator program that could be the basis for a calculator desk accessory. However, no information on how to create a desk accessory is given. Beyond the problem of coding calculator functions, there is little to recommend this book. Worse of all, the programs are not LaserWriter typeset, but rather imagewriter dumps, poorly done.

The book Programming the Mac in Assembly Language by Coffron for Sybex at first glance appears to be a very good book that shows off quite well on the bookstand. The first 256 pages do a nice job of covering the instruction set in a manner that would make it effective as a reference book. If you also have the other Sybex book on 68000 programming by Steve Williams, you might feel cheated since the first 248 pages of both books are virtually identical. It appears Sybex simply re-wrote the earlier book and re-printed it as a Macintosh book with the necessary changes. In chapter 4, we begin to write programs, and from this point, the two Sybex books diverge as the Mac programming specifics are covered. Once you get into the book, you begin to see the problems of converting a non-Mac book. The programs lack relevance to the Mac programming environment. File I/O is discussed before event loops and windows. Hex to ascii type utilities are covered as a first program. Fixed length and variable length records are discussed, which really are not meaningful in the Mac environment. Finally on page 348 we get into the Mac programming. A Mac Paint type doodle program is presented in chapter 8 that serves as the example. However, the order of presentation is uneven and confusing. It appears the code is discussed as it appears in the listing rather than in the logical order of toolbox managers. Through the printed code, a majority of the Mac ROMS are covered, but the style of presentation is hard to follow and understand and the coding style is confusing. In conclusion, this is a book that the more you read and study, the more disappointed and frustrated you become.

The book Programming the 68000 by Rosenzweig & Harrison for Hayden is similar in scope to the Sybex book above, but much better done, and much easier to understand. The first 128 pages cover the 68000, but it is evident the book was done for the Mac from the beginning. One drawback is that some of the book appears to have been done in Lisa Assembler and both the Mac and Lisa assemblers are mentioned. The program examples however are MDS and done in a familar and easy to follow programming style. Chapter 9 begins the Mac programming examples with a simple spreadsheet type calculator. This is a good example if your interested in spreadsheet technology or the SANE numerics package. In chapter 10 we get into the more traditional mac interface programming not covered in the calculator example. The undo command is covered, along with printing, and dialog boxes. However, just when your starting to warm up to Mac programming in chapter 11, the book ends, leaving you hungry for more! One nice thing about this book is a discussion of how to make a selection, have it blink and then drag that selection around like in MacPaint. This is a good book that can be recommended and I rank it third best in our list. It's main drawback is it waited too long to get into the Mac ROMS and ends too soon before much of the Mac programming issues can be covered in depth.

The book Assembly Language Primer for Mac by Mathews for Waite is one of the best books on Macintosh programming I have seen. The book is easy to read, cleanly put together, uses color very effectively for source listings and illustrations, and is understandable. This is one of the two Mac books every Mac assembly programmer should own. It is also the best "first" book if you are new to either assembly language programming or the Mac toolbox. The Mac programs start nearly at the beginning of the book, build in logical fashion and are easy to understand. ROM routines are nicely set off in boxes like a reference to help in understanding their function and calling sequence. This is the second best book on the market. It does not go into the depth that our next book does, but that is not a drawback, as it is very complete in the topics it does cover, and leaves you satisfied that you've had a solid foundation for further study.

The books Complete Book of Mac Assembly, Vol. 1&2 by Dan Weston for Scott, Forseman and Company, is the best set of books on Mac programming I have seen. These books are written in the same style as the Mathews book above, but are much more specific to Mac programming problems and covers a great deal more depth than the Mathews book. Volume 1 goes much farther than any other book listed above. As our comparison list shows, this book has it all! Not only does it cover more toolbox routines, it covers them in more depth, discussing potential problems, switcher considerations, Apple bugs and more. It is clear that while the Mathews book might have been written by an educator trying to teach clearly, the Weston book is a work of love from a devoted Mac hacker trying to cover the real life problems of a software developer. This book is a must for anyone serious about programming the Mac beyond the event loop and an empty window. It is the only book I have seen that covers material not previously published in MacTutor. Most of the information is not available in any other book. Such things as how to work with the clipboard between programs, how to write a desk accessory, the correct way to update multiple windows that have scroll bars and much more. The 68000 information is placed in the back, so you can review as much or as little as you need. But the text concentrates on toolbox programming and the 68000 instructions quickly become second nature. This is the thing that makes Mac programming different. It's not the 68000 that is the star, but the Mac ROMS! Weston realizes this and has the topics in the right priority.

Volume 2 of this set goes far beyond anything now in print, even MacTutor! The presentation on the clipboard and how it interfaces with switcher is particularly good. The print manager is covered in great detail as are the speech drivers. Both HFS and the new ROMS are also discussed. The only item missing is Appletalk, which as of this review was not covered for some reason. Perhaps by the time the book goes to press it will be added. This is the number one book to buy on assembly language programming for the Macintosh.

All of the above books are now in bookstores, with the exception of Dan Weston's book. Volume 1 is scheduled to reach bookstores in June and Volume 2 is scheduled for bookstores in November.

Software Version List

The recent explosion of new versions of software has everyone's head spinning, so we've decided to try and publish an updated list each month of the latest version of each program of interest to technical Mac owners. Here is our first attempt. Please write with any corrections, especially languages and utilties we may have missed.

Program Version

System Stuff

System File 3.1.1

Finder 5.2

Scrapbook 2.0

Imagewriter 2.2

Appletalk Imagewriter 2.2

Laserwriter 3.0

LaserPrep 3.0

Utilities

switcher 4.6

TMON 2.585

Nosy V2 2.09

RMaker 2.0d2

Font/DA Mover 3.1a6

ResEdit 1.0d7

REdit 1.2

Fedit 3.7

Heapshow 3.0

QUED 1.3

Edit (Consulair) 1.53

Edit (Apple) 2.0d1

Copy2Mac 5.0

Mac Tools 5.0

Hard Disk Util 1.21

Multimacs 2.8

MacZap 4.1

MockPackage 4.2a

Other DA 1.6

DiskInfo DA 1.4

WayStation minifinder 2.1

Languages

Consulair C 4.53

Aztec C 1.06g

Megamax C 3.0

TML Pascal 1.1

McAssembly 3.7

MSBasic 2.1

MS Fortran 2.1

ExperLisp 1.4

Experlogo 1.1

Porta APL 3.0a

Neon 1.5

Mach1 1.1

MacForth 2.4

Macsbug 5.1a1

MacinTalk 1.1

Trap Files

tooltraps 2.0a2

quicktraps 2.0a2

systraps 2.0a3

Equate Files

toolequ 2.0a2

quickequ 1.0a1

sysequ 2.0a2

timequ 2.0a2

syserr 2.0a1

scsiequ 1.0a1

sanemacs 2.0a1

packmacs 2.0a3

fsequ 2.0a1

prequ 1.0a1

atalkequ 1.1

Selected Applications

Thunderscan 3.2

MacWrite 4.5

MacPaint 1.5

MacDraw 1.9

MacTerminal 2.0

MacDraft 1.1

Just Text 1.1

Pagemaker 1.2

Ready Set Go 2.1

Statworks 1.2

Filemaker 1.0

Excel 1.01

Jazz 1A

Helix 2.0 r5

Omnis 3 33.10.MAC

OverVUE 2.0d

MS Chart 1.0

MS File 1.01

Multiplan 1.1

MS Word 1.05