Feb 95 Dialog Box
|Column Tag:||Dialog Box
By Scott T Boyd, Editor
Your printed copy of EvenBetterBusError in the December issue has a bug. Your constant SizeOfCodeBlock is computed to include only the code, but then is used as if it contained both the code and the constant BuggyCodeWroteToNil. The effective address of the PEA just before _DebugStr in the VBL task is outside the system heap block you obtained with _NewPtr.
Check it out. The effect is that after legitimately dropping into the debugger, one might see almost anything as the debugging string, hardly helpful!
Fix it by moving the EndOfCodeBlock label after the DC, not before. Does your assembler complain about labels with no contents? Fix that by putting another dummy DC after EndOfCodeBlock.
I wish we could ignore the dumbbells who claim their bugs are caused by the detection mechanism, but what if one needs their software!?!
- Emerson Mitchell, firstname.lastname@example.org
[Yes, indeed, its a bug. Its also missing an ALIGN to get it on a nice boundary. Thatll teach me to assemble and link without actually installing and running. Another lesson learned. Thanks for the correction. As for the dumbbells, we cant fix them, but a whole lot of folks now know to use EBBE when testing software (theirs and others). The culprit that I wrote about has already rewritten chunks of their product and has a new appreciation for low-level debugging tools. If you see other software that could use fixes along these lines, please drop us a note - Ed stb]
This Is California, And Its 1994
Scott, 14.4K Internet access? Why bother, when PacBell will install an ISDN line in your home for less than $100, and companies like Internex will give you ISDN access for $49/month?
Thats what I did. With an Ascend router, I get ISDN into my local Ethernet, and we both have high speed access. Whee!
- David Ramsey, email@example.com
[That sounds terrific, but I want to host my own Internet services (Web server, ftp site, and so forth). I can do those now, albeit slowly, with my constant 14.4K connection. A constant ISDN connection in this area would run more than three times what Im paying now. ISDN equipment costs substantially more than my cheap modem, too. Ascend routers get you up and over the $1000 mark pretty quickly. Of course, these reasons dont mean Im not jealous! - Ed stb]
I just discovered a nasty gotcha in a tip I submitted to MacTech, which was printed a few months ago.
If you hack a folder alias with ResEdit to look as if it were an alias to the Desktop Folder, dont ever ask Finder to Get Info... on the hacked alias and then try to Find Original. If you do, Finder crashes; dramatically or quietly, depending on its mood at the time.
I hope this doesnt mean I have to give back the tip of the month money for that one, cuz I already spent it!
- Lee David Rimar
FTPs A Good Idea, But
Id like to thank you for maintaining an ftp-site, and a net-presence in general. I would, however, encourage you to seek a mirror site. Ive had very little luck connecting to ftp.netcom.com. And most of the few times I have been able to connect, the response time has been unbearably slow.
- Robert Fisher, firstname.lastname@example.org
[We dont know whats up with Netcom, but were not happy with it either. Well be getting our own site online sometime soon. Thanks for the suggestion about a mirror site - well keep you posted - Ed stb]
Develop and MacTech Editors Read Each Other
In response to Steve Kienes letter in the December issue:
I enjoyed Steve Kienes well-written letter to MacTech in the December issue - even though Im the editor of Apples own technical journal, develop. We try not to make develop a Stars and Stripes, feel-good magazine either, although we do need to push the companys technology direction a bit to avoid incompatibilities for developers down the road.
My forthcoming editorial in Issue 21 of develop is on the subject of my own emotional attachment to the Mac, so I especially enjoyed the paragraph on your similar attachment. I hope your attachment remains - and that youre a develop reader :- )
- Caroline Rose, CROSE@applelink.apple.com
List Versus Object In Smalltalk
Kevin ONeill wrote:
I managed to get the time to read your article in MacTech last night. It was great and I hope to see more.
Id like to know more about how you decided to use a list to store the drag data rather than an object of a specific class. I found myself flipping back to the stop where you defined the list so that I could be sure what was being referred to in the various data@x statements.
Actually it turns out that we should have used a subclass of <List> which we call a <DragPackage> class. At the time it wasnt clear whether it would be a private data structure for use among a few objects, or whether it would have a public/client API. Since the time that article was written we have concluded that there really should be some behavior attached to the drag-data to enable it to serve a more general usage.
:-) That was good instinct/observation on your part...
Thanks for the comments and feedback.
- Dave S., email@example.com
EvenBetterBusError Yet Again (EBBEYA)
The wrath over EvenBetterBusError (Editors Page, November 1994) is directed to the wrong target. The typical Mac developer, struggling against all odds to earn a living from a platform intentionally restrained to single-digit shares of the business market, is not helped by the thought police yelling bonehead and liar at him. Anyone who says of a block of 68K code, As you can see, its pretty simple is well out of touch with the real world of business applications programming.
Rather than excoriate the poor developer, why not direct your flame towards the source of the problem, the tool developers? EvenBetterBusError is just one of a scattered set of poorly-documented, poorly-designed and poorly-distributed hacks, each of which is intended to address some gaping problem in Mac development tools. Why cant the functions of all such debugging aids be bundled with the tools themselves, in a simple-to-use format? Why dont more development environments automatically (or optionally) check for such detectable nefarious acts as using DisposeHandle on a resource, dereferencing NIL, or calling DisposeHandle twice? Why isnt a simple, high-level form of Discipline standard with all languages? Finally, why do toolmakers treat source-level debugging as unmanly, and therefore of no interest? Some of these hacks give results in a machine level so low as to be useful to only a smattering of programmers - I guess that leaves the rest of us as boneheads.
Think Pascal was (as is) fairly good on some of these issues, so why have more recent environments taken steps backwards from that level of assistance? It should not be necessary for the beleaguered Mac developer to conduct a fishing expedition through CDs and online sources to find all of the hacks needed to fix the obvious omissions of the development environments.
- Kevin Killion Stone House Systems, Inc. firstname.lastname@example.org
[Thanks for your excellent letter. A few thoughts came to mind while I was reading your letter, and here they are - Ed stb]
First, someone has (as you may have already noticed in the December issue) put a bunch of the tools together in the form of QC. They brought together many of the tools, wrapped them together in a nice package, and are doing what they can to get them out to developers. At $100, its cheap at twice the price.
Second, Ill cop to playing the role of thought police. Somebody has to do it. Apple sure isnt, and, as you pointed out, neither is Symantec or Metrowerks. The aspersions were cast at a vendor who chose to blame the tool rather than address their serious, yet known bug. Ignorance is one thing, but blaming EBBE was a wrong thing to do.
In a followup conversation with that particular vendor, the product manager told me that he was horrified once he had read my editorial. The right thing has happened now - the product has been repaired, and were a little better off for them better understanding the situation, the available tools, and their responsibility to test their software with whatever tools are available.
Third, lets not blame someone for the existing tools being poorly documented and poorly distributed. Why? Greg, Bo3b, and others kindly and generously donated tools. Those tools are available on every online service and on Apples CDs, as well as our online sites. Sure, their documentation isnt great, but at least it exists to some degree. Im sure you didnt mean to put them down, but, having been there when these tools were written (and having written the beginnings of one of them myself), lets praise them for not only making us aware of the problems, but also giving us tools (albeit crude) to address the problems.
Third-and-a-half, the three principal problems that DoubleTrouble, DisposeResource, and EBBE address are problems that we (the System 7 team at the time) realized were bigger problems than we had known during the System 7 effort. Greg wrote the tools after he had debugged hundreds of incompatible pieces of software. Sometimes it just takes a while to realize the need for a specific tool. Without his debugging efforts, we still wouldnt have these tools.
Fourth, I totally agree that environment vendors need to provide more and better tools. Some vendors have. For example, QKS SmalltalkAgents knows about various classes of memory, allocates most things for you, and deallocates when your done. Its nearly impossible to make some of these classic mistakes with an environment like STA.
Finally, Id say that its time to put some blame on Apple. Isnt it time that they develop a system which makes it nearly impossible to make these kinds of mistakes? Now that weve had a decades worth of experience, dont we have a pretty good idea what the common mistakes and failure modes are? Couldnt we find a way to eliminate some of them? QKS has. Dylan does. NeXT has. Sun is working on it. Taligent has put a lot of effort into it. When is Apple going to step out and take a leadership role in making the developers job easier, safer, and more rewarding?
- Ed stb