Dialog Box

By Scott T Boyd, Editor

EvenBetterBusError Again?

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, 72257.2213@compuserve.com

This Is California, And It’s 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?

That’s what I did. With an Ascend router, I get ISDN into my local Ethernet, and we both have high speed access. Whee!

- David Ramsey, ramsey@be.com

Another Bug?

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, don’t 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 doesn’t mean I have to give back the “tip of the month” money for that one, ’cuz I already spent it!

- Lee David Rimar

FTP’s A Good Idea, But

I’d 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. I’ve 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, malirath@zilker.net

Develop and MacTech Editors Read Each Other

In response to Steve Kiene’s letter in the December issue:

I enjoyed Steve Kiene’s well-written letter to MacTech in the December issue - even though I’m the editor of Apple’s 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 company’s 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 you’re a develop reader :- )

Regards,

- Caroline Rose, CROSE@applelink.apple.com

List Versus Object In Smalltalk

Kevin O’Neill wrote:

I managed to get the time to read your article in MacTech last night. It was great and I hope to see more.

I’d 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 wasn’t 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., quasar@qks.com

EvenBetterBusError Yet Again (EBBEYA)

The wrath over EvenBetterBusError (Editor’s 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, it’s 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 can’t the functions of all such debugging aids be bundled with the tools themselves, in a simple-to-use format? Why don’t 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 isn’t 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. shs@mcs.com

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, it’s cheap at twice the price.

Second, I’ll cop to playing the role of thought police. Somebody has to do it. Apple sure isn’t, 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 we’re 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, let’s 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 Apple’s CDs, as well as our online sites. Sure, their documentation isn’t great, but at least it exists to some degree. I’m sure you didn’t mean to put them down, but, having been there when these tools were written (and having written the beginnings of one of them myself), let’s 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 wouldn’t 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. It’s nearly impossible to make some of these classic mistakes with an environment like STA.

Finally, I’d say that it’s time to put some blame on Apple. Isn’t it time that they develop a system which makes it nearly impossible to make these kinds of mistakes? Now that we’ve had a decade’s worth of experience, don’t we have a pretty good idea what the common mistakes and failure modes are? Couldn’t 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 developer’s job easier, safer, and more rewarding?

- Ed stb