Letters, reviews

Dr. Tom's Reference Decks

Tom Programs of Washington DC has announced a set of reference cards keyed to Inside Macintosh for developers and programmers. Each card lists information about a single toolbox trap call, giving the trap name, address, parameters and notes on how to make use of the trap routine. Both the toolbox and OS are covered. Three sample cards are shown below full size. As you can see, there is quite a bit of technical information summarized for each routine. This set is a must for anyone doing programming in assembly or C where toolbox calls must be made directly. It provides a handy quick reference during programming that can eliminate the need to flip through the un-referenced Inside Macintosh book.

Three decks are being offered, printed on card stock and color coded by manager. Each of the three sets sell for $21.95, a very reasonable price. Alternately, you can buy the entire set as a Microsoft File data base for $59.95, but we think the index card format is much more handy, since your computer is hardly free to run File while your writing code! Contact Tom Programs, Suite 34T, 1500 Massachusetts Ave., NW in Washington, DC. 20005. Or call (223-6813). Or bag the formalities and just send for the goods: Deck 1, 2 or 3 @ $21.95 each, File Data Base @ $59.95 or both combined for $99.95. Include $3 for shipping.

One Flew Over The QuickDraw's Nest

Valuable Information Press announces a new technical Macintosh Programming book by Gregg Lewis of Montreal, Canada, titled "One Flew Over the QuickDraw's Nest" (a fan of Jack Nicholson's no doubt!) This book is designed for people who want to program their Macintosh! (Where have I heard that before?) Should be great stuff for MacTutor fans. The book sells for $24.95 and is being distributed by Jim Fitzsimmons at Mac America, the same distributor who handles MacTutor, Macazine and the Macintosh Buyer's Guide. Contact Jim directly to reserve an advance copy. The final manuscript is being prepared for printing now and is expected to be available from Jim at the Mac Expo in Boston at the MacTutor booth. Contact Mac America, (714) 779-2922.

Here is a sample chapter from the book, re-printed with Gregg Lewis's permission [Since Gregg speaks French, some english grammer is still being revised prior to final printing]:

REVIEW

At this stage, you and I are perfectly aware that we still have a long way to go before we can set up a program together. We have brought up a certain amount of notions, and we'll be obliged to extend some of the points raised.The first approach was very schematic, of course. Now that a collection of concepts has been provided, which is supposed to have fixed all the spare parts in our minds, let's penetrate more in depth each component. Don't expect to really understand the meaning of everything until we go together through the commented program lines.

HOWS AND WHYS OF THE MANAGERS

In order to have modular programming, the people at Apple wrote a set of procedures and functions for each specialised operation within the Macintosh™. They constantly used the same variable and type definitions; that is the same words. They designed them such a way that, in a given structure, they always found the required types and the amount of definitions they needed. So, they designed several basic structures. Some examples are the types Point, Rect, cursor or bitmap, which we saw in QuickDraw.

Adding some basic functions, they wrote a whole nucleus to perform specialised low-level tasks. This nucleus has been named... Managers. And each specific task oriented Manager is named for its purpose. The Manager philosophy allows modular programming, which brings compactness in coding, but it is not the only reason why. As an external programmer, you've been using those procedures and definitions for a week, you eat with them, you sleep with them, you drink in their company, you... for the rest of your life. They're in your mind forever, and ever. In short, you know them, you know what they do, you relate a name to a function, and with the mnemonic names used, you do not loose time in associating a name with the meaning of a type, a procedure, or a function and the purpose of it. Does the routine 'GetNextEvent' belong to the Font Manager? Certainly not.

These mnemonics can tell immediately which Manager the function or procedure you are reading - or writing - belongs to. And, as said previously, within one week, they are part of yourself. There are more than 480 different routines, but actually, only some 80 are currently used. Obviously, this is a small number, and just like the individuals you happen to meet daily, you know them after a short while.

HOWS AND WHYS OF AN EVENTS LOOP

The whole interaction between the application, the user and the system goes via exploring an events queue. You are not obliged to process the events in the sequence they occured. You may select one or several of them using a selection mask, each type of event has its numeric code, corresponding to a bit of the mask.

In order to accept several types of events, it is enough to add their numeric codes and to pass the result through the EventMask. A mask of (-1) will pass all events which may occur. These points will be developed while exploring the Event Manager.

Time is an important notion: the unit of time chosen is the tick, a 1/60th of a second, date synchronized interval. The number of ticks (Tickcount, a longint) is maintained from the beginning of last boot-up.

Why this choice? Because the Macintosh™ system is re-initialized every 1/60th of a second (during the Vertical Retrace Interrupt), and then, the memory itself is re-organized.

An event is described in a record (EventRecord). It contains such items as: Which Event, When (in ticks), and where the mouse is (in global grid coordinates, not in a GrafPort). All of this information is qualitative as well as quantitative data in regard to an Event.

Different types of tasks are met: background (keyboard, mouse, SystemTask), foreground, etc.; some events are even swallowed and processed by the system, and require no action from the developer.

With such a system, generating events at random, you don't know when an event occurs, you cannot foresee its arrival and reserve it any room in the next Hilton. The events occur when a software user decides he will click, or inserts a diskette; the exact instant may not be forecast. In consequence, your software will have to constantly test if an event, any kind of event, has occured.

The best way to write compact programs that test events, is to use an EVENTS LOOP. This method reduces a lot the code size (both source and object). A survey on automations and compilers shows that one is better off using tabular automations to perform the error recovery without extra prohibitive sized code (random events). This point will get clear while explaining GetNextEvent.

An automation has transition events and states. In the Macintosh™ programing, events produced by the System are transition events; and, states are handled by the application, via booleans, etc.

This small chapter summarizes the stuff so far covered. Now that you know about the machine (well, reasonably), we dive into the Managers, themselves, in person.

We begin by, uh? Which Manager already?

Oh, yes...

The Memory Manager.

Letters

Write for Women Too!

Regina S. Litman

My Mac is downloading from a BBS right now, so I have to (horrors!) handwrite this letter. There aren't enough women involved in Mac developing. Hope I can shed my IBM/Univac mainframe biases toward Cobol and PL/1 and start picking up Pascal, Forth, C, NEON, LISP, Modula-2, Assembly and BASIC so that I can write for the Mac soon.

In the meantime, here are some tips at using more inclusive language, so that your (hopefully growing numbers of) female readers won't feel left out.

Instead of "The user literally changes...to his own tastes..", you can say "Users literally change...to their own tastes..." or something similar. Get the idea? I don't mind "his" or "her", but I know that others do though.

I look forward to learning from past, present, and especially future MacTutor issues. Also, please do not let others have my name, address and phone number for commercial purposes.

[Can I sign your name to this letter? Shall try to watch the gender in our articles. Thank you. -Ed.]

Sold on Call A.P.P.L.E. Tradition

Arthur B. Davis, Jr.

OK guys, I'm sold. I just found your publication for the first time at issue #7 and I am quite pleased to see what you are doing. I am a software engineer for a living, but I am relatively new to the Macintosh, and I am thrilled to see the tradition (as you say) of Dr. Dobbs and Call A.P.P.L.E. still alive and attached to this marvelous machine. I found issue #7 to be very much "to the point" and informative. I not only hope that you continue, but that you performed at the same level in the past, as I am writing not merely to compliment you and subscribe, but also to order the first six issues.

Your assembler articles might be of great interest to me if I knew where to start. Any suggestions would be gratefully accepted. [If your into MacAsm, check out this month's Beginner's Corner for a simple MacAsm assembly shell. If you like MDS, see issues #3 and #4 for similar Apple assembly programs for windows, menu bars and event loops.-Ed.]

Forth Tokens

Larry Tannenbaum

I was at a computer store the other day and I picked up a copy of your magzine and started looking through it. You've got some good stuff in there and I'd like to subscribe. I have some comments on the FORTH column in the May issue. The author should mention which version of MacForth he's talking about. I have versions 1.1, 1.2, 2.0 and 2.1. The tokens mentioned in the column work in 2.0 but apparently are not available in 1.2 or 2.1. Anyway I couldn't find the same code in memory. The dictionary in the later versions are in a different order so the tokens won't be the same.

[ Jörg, can you provide an update on this? -Ed.]

Mac Technical Notes?

Dave Alverson

I hope you are planning to reprint the Macintosh Technical notes from Apple in MacTutor. I don't think they would mind. I think the first issue is just now going out. [Haven't heard of this or recieved anything and I'm certified. Anybody know about this? -Ed.]

MacPascal Frustrations

Steven Leach

I would like to relate my classmates and my experience in using MacPascal version 1.0 to write graphics oriented software for a class at Stanford University. First the good part: the debugging facilities in this system are very good. The use of the observe window, to allow a person to see how the variables are changing while the program is executing is extremely helpful to find the occasions when a sign or operation had been switched. The Instant Window that allows a person to enter small Pascal legal statements in conjunction with the STOPS is also useful, but is often difficult to use for debugging since only those variables that are currently active when the program was stopped can be used. The editor is quite good, although if your program gets over 10K, it does tend to get a little slow, especially on boot up.

Now for the bad news: Besides the established procedures available in MacPascal, in order to get at the tool box, you must study very carefully the text editor example given on the MacPascal disk, in order to create your own Menus, dialog boxes, buttons, etc. through a completely unmentioned facility called InLine Procedure. Since this procedure has only been very briefly discussed in MacTutor, I have yet to have menus in my programs that have not bombed the system. This is bad enough, since it requires that I buy Inside Macintosh (which I have now done), however it gets worse. If your Pascal program exceeds 30K!!! the text editor, program editor hangs completely, no warning, no sign, not even a bomb; it just stops and you have to restart the system and lose all you have typed in since you last saved the file you were working on! Several of us called Think Technologies to ask about this and were given no explanation. Thank you for your magazine, and for providing a forum for this and other issues important to programming.

[Alan Wootton, can you look into this for us? Personally, I like MS Basic 2.0 for large programs that have to be done quick. I've had no problems using custom menus and such from BASIC. Both InLine and GENERIC procedures allow full toolbox access for Pascal and have been covered in past issues of MacTutor. Perhaps we can address a more fuller treatment of menus under MacPascal in an up coming issue. -Ed.]

Forth Conference

Linda Kahn

The FORTH interest group is sponsoring a Forth Modification Laboratory conference October 25-27, 1985 at the Stettenfels Castle near Frankfurt, Germany. This FORML is a forum for sharing and discussing new proposals to enhance the Forth computer language.

FIG also invites you to the 7th annual Forth convention and banquet on September 21-22, 1985 in Palo Alto, CA at the Hyatt Rickeys. The convention will focus on current developments and uses of the Forth language with exhibits, vendors, tutorials and more. Convention pre-registration is $10. For additional information, write FIG, P.O. Box 8231, San Jose, CA. 95155 or call (408) 277-0668.

MacTutor Ads are OK

Robert Shatto

I am very impressed with the quality and quantity of your articles and I want you to know that such work is being noticed and supported. I have already ordered material from your advertisements that I coudn't find anywhere else, so keep up the good work and keep out the bad ads!

Bob's the Greatest!

David W. Smith

Bob Denny's article on custom dialog boxes in volume 1-7 was outstanding! However, potential users of Bob's routine should take care that the string returned by the dialog is really null-terminated.

I found the Mousehole postings quite interesting and I have heard from MAUG and local Mac boards that this is a great board. Any chance that I might get some info on how to apply for "Usership"? [Write the Mousehole care of the address at the top of the Mousehole colmun in this issue for a password and access instructions.-Ed.]

Do Nothing Program!

Michael Coren

This letter is being written in response to Andy Gottlieb's letter that appeared in the June 1985 issue of MacTutor. He wants to know if there is an application available "...which does absolutely nothing but return to the Finder". Well, Mr. Gottlieb, there is, and you already have it. It's called the Finder! To use it, open up the system folder, hold down the command and option keys, double-click on the Finder and release the keys. This will "run" the Finder on that disk, making that the startup disk.

Phenomenal!

Scott Vanderbilt

You folks have a phenomenal magazine. Sign me up pronto, tonto! Enclosed is my check for $24.

NEON WANTED

Randy McCallum

First of all, thank you for issuing this Mac tutorial Journal. I want to learn how to make my own programs on the Mac and have just recently purchased NEON and MacForth. I was getting discouraged at first, but Reese Warner from Kriya Systems told me of your monthly Journal. I am told that at NEON tutorial will be in the upcoming issues, of which I am glad to hear. [We had our first NEON column by Noel Bergman last month; we haven't heard from Noel in a while, so Paul Snively is working up another one. Between those two editors, we hope to have a regular NEON column. -Ed.]

I have a BBS for Mac users in my area [ (604)-368-5931] called "Neon Lights" BBS, running on a mouse exchange program from Dreams of Phoniex. I want to be able to make my own BBS program using NEON or Forth that supports a telegamming section. I use the 300/1200 Hayes modem and need help to start out on the right track. Reese Warner assured me that I would be taking the right step by subscribing to your Journal, and I am sure I have. If you have any public domain stuff, I would appreciate it. [ See our source code disks for programs published in MacTutor. -Ed.]

Also a useful exercise is to modify the example to suppport selection by double-clicking. Keep up the good work! (Please send me a copy of your submission requirements.) [Submissions are MacWrite file format, with source code provided in both original source form for the source code disk, as well as in a MacWrite format. Illustrations should be in Draw when possible, otherwise in Paint. Always use tabs instead of spaces for alignment. Column width should be set at 2 and 51/8 inches, single spaced.-Ed.]

Loves the Utility and Source Disks

Mike Johnson

I'm certainly glad I subscribed to MacTutor with issue #1! I've learned a great many good hints and help on Assembly, Forth and C language programming on the Mac from your articles. Keep up the good work! I see an improvement in the Journal every month. Your source code and utilities disks are greatly appreciated!

How about some help on who's got what? As of May, I have these versions:

Switcher 2.6 [latest is 3.5! -Ed.]

Paint 1.5

Write 4.5

Draw 1.7

Finder 4.1

"New" imagewrite 15 (on Draw disk)

[ These are the latest. Anybody have anything later? -Ed.] MAC C 2.0 with the floating point and other changes seem good. Mac C does run better on a RamDisk. I do wish the MDS linker was a "smarter" on though. Some public domain and shareware stuff seem to be in trouble. I've had problems with SETFILE and the newer KEYCAPS with the new Finder 4.1. Some of the problem seems to be with Apple's new Font/DA mover (ie it seems some resources are being renumbered and some aren't when copied). Does anyone know which of the above are safe to use without crashing or data loss?

I find it rather bewildering at the Paint/Write "musical version" game that has been playing lately. [Aren't we all! -Ed.] Now it seems the Finder, System and Printer drivers have joined the fray. [Don't forget about the laser printer stufftoo! -Ed.] It IS difficult to know just what you now have on a given disk and what may cause trouble later if not updated. Someone sort it out ---PLEASE!!

No Fluff!

Michael Rollins

Let's give your programming Journal a try for a year. The NO FLUFF got me.

Megamax C handles Pascal Stacks

Jan Eugenides

Please send your writer's kit or whatever you have for contributing editors. [If you don't hear from us, send a MacWrite disk. -Ed.] Now a note for Bob Denny: In your columns in the May and June issue you indicate that routines which are called back from the ROM must be written in assembly language because they must handle the stack Pascal style rather than C style. The Megamax compiler includes a "pascal" directive which tells the compiler to use the stack Pascal style in the following function. This makes life very easy! For example, here is a routine I use for the clikloop routine, to scroll text when the mouse is moved outside the viewrect during selection of text.

pascal clicklooproutine()
{
Point   thept;
Rect  therect;

therect = (**hTE).viewRect;
GetMouse(&thept);
if (thept.a.v>therect.a.bottom)
 {
 SetCtlValue(vshandle,                            GetCtlValue(vshandle)+get_lh());
 edit_scroll();
 }
if(thept.a.h>therect.a.right)
 {
 SetCtlValue(hshandle,                             GetCtlValue(hshandle)+get_lh());
 edit_scroll();
 }
}

This routine is called from TEClick, and all that is necessary is to redraw the controls after TEClick is done (when called this way, SetCtlValue doesn't redraw the controls, don't ask me why!). A simple DrawControls(mywindow) will do it. I am quite pleased with the Megamax in general and would recommend it.