Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!voder!apple!lsr
From: lsr@apple.UUCP (Larry Rosenstein)
Newsgroups: net.micro.mac
Subject: MacTutor Considered Harmful
Message-ID: <139@apple.UUCP>
Date: Mon, 18-Aug-86 20:04:56 EDT
Article-I.D.: apple.139
Posted: Mon Aug 18 20:04:56 1986
Date-Received: Tue, 19-Aug-86 23:13:23 EDT
Organization: Advanced Development Group, Apple Computer
Lines: 64
Keywords: MacTutor, bogosity

The August (and July, I believe) issue of MacTutor contains information
which is guaranteed to trash your heap.

I am referring to the article on creating custom menus.  In the article the
author describes how to install a custom menu defproc.  He recommends
allocating a handle and replacing its master pointer with a pointer to your
defproc procedure.

The problem is that each memory block has a header that points back to the
master pointer, so the Memory Manager can move blocks in the heap.  If you
follow the instructions in the article, the memory block you allocated will
still be in the heap and its back pointer will still point back to the
master pointer.  When the Memory Manager compacts the heap it will move the
block and FIX UP the master pointer.  This will trash the pointer to your
menu defproc, and your application will die when the Menu Manager tries to
call the defproc.

If you want to write a defproc that is embedded in your code (i.e., your
defproc is not in a separate resource), then the best things to do is to
allocate a handle and place in it a JMP instruction to your defproc.  (Watch
out for storing the address of a routine that might move if the segment is
unloaded.  Either make sure the segment is never unloaded or store an
address of a jump table entry.)

The only issue in my mind is the fact that the ROM will call LoadResource on
the defproc handle, to ensure it hasn't been purged, and the handle you are
allocating will not be a resource.  It appears to me that as long as the
handle you allocate is never purged, the LoadResource call will succeed (it
doesn't have to do anything).  I am checking with Technical Support on this
question, and will have a definitive answer in a couple of days.  I am
posting this now because this is a critical error in MacTutor.

I talked to the editor of MacTutor and the author of the article about this
at the MacWorld Expo, and finally convinced them that the scheme in the
article will not work reliably.  (The author had not really tried the
technique in a real program where heap compactions might occur.)  Hopefully,
they will follow this up in a future issue; if I can find the time, I plan
on writing a letter to MacTutor.

The article was written by a person from TML, so I would guess that the same
code is distributed in the sample sources that they sell.  Let the buyers
beware.

Finally, I want to say something about MacTutor as a whole.  I like the
magazine because it does provide listings and sources, etc.  I have noticed,
however, several articles that describe questionable Macintosh programming
techniques, such as this problem with menu defprocs.  

It is not very hard to tell which things are questionable.  Any programming
"trick" that relies on undocumented features or that is discovered by
disassembling the ROM, System file, etc. is almost guaranteed not to work
on future software releases.  Although these tricks are fine for personal
hacking, they should not be used in any distributed program.


-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET