Winter 91 - Letters
Thanks for the excellent article in the October 1990 issue of develop dealing with polymorphism in
C++ stand-alone code resources. I have one question about the code that accompanied it
on the disc; it concerns the file WindowDef_main.cp: why are the overloaded "new" and "delete"
operator definitions bracketed by
the #ifdef NEEDED and #endif statements? Is NEEDED defined somewhere else? (I couldn't find
it in any of the other files on the CD.) Are there circumstances in which you wouldn't want to
overload the storage operators for a window definition function? I'm confused.
--Carlos Weber, M.D.
Yahoo, a technical buck to stop! Lemme at it!
The code in question (#ifdef NEEDED... #endif) shouldn't be there at all, and as a matter of fact is ignored
by the compiler, since NEEDED isn't defined. It is left over from when Patrick was developing the code and
In the final version he is basing his WindowDefinition class on the
Relocatable class, which is in turn based on HandleObject, an Apple® extension to C++ which uses handles
instead of pointers when allocating space for new objects. No overloading of the storage operators is necessary.
Sorry about the confusion. I should have spotted that code and yanked it out before we published.
In develop, Issue 4, you advocate installing DRVR resources at startup time by changing their
resource ID to an empty slot in the Unit Table and then calling OpenDriver rather than use
_DrvrInstall due to its bug.
The problem with this method is
that it actually modifies the DRVR
resource, which has two consequences:
1. According to Apple you are not supposed to modify yourself; and 2. it sets the last date modified
field on the file. This latter problem causes backup programs to think the file has really changed and
it worries users that perhaps some virus has modified that
file when they know they didn't.
Thus, in my opinion, it is much better
to use _DrvrInstall and, until Apple fixes the bug, stuff the DCE yourself. This method does not
suffer the side effects of the OpenDriver method.
You're right, it's easier to use the method outlined in my article, but it's "better"to
use _DrvrInstall and manually put the pointer to the driver into the appropriate field in the DCE.
I have a question about the article on
the 8*24 GC card in develop, Issue 3, which, incidentally, was excellent. On pages 338 and 339 you
mention the files that must be present to use the card. Is the GC file a transparent patching upgrade
or is it a supplemental code block that duplicates all of the 32-Bit QD file functionality?
Good luck with Dogcow breeding,
The 8*24 GC file contains more (and less) than just the 29000 equivalent of 32-Bit QuickDraw TM; it also
contains the IPC software that steals QD calls and transfers them to the card, the shell (GC OS) that receives
the commands and dispatches them as well as doing the Memory Management chores and such, and finally the
'drawing' parts of 32 QD. Note that calls that do not cause any drawing to take place, such as NewGWorld,
are not part of GC QD but are executed by the main processor even when acceleration is on.
All these functions are not part of 32 QD and therefore make it necessary to have the 8*24 GC file present
when you want to have acceleration. So when running 6.0.x you need both files, 32 QuickDraw and 8*24
GC; under 7.0 you will need to have the 8*24 GC file present.
Have you guys considered adding perfume to the CD envelope, to try to raise a little capital from
advertising to offset your costs? "C perfume, for the programmer in every man," "L'Air du Comp, as
fresh as a new CPU."
My copy of develop arrived in my P.O. box this morning and therein lies the problem. In its
original shape develop will not fit into my P.O. box so its shape was altered to make it fit. The CD
is warped, and try as it might, the Finder TM cannot make the "minor repairs" it says are needed.
Unfortunately, we out here on the frontier don't have someone to bring our mail to us each day; we
have to go fetch it--and pay for the privilege. So I'm stuck with the U.S. Postal Service and an
Perhaps a large "DO NOT BEND"
on the outside of subsequent issues
will avert deformation. Then again, maybe not. Would you kindly use
your considerable influence to get
me a flat CD?
And if the printed warning doesn't work, how about a steel plate in each issue? Make that a really
stiff steel plate. You know how those Postal Service people are--neither rain nor snow nor CD. . .
Sorry about that mangled CD--pushing the limits on information distribution sometimes we run into hassles
like how to actually get the information into the hands (and drives) of the folks that need it. Hopefully our
"DO NOT BEND" notice will help because I'd sure hate to have to resort to a steel plate.
f in fact, the warning doesn't help, you
can contact the fulfillment house (see the subscription order form at the back of the issue for contact
information) and tell them that your CD was mauled; they'll
be happy to send you a new copy.
In response to recent concern regarding the ecological soundness of your page layout, I have the
CD-ROM and electronic magazines are examples of technologies that--provided they are adopted--
are ecologically superior to more traditional media,
such as paper.
develop is encouraging the adoption of these new media, and thus can easily defend its spacious page
layout. It is
one of the few publications that
can have a positive environmental impact--provided that developers absorb and act upon its
Incorporating these new technologies into useful products is the first step toward their eventual
widespread adoption. By keepingdevelopeasy-to-read, you are encouraging this trend.
P.S. Providing an e-mail address
for comments would also decrease
Thanks for your words of encouragement. Pushing CD distribution is one way we're trying to get away from
killing forests; using recycled paper is another. Our production manager, Hartley Lesser, found a paper that
meets our quality standards, that doesn't use toxic chemicals for de-inking, and that's available in the
quantities we require. This issue is the first one printed on the new paper--let us know what you think.
Also, we are now even more available electronically (although Dave's much more connected than I am), so if
you'd rather send e-mail, feel free to use the addresses
May it be known by you and your wonderfully talented crew how very much I appreciate your
efforts on behalf of creating the wonderful, informative, interesting, entertaining, and otherwise
"slick" magazine, develop. The opportunity to see what others are doing, who those others are, and
perhaps to learn more than you would from MacWeek , but less than from Inside Macintosh, is indeed welcome.
Add to this the fact that you include a CD-ROM and I am hard-pressed to even IMAGINE a more
valuable offering. Great job. Thanks a zillion!!
I noticed that Apple is looking for a
new editor-in-chief for the major publications. You're not going anywhere, are you?
--A concerned reader
First of all, believe it or not, I did
not make up this letter (or even the signature). Our group (Developer
Technical Communications) recently reorganized and now my grouplet is responsible for not only develop, but
also technical updates (like the Q & A stack), Technical Notes, Sample Code, and reporting compatibility bugs
to developers. Since I need to spend my time doing the things that managers do, I'm looking for someone to do
all the real work. If this sounds fun and you think you'd be
qualified, let me know.
COMMENTS We welcome timely letters to the editors, especially from readers wishing to react to articles that we publish in develop.
Letters should be addressed to Dave Johnson or Louella Pizzuti at Apple Computer, Inc., Developer Programs, 20525
Mariani Ave., M/S 75-3B, Cupertino,
CA 95014 (AppleLink: Johnson.DK or Pizzuti1).
All letters should include name and company name as well as address and phone number. Letters may be excerpted or
edited for clarity (or to make them look like they say what we wish they did).*