Sep 86 Letters
Volume Number: 2
Issue Number: 9
Column Tag: Letters
Fortran Bugs
Jim Bishara
New Orleans
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, menu handle, itemcount, chstyle) {works fine}
call toolbx(SetItemStyle,menu handle,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
Ridgecrest, CA
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
College, AK
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
La Mirada, CA
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
Broken Arrow, OK
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
Seattle, WA
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
Famous Assembly Author
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
Tulsa, OK
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
San Leandro
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
Austin, Tx
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 columne specially
last month's TML shell program. It had a lot of goodies! -Ed]