Letters

Fortran Bugs

Jim Bishara

Help, Help, I can't get SetItemStyle toolbox call to work. I've spent at least 40 hours reading the Microsoft Fortran manual and no luck. I'm running a Mac Plus under Finder 4.1 (dumb Microsoft), with version 2.1. I used the DEMO.INC file supplied with the Fortran. When it tries to execute the trap, a bomb message returns ID=02. What can be wrong?

call toolbx(GetItemStyle, menuhandle, itemcount, chstyle) {works fine}

call toolbx(SetItemStyle,menuhandle,itemcount, chstyle) {bombs like a champ with ID 02}

[Probably the toolbx.par file is wrong. We've found lots of errors in it in the past. SetItemStyle probably is not a VAR. Just a guess. -Ed]

Aztec C 1.06H Release

Don McCauley

I purchased my Aztec C from ComputerWare, a MacTutor advertiser, and on May 20, I received a beta release of version 1.06H, created May 12th. This time I received tens of pages of update documentation from their new manual, fresh off the press. Included with this update is an index. Unfortunately, the index seldom includes the key words I've looked for. For example, try to find in the index where to find how many characters are significant in a variable declaration? I've had trouble with multiple defined symbols using "theWindow" from Takatsuka's book Using the Macintosh Toolbox with C, page 70. Struct assignments in SetRects don't seem to work right for me. Any help for us Aztec'ers in the ABC's of C column? As far as HFS goes, basically it's "so far, so good" with this version. I really love the Manx UNIX like vi editor, Z. Manx is worth it just for z. I'm excited about C as a language and more specifically, about Aztec C for my Mac Plus.

[I'm sorry to report that Bob Gordon, our ABC's of C author, became seriously ill this month and has been unable to work on his C column for some time. We've talked to him and he reports he is beginning to recover and hopes to contribute another ABC article next month. We wish Bob a speedy recovery as I'm sure all our C fans do. A few notes and letters to Bob would be most appreciated I'm sure. Send them to Bob care of MacTutor and we will forward them on. -Ed.]

What's Wrong with this Picture?

move.l  #4, D0
_NewHandle
LEA   #$40E132,A1  ;get icon pointer in rom
move.l  A1, (A0) ;save pointer in new handle
 pea  top(A5)  ;set up rom call
move.l  A0, -(SP)  ;handle to icon
_PlotIcon ; plot it

[Note: I tried to write an assembly routine to plot the famous stolen icon from ROM memory, but it didn't work. -Ed.]

Icon Problem Above

Lon Kelly

Thank you for your recent letter regarding the stolen icon problem. The simple explanation for the failure is that the line

LEA #$A0E132, A1

is not a legal 68000 assembler statement. This is because LEA will not use the immediate mode for the effective address field: only control addressing modes are allowable (see Morotola's Programmer's Reference Manual, p. 102 and p. 53). However, Mac C will assemble the line, setting the effective address bits as though it were a MOVE instruction. The linker listing shows the code actually generated:

Mac C Linker Listing:

4: 43 FC 00 40 E1 32    lea   #$40E132, A1
A: 20 89  move.l a1, (a0)
C: 48 6D FF  FC  pea top(a5)

Note that the first six bits indicate the effective address mode. Mac Nosy version 2.1 will disassemble the errant code without comment, as shown by the Nosy listing, but it loses track of 2 bytes and the next instruction:

Nosy output:

4: 43FC 0040 E132  LEA  #$40E1232,A1
; where did location A go?
C: 486D FFFC     PEA glob1(A5)

The Mac Zap listing shows that the code is actually on the disk as in the linker listing and that Nosy just got confused. It is interesting that Mac Zap and TMON, which have relatively simple disassemblers, recognize the illegality, while the assembler and Nosy do not.

Mac Zap Disassembly:

00F3C4  43FC   DC.W $43FC  ;illegal 

I believe you have another, more insideous problem doe to direct manipulation of "master pointers" created by _NewHandle. You seem to simply write over them. This leaves the memory manager with a master pointer pointing to ROM or to part of your code, rather than to a "relocatable block". I've never done this, but I sure expect it would cause problems with heap compaction, etc. What will happen if you call _DisposeHandle for a "handle" to ROM?

I think it would be a lot safer to do something like this: first make a constant pointer in your code, then push it's address (which would be a handle in the sense of a pointer to a pointer, but not in the context of the memory manager) as a parameter to _PlotIcon. See the untested suggestion below:

romicon:  dc.l   $40E132
 pea  top(a5)
 pea  romicon
 _PlotIcon

More on the Icon Problem

Peter Brown

Thank you for your response to my letter. I have to admit my surprise at receiving it. You must be swamped wiath mail and I really appreciate your taking time out to write.

I took a look at the code you sent me and the stolen mac icon problem in particular. I banged in the whole listing as it stood and then fiddled around with it. The problem looked like this: the "LEA" instruction does not require use of the immediate mode designator, '#'. If it wasn't just a handwriting boo-boo, I'm surprised your assembler took the statement. [See previous letter. -Ed] This is possible pitfall #1. Well, to test things out using TMON, I inserted an:

LEA $40AD40, A1 ; NOTE FOR OLD ROMS

instruction at the spot in question, set the program counter to the beginning of ICONSTUFF: and let 'er rip (an instruction at a time). Lo and behold, I got a bunch of barbage in the output icon.

I then thought I'd trace through the ROM code to see what it looked like. The routine itself is pretty compact and straight forward, and no special handling of address registers. After a few different efforts, including getting garbage plotted from the icon data in RAM, I realized that the LEA 'ROM' location, A1 instruction assembled as 6 bytes, not 4 as with the LEA ICON, A1 which uses program counter relative addressing. I was coding over the next instruction! This is possible pitfall #2.

After re-assembling the file with the LEA $40AD40, A1 in place, (and no typos!), the code worked! Best of luck and keep up the great work with MacTutor.

 lea  icon, a1 ;assembles in 4 bytes 
 move.l a1, (a0) ;move pointer to a0 h
 pea   top(a5) ;push rect
 move.l a0, -(SP);push handle
 _PlotIcon;plot icon

[The advantage of being Editor of MacTutor, is that I have 6,000 "registered" programmers to call on for assistance! Thanks guys! -Ed]

Loves TML

Micahael Rollins

I appreciate all the help your publication has provided over the last few months. There is nothing better than good examples to help learn a system as sophisticated as the Mac's. Since I have started using MacTutor and programming with TML's Pascal, I have managed to come a long way up the learning curve on the Mac. I find that I turn frequently to Mactutor for help with ROM calls and Resource Files that are not well explained in Inside Macintosh. I looke forward to each month's copy. Keep up the good work.

Tutor and TML Great

Terry Permeuter

Just got the TML Pascal compiler and saw an issue of MacTutor. Both look great! Enclosed is my check for a year's subscription. If you haven't done so yet, could you plan on an article or two on the differences between MacPascal and TML? The ads say TML compiles MacPascal programs, but I've already found some walls when trying that. A short guide on what to look for would be helpful! Keep up the good work!

[MacPascal is so non-standard that it is a dis-service to try and maintain compatibility with it. See the new LightSpeed Pascal, which IS TML compatible. -Ed]

Thanks for the Review

Dan Weston

I hope that by now you have received a final manuscript copy of volume two of the Complete Book of Macintosh Assembly Language Programming that you so thoroughly reviewed at the mid-way point. I was able to incorporate many of your suggestions into the final version, but not all. In particular, I didn't write anything about AppleTalk because I haven't ever had the opportunity to use it in any real situation. I think the strength of my books is that they are derived from my experience as a software developer, so I am reluctant to write about things that I have no direct experience with. Also, AppleTalk seems to be worth an entire book all by itself. I am very grateful for the comments that you made however, because I think they helped me produce a better book in the end.

I don't know exactly when we will go into final editing, but I assume that it will begin July sometime. I expect the final book out sometime in November. Thanks for the nice words in MacTutor on my new books!

Language Fanatic

David Adamski

Well, I see by the EXP 5/1/86 notcie on my mailing label that it's time to renew my subscription to MacTutor. Enclosed please find my personal check for $30. MacTutor is one programming journal that I would NOT want to be without. Although I subscribe to a variety of computer publications, I look forward to receiving yours each month. As a language fanatic I feel that MacTutor is by far the most informative Journal, with regular articles on all the popular programming languages for the Mac. Sorry to hear about your robbery, hope my renewal helps you get back on track. Keep up the good work, and I wish you luck in the future. [MacTutor is enjoying great success this summer, thank you. -Ed.]

Questions

Bill Westcott

I got an idea! I've been trying to learn TML Pascal and Mac programming at the same time and your magazine has been a great help, but when my programs don't work, it's sort of like playing Zork. I keep trying everything till it works. Very time consuming. I noticed a green "3" sticker on one of my last MacTutor issues. That means that there are at least ten people in my three digit zip code who subscribe to your magazine. What do you think of a "Mac.Guru" program where people who know what they're doing might volunteer to answer stupid questions and your organization could somehow bring them together with askers of stupid questions? Just thought I'd ask. [Here's a stupid question: How would you do that? -Ed]

How do others do it?

J.M. Puckett

Oh No! I just received my April issue of MacTutor and on my label I see that my subscription is due to run out beginning of next month. So enclosed herein is a check for $30. Also I would like to know if you could send me an author's kit. I have just completed a series of desk accessories and applications using Megamax C, and am anxious to share some of the neat things I have found.

Yours is an excellent publication. I have learned a lot from it. However, I would like to submit a suggestion: Please suggest that some of your experts write articles on defining one's own menu, window, and control definitions. I have been attempting to write these kind of programming objects, and have had, for the most part, great success just by following the hints in Inside Macintosh; but I would sure like to see how others are creating such things. [Keep watching my Intermediate Mac'ing column especially last month's TML shell program. It had a lot of goodies! -Ed]