![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/images/you_are_here_red.gif)
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/default/files/beta-site.gif)
LETTERS
I just wanted to let you know that I have found both issues of d e v e l o p to be extremely useful.
You do an excellent job in picking up where Inside Macintosh leaves off. I hope Apple continues to
publish d e v e l o p for a long time.
-- Paul Higinbotham
Of all the technical journals I receive about the Macintosh, Digital VAX, and computing in general,
all pale in comparison to your d e v e l o p . Please send me a copy.
--Steve Salika
In your last issue, Curt Bianchi tells me to beware of how the Memory Manager grabs my Pascal
object's handles. Then, in another article, Richard Clark tells me that the Memory Manager has a
secret life and that I should be careful when I pass it pointers. My question is, should I ask the
Memory Manager to take a blood test before we get serious?
--Concerned in Palo Alto
Although you are right to be cautious about getting serious with the Memory Manager, there is really no need
for a blood test. The very articles that you mention present clear guidelines for having safe yet fulfilling, uh,
"interactions" with the Memory Manager. These guidelines, judiciously and conscientiously (and
enthusiastically!) followed, provide all the protection you
will need.
--Dave Johnson
After using both on-line documentation and hard copy for a while, I prefer hard copy. It is easier to
read, and more immediate. I like the concept of having complex and interrelated documentation on-
line with cross referencing a click away. When you obtain instant response time, on-line
documentation will
be invaluable.
--Thomas Bernard
STEPS FORWARD
Thanks for all the fantastic work on d e v e l o p --I love it, and being
an American abandoned in England,
it is one of the most informative journals I get over here. I do have a couple of gripes (read,
"winges" in England) about the software used to display the articles.
The control panel windoid is a complete pain--it doesn't fit on a 13-inch monitor without obscuring the text window unless you move it halfway off the screen, so you have to be continually moving the panel around the screen. I then decided to print out some of the articles, but that isn't much easier, because you either have to know the page where each article begins, or navigate there one page at a time.
It would be nice to see a control panel which is vertically oriented so that it can fit along with the text
window on a 13-inch screen, and to also include a button which jumps to the next article--moving to
the first and last pages is not really that useful. I think it would also be much more useful if the
text for each page fit in a window rather than having to scroll each window as well as forward each
page.
--David L'Heureux
As you know, we're entering an era in the Macintosh world that revolves around electronic publishing. Many of the standards and interfaces that are so well defined in the Macintosh desktop metaphor don't exist when you're creating interactive electronic magazines (Hyperzines). Developer Essentials is a living document. It will continually grow and change as we begin to determine what works (and what doesn't)--things like how you use sound, how and when you should animate an icon, what's the best use of color, where is the best place within the virtual magazine metaphor to put a control panel windoid and have it not be a complete pain. Ya know, things like that.
The reason we've put the automatic feedback capabilities into d e v e l o p is to get your ideas, criticisms, and thoughts. We don't have all the answers and will be experimenting with new ways of representing data. We hope to have more defined and stable human interface standards regarding the use of electronic media like CD-ROM in the near future. In the meantime, look for experimentation, a few mistakes, and some very open minds looking to you for feedback and suggestions here at Apple.
--Scott Converse
Electronic Media Group Manager
Issue 2 of d e v e l o p is great. The articles are fun, informative, and well written. I think you are off to a great start.
But I must strenuously object to your rampant waste of paper for the sake of "design." Almost every page has at least 25 percent white space; many have more. I don't know if you have an aversion to trees or just a lack of concern for our children, but your choice in this matter does not reflect Apple's generally ecological view. Apple is a leader in reducing waste in manufacturing, but you insist on creating waste in your magazine.
Please, please take a look at redesigning your pages for future issues. Apple's publications are often
very well designed, but yours is the only one that screams "paper waste"
on every page. It is an easy step that will help the whole world.
--Paul Hoffman
I'm looking into using recycled paper for d e v e l o p (in fact, it started out as a requirement for the first issue), but I've run into conflicting information. I recycle my paper (both here at work and at home) and am actively looking for ways to help d e v e l o p fit into the ecological scheme of things. Our printer recycles all of the waste (generated from printer make-ready, and overages), and the paper we print on, like most paper these days, has a recycled component. Some people I've spoken to advocate recycled paper as the answer to all of our problems; others contend that the chemicals used to de-ink the paper damage the environment more than they help to save it. If you've got ideas about whom I could talk to to hear the real scoop on recycled paper (from environmental impact to lasting qualities), I'd love to hear them.
Meanwhile the page design is intended to leave room for notes (which many developers have told me they make), and for readability. The column widths must allow for full-page width code listings but must also work with readable line lengths. I'm sorry that it screams paper waste to you, and I will talk to our designer about ways in which we might adapt the design.
--Louella Pizzuti
STEPS BACK
When we find technical errors in previous issues of d e v e l o p (or when you point them out to us), we make corrections in the text and code for the current Developer Essentials disc. You can also find corrections in this section of the journal.
So far, we want to let you know about these changes:
On page 75, the abstract should read "Through the Slot Manager system software, the Macintosh can read the declaration ROMs in NuBus slots and processor slots, like those in the Macintosh SE/30. This article tells you what you must know about NuBus addressing and the structure of correct declaration ROMs to successfully debug the ROM. It walks you through the structure of an example declaration ROM and gives common errors and strategies for debugging declaration ROMs."
On page 91, "Assuming the board is in slot $B, the above format block (residing on byte lane 3)" should be byte lane 0.
On page 149, the procedure MyVScrollCallback
appears twice. The second one should have been MyHScrollCallback
, as indicated in the comments. Thanks to Sam Roberts for pointing this one out. For those of you who didn't even notice, shame on you.
There was a pair of bugs in the "Heap Demo" source code distributed with Issue 2 of develop, one of which prevented the source code from compiling. The Developer Essentials disc contains a corrected version (HeapDemo 1.3.4) In order to compile the old code, you should remove the reference to "UMonitor" at the start of HeapDemo.p. The UMonitor unit is a debugging tool that was used during the final checkout of the Heap Demo, and though I removed the calls to its code, I forgot to remove the USES reference.
The other bug was in the menu enabling logic. With the bug, you could crash the program by closing the memory window, and deleting all blocks. The menu enabling logic has been changed to fix this problem. Thanks to the diligent readers who pointed out these problems. I'll make sure you have more articles to nit-pick in the future!
--Richard Clark
COMMENTS We welcome timely letters to the editor, especially from readers wishing to react to articles that we publish in develop. Letters should be addressed to Louella Pizzuti, 20525 Mariani Ave., M/S 75-3B, Cupertino, CA 95014 (AppleLink Pizzuti1). All letters should include name and company name as well as address and phone number. Letters may be excerpted or edited for clarity and space.
SUBSCRIPTION INFORMATION Use the order form on the last page of the journal. Please address all subscription (and subscription-related) inquiries to
d e v e l o p
Apple Computer, Inc.
P.O. Box 531
Mt. Morris, IL 61054 U.S.A.
AppleLink Address: DEV.SUBS
![](/file/12652/www.mactech.com.tar/www.mactech.com/sites/all/themes/custom_front/img/search_text.gif)
- SPREAD THE WORD:
- Slashdot
- Digg
- Del.icio.us
- Newsvine