LETTERS%
RThanks for the excellent article in the October 1990 issue of develop dealing with1
Rpolymorphism in C++ stand-alone code resources. I have one question about the code=
Uthat accompanied it on the disc; it concerns the file WindowDef_main.cp: why are theI
Soverloaded "new" and "delete" operator definitions bracketed by the #ifdef NEEDEDU
Sand #endif statements? Is NEEDED defined somewhere else? (I couldn't find it in anya
Tof the other files on the CD.) Are there circumstances in which you wouldn't want tom
Noverload the storage operators for a window definition function? I'm confused.y
--Carlos Weber, M.D.
.Yahoo, a technical buck to stop! Lemme at it!
SThe code in question (#ifdef NEEDED... #endif) shouldn't be there at all, and as a
Wmatter of fact is ignored by the compiler, since NEEDED isn't defined. It is left over
Cfrom when Patrick was developing the code and still experimenting.
XIn the final version he is basing his WindowDefinition class on the Relocatable class,fl
Owhich is in turn based on HandleObject, an Apple® extension to C++ which usesÎ
Yhandles instead of pointers when allocating space for new objects. No overloading of the˜
storage operators is necessary.
WSorry about the confusion. I should have spotted that code and yanked it out before we
published.
--Dave Johnson
NIn develop, Issue 4, you advocate installing DRVR resources at startup time by
Nchanging their resource ID to an empty slot in the Unit Table and then calling
7OpenDriver rather than use _DrvrInstall due to its bug.
TThe problem with this method is that it actually modifies the DRVR resource, which
Uhas two consequences: 1. According to Apple you are not supposed to modify yourself;
Zand 2. it sets the last date modified field on the file. This latter problem causes backup
Tprograms to think the file has really changed and it worries users that perhaps some
9virus has modified that file when they know they didn't.
VThus, in my opinion, it is much better to use _DrvrInstall and, until Apple fixes the
Pbug, stuff the DCE yourself. This method does not suffer the side effects of the
OpenDriver method.
--Jeff Shulman
YYou're right, it's easier to use the method outlined in my article, but it's "better"to
Wuse _DrvrInstall and manually put the pointer to the driver into the appropriate field
in the DCE.
--Tim Enwall#
UI have a question about the article on the 8*24 GC card in develop, Issue 3, which,/
Tincidentally, was excellent. On pages 338 and 339 you mention the files that must be;
Qpresent to use the card. Is the GC file a transparent patching upgrade or is it aG
Psupplemental code block that duplicates all of the 32-Bit QD file functionality?]
Good luck with Dogcow breeding,i
--David
SThe 8*24 GC file contains more (and less) than just the 29000 equivalent of 32-Bit
SQuickDraw TM; it also contains the IPC software that steals QD calls and transfers
Vthem to the card, the shell (GC OS) that receives the commands and dispatches them as
Uwell as doing the Memory Management chores and such, and finally the 'drawing' parts
Oof 32 QD. Note that calls that do not cause any drawing to take place, such as
RNewGWorld, are not part of GC QD but are executed by the main processor even when
accelera