The Editor’s Page

By Scott T Boyd, Editor

Twice As Much Booger Glue In This Issue

As you’ve no doubt already noticed, this issue contains both an OpenDoc and an OLE CD. That takes twice as much glue as we used in our August issue, which had just one CD. This continues our efforts to keep you abreast of developing technologies. We’ve thought about taking sides in this technology battle, but we’re not going to. First, we believe that you can decide which, if either, technology best suits your needs. Second, we don’t believe that it’s an either/or choice. Finally, both technologies have the backing of companies with the resources to assure their success. We believe that both OLE and OpenDoc will endure in the marketplace. Enjoy the CDs, and please let us hear from you about your experiences.

EvenBetterBusError Caveat

Some of you have reported some interesting experiences with EvenBetterBusError (EBBE) and PowerBooks. This is a well-understood phenomenon, and I should have mentioned it previously. The short of it is this - EBBE and PowerBooks may not get along. The long of it is this - PowerBooks have the ability to “sleep” the processor to save battery. Also known as power cycling or rest mode, the Power Manager shuts off the CPU for periods of inactivity, waking it up quickly when it sees signs of activity (e.g. mouse movement, keystrokes, and such). Without power, the CPU loses its state, so PowerBooks have code to store the CPU state on the stack. That’s fine, but how does it find the stack when power is reapplied to the CPU? The processor expects to find the SP and the PC at 0 and 4, respectively, so the Power Mgr writes those values there before shutting off the CPU.

Now, given that EBBE was written prior to the release of the first PowerBooks, and since it was written one floor up and about 100 feet away from where the PowerBook software was written, you might expect that PowerBooks would know about EBBE, and would save and restore the 8 bytes at zero around each sleep cycle, or even just the 4 bytes at zero. Well, sorry to say, but the PowerBook team hadn’t heard of it (I still vividly remember, “What’s EvenBetterBusError?”), so EBBE winds up reporting “Write to NIL” a lot on PowerBooks. (Quick reminder: that’s because EBBE watches the 32-bit value at 0 with a VBL task to see whether 0 has been changed from the value $50FF8001 that EBBE put there in the first place).

The ROMs were nearly final by the time we realized we had a problem, and it was only with a debugging tool, so they didn’t fix it. We considered a patch, but rejected it when it became clear that a patch could disturb the very carefully-timed wake up code and cause dropped incoming AppleTalk packets.

Bad news, right? Not as bad as it could be. You can turn off resting on PowerBooks. It chews up batteries, but lets you test your code, and that can often be done while plugged in.

It does raise a question, though - what kind of behavior does NIL-non-savvy software exhibit when it gets the value of the rest-time stack pointer out of location zero each time it dereferences NIL?

Strange Bedfellows

Who would have ever thought that Apple would willingly team up with IBM to sell machines? There was a time when many thought that droves of employees would walk right out the door should such a thing happen. But the Intel/Microsoft WinTel domination serves as a powerful motivator. It was enough to convince IBM, Apple, and Motorola to team up to build the PowerPC chip family, and now they’ve taken it one step further and agreed to design a family of PowerPC machines that they’ll build, sell, and run their operating systems on.

While the announcement covered hardware, almost nothing was said about software. IBM reportedly wants to reassure their OS/2 user base that they are solidly behind OS/2. Motorola seems to believe in Windows/NT. Apple continues to ride the Macintosh wave. All of these existing allegiances notwithstanding, keep your ears open for possible collaboration on the operating system front. With Apple’s plans to license Mac OS, the only licensee we don’t expect to see is Microsoft.

Unclear On The Concept - Next Topic

When you ship software to customers, do you ever intentionally put them at risk? Sounds silly, doesn’t it? Yet, that’s what at least two major software vendors have done recently by shipping software that relies on undocumented and unsupported features of Apple’s system software.

Apple’s programming interfaces don’t cover all the ground that Macintosh programmers need to cover. Most of the time programmers compensate by writing new code or reusing code from past projects, sample code, or a third-party source library.

Sometimes a programmer will say, “Hey, you know, Apple must have something like this in the system somewhere that they just haven’t documented. I’ll go figure out how they do it.”

Such a thing happened during the development of System 7.0. Apple determined that resource compression would make it possible to fit enough of 7.0 onto the Install 1 disk to be able to boot from the floppy. That’s pretty important to be able to do, so a few engineers sat down and solved Apple’s problem by building a mechanism to transparently decompress resources as they were loaded from disk. This mechanism became known as the dcmp mechanism because of the new resources of type dcmp which did the bulk of the work.

Inquisitive developers with similar needs (to squeeze lots of stuff into a little space), noticed what Apple was up to. One of these dropped me a note after figuring out how it all worked. He had even built his own decompressor to try his hand at beating Apple on size and speed.

We talked, and I pointed out that the workings of the mechanism were not public, nor supported. That’s because we (Apple) had done only enough testing to ensure that it worked for the things that we were using it for. We hadn’t done the testing that any public API necessarily goes through before publishing the interface. There wasn’t time, there wasn’t money, and we weren’t even sure that we liked the mechanism well enough to keep it beyond 7.0.

This developer decided, after mulling it over for a couple of days, that it was too risky to use dcmps in his software. If Apple changed things, his customers would be the ones with the problem - Apple might need to change it in the future, and it didn’t make sense to put technological handcuffs on Apple just for this. Besides, with a little thought, he had come up with a completely different mechanism, one which would work fine no matter what Apple chose to do for compressed resources.

Two years ago, while I was still on the system software team at Apple, this magazine ran an article by Justin Gray entitled Resource Compression - What it is, how it works, and how to use it in your own software. The article was based on his experiences using dcmps in some of his software. I called the Editor, and we had a little “talk”. He got an earful, and learned that publishing unpublished Apple internals was, shall we say, problematic. Neil says that his ears are still ringing from that “talk”. (Little did I know where that conversation might lead - I learned that I have to be careful what I complain about!)

It’s one thing to learn about how the Macintosh works. It’s quite another to expose customers to the risk that their software may crash when they upgrade systems simply because someone chose to use an unsupported internal mechanism when others were readily available. At the start of this tirade, I mentioned two companies which had recently shipped dcmp-dependent products. I spoke with one of them before they shipped. Here’s a message to them: “Shame on you! You had alternatives that were well-tested and immediately available, yet you chose not to use them. Will your customers understand when they crash?”

If anyone is looking for resource compression that works without relying on unpublished and unsupported code, e-mail me at editorial@xplain.com. If you have such a product available, let me know, and I’ll add you to the list of resource compression vendors that I send to those who ask.

Virtual Corporation Enabler

IRC stands for Internet Relay Chat. If you’ve ever participated in an online group discussion, you’ll have a pretty good idea of the nature of irc. It runs on many servers on the Internet and maintains the illusion that each server participates in all of the many discussions. Tonight, for example, my irc server said, “There are 2876 users and 1931 invisible on 111 servers, 77 :operator(s) online, 1529 :channels formed, I have 139 clients and 1 servers.” I use Homer (available on your favorite info-mac mirror site) to join in with the few thousand folks online.

So you can go chat. Big deal, right? It can be if you’re one of the growing breed of work-at-home members of virtual corporations. Having my home office on the Internet lets me carry on conversations with coworkers in any of the virtual companies I’m a part of. It cuts phone costs, and is more interactive than e-mail. IRC also allows direct file transfers.

A few of us on a recent MacHack planning conference call used irc take one-on-one conversations off-line so we wouldn’t disrupt the meeting. It was also a great place to crack jokes.

It’s possible for others to listen in on your chats, so be forewarned. Much of the necessary communication between virtual coworkers runs towards the mundane, so the tool can still offer quite a bit of utility. If you’re already on the net, it’s a cheap and useful addition to your suite of net tools.

Food For Thought

Apple now has an infomercial. Microsoft is showing feel-good commercials. Neither shows an 800 number for taking orders.