lsr@apple.UUCP (Larry Rosenstein) (08/19/86)
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.CSNETchuq@sun.UUCP (08/19/86)
> 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. I feel like adding something to Larry's comment here. I subscribe to MacTutor, but I keep trying to convince myself to get rid of it. Why? because they are, frankly, sloppy. I don't trust their articles OR their code. I can't remember when the last issue that didn't have some kind of errata or bug fix in it was. They typography and layout is ragged (little things like comments wrapping around to the next line, for instance), the issue tends to have a number of spelling errors, and in general I don't think MacTutor does a professional job of presenting their material. I was around when your only choices were Mactutor and Macworld (ugh!). Back them, IM was in the phone book (mine was actually looseleaf) adn the rest of the Mac books were gleams in the author's eye. MacTutor was the cutting edge of hackerdom. When you'r spending all your time trying to come up with information and you are playing to a small and intense audience, that's fine. Mactutor is trying to be the programming magazine for the rest of us, though, but they haven't taken the time to doublecheck they work, clean up their act, or really think about their audience. I can look at a piece of code and see that the programming is shakey. What about the person who just bought a Mac, picked up lightspeed C, and starts typing it in? He may not even OWN IM yet. how is he supposed to tell good code from bad code? Mactutor isn't writing at the edge of the Mac anymore (in my eyes) ytet they also aren't protecting the novices from themselves. I find it hard to recommend macTutor to people anymore. buy a couple of good Mac books instead. Like the Huxam C book (Hi, fred!) from Sybex. If you must read macTutor, I echo Larry -- buyer beware. The code is sloppy, and it isn't even neccessarily good. chuq -- Chuq Von Rospach chuq%plaid@sun.COM Delphi: CHUQ {decwrl,hplabs,ihnp4,seismo}!sun!plaid!chuq Do not be arrogant because of your knowledge, but confer with the ignorant man as with the learned.... Good speech is more hidden than Malachite, yet it is found in the possession of women slaves at the millstones. -- Ptahhotpe
siritzky@acf2.UUCP (Brian Siritzky) (08/19/86)
I will not comment on the content or layout of the Magazine, but they do have one very good thing going for them. Their ads are usually from companies that are ahead in marketing Mac stuff. A number of small mail order places cannot afford to put ads in the big glossy magazines (like MacWorld), but they can afford MacTutor. Also, the ads are aimed at developers, not at end-usr consumers.
tim@hoptoad.uucp (Tim Maroney) (08/21/86)
I also dislike MacTutor, though every two or three months it contains a bit
of valuable information. My chief dislike is their use of rumor and
out-and-out falsehood. For instance, a message was run saying that caching
doesn't work unless the "cache" bit of an application is turned on - in
fact, the cache bit has no effect at all in the current system, and is
simply reserved for further use. The cache works as advertised without any
messing with bits in Fedit. It is obvious that someone thought they were
very bright to discover this bit and, blinded by their brilliance, jumped to
a totally inane conclusion as a vessel for demonstrating it. This is only
one example, but there are many others of equally dumb caliber. This has
made me distrust anything I read in the magazine.
I also agree with Chuq (a rare enough occurrence...) concerning the
sloppiness of the layout. Every page is ugly, without exception. Source
code listings are frequently laid out in a style that completely ignores all
indentation. Errors are made in tables of contents. Columns are laid out
visibly skewed and with variable line spacing. Gack! Shouldn't a national
magazine have layout at least as good as a college newspaper?
Finally, it is irritating that there is no clearly-defined policy for the
use of source code in MacTutor. If I want to write a menu definition
function and start from the one they provide, is this legal? Can I use
their LaserWriter desk accessory as the basis for a print spooler? Who
knows? This renders the source code almost useless, since it is typically
of a low grade and incorporates all sorts of uncommented clever tricks.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
Bibliolatry is my bizarreness.bhyde@inmet.UUCP (08/25/86)
First lets not be too hard on MacTutor, here we have a group of people trying to provide a useful service to people who like to hack their Mac software. If you multiply their distribution times their subscription cost they are making a very very meager living doing this, so it is surly and act of love at this point. If those people that think they are professional about software for the Mac don't even write letters to MacTutor, or articles, etc. then how is going to become the resource we all need? I agree that it is spotty, but it is the only publication in this area and I'd rather have something here rather than nothing. Second about this handle stuff? I usually fack a handle in my global data area. It never occured to me that somebody who uses the handle might decide that it was really a handle and start treating it as such. What a mess! This means that every place that the documentation says a things a handle I'll actually have to allocate a real Handle from the memory manager and then stuff it full of things to make it have the values I want in it. If it is code then I'll have either make it a real code resource or I'll have to "stuff a jsr into it." (What a hack!)
zben@umd5 (Ben Cranston) (08/28/86)
In article <26700068@inmet> bhyde@inmet.UUCP writes: > ...Second about this handle stuff? I usually fack a handle in > my global data area. It never occured to me that somebody who > uses the handle might decide that it was really a handle and > start treating it as such. What a mess! This means that every > place that the documentation says a things a handle I'll actually > have to allocate a real Handle from the memory manager and then > stuff it full of things to make it have the values I want in it. > If it is code then I'll have either make it a real code resource > or I'll have to "stuff a jsr into it." (What a hack!) It may seem a hack, but what about those routines that add to an existing data structure? They rely upon being able to make the area pointed to by a handle bigger! You want them to make your carefully faked data array bigger for you? :-) -- umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS"