The Editor’s Viewpoint

By Scott T Boyd, Editor

I recently came across the following e-mail closing:

“(Anxiously awaiting a protected memory MacOS)”

We all know what he was getting at, don’t we? If only we had memory protection, life would be oh-so-much better. As often as we hear this, read this, and utter this, it must be true.

Memory protection - it’s got to be good. Make sure that stray writes won’t damage anything else, and the machine will stand solid as a rock, impervious to the vagaries of programmer error and lack of foresight. Let’s go march in front of Apple’s R&D center with placards, bullhorns, and riot police, and demand our memory protection now!

pan•a•ce•a n. a supposed remedy, cure, or medicine for all diseases or ills; cure-all [Webster’s New World Dictionary, 2nd College Edition]

Memory protection sounds so good, but it’s a panacea, a holy grail. Now, that’s not to say that it’s necessarily a bad thing; far from it. Nevertheless, it’s not the solution. If it were, unix systems wouldn’t crash, and wouldn’t get corrupted, but they do.

What is the solution? I’ll get to that, but for now consider this - fixation on a panacea can distract us to the point of missing real solutions.

The writer of the e-mail I mentioned above listed a serious of difficulties he experienced recently while trying to install and use a complex environment. He also offered his workarounds. Let’s take a look at the problems.

Crashes. Workaround - reinstall MacOS from scratch (clean install). Reason - system corruption from repeated crashes.

Corrupted files and file system. Workaround - run Norton Utilities, Disk First Aid, and so forth. A bad file system often gets worse, so fix problems early and avoid more damage.

Faulty system extensions. Workaround - remove suspect extensions. These can cause trouble whether they’re intact or corrupted.

Unknown crashes. Workaround - power down the machine for a few minutes. Reason - don’t know, but it seems to work sometimes when simple rebooting doesn’t.

Incorrect parameter RAM settings. Workaround - zap PRAM. Reason - bad settings can result in improperly configured hardware and software.

While this list isn’t complete, let’s see what we can quickly figure out about what’s happening here.

Problem: corrupted system file. Possible causes include:

• power or system failure during a write to the system file, due to “natural causes” or “human nature” (see below).

• power or system failure before the file system cache is flushed to disk, or while a file is open

• faulty hardware (SCSI termination, SCSI drive, cables, etc.)

• bad software changing the system file unintentionally or incorrectly.

Problem: file system corruption. Possible causes include all of the above, as well as improper use of file system calls (e.g. it would be bad to write directly to any of a number of system-owned files).

Problem: incompatibilities introduced by extensions. Possible causes are too numerous to mention. It’s hard to write system software, and that’s what extensions are - system software. Extendibility makes the Macintosh interesting, and it comes with a price.

Problem: Only a shutdown, power off, then restart solves problem. Typically caused by equipment problems (overheating, for example). Might also be that something needs to be reset but doesn’t except during a cold start.

Problem: configuration settings improperly set. Probable cause? Someone or something writing to PRAM unintentionally or incorrectly.

Back to the suggestion that protected memory will fix lots of problems - will it?

Will it protect the file system from corruption in the event of power failure? system failure? Wouldn’t that really require a robust file system? Perhaps a transaction-based system, complete with commit/rollback (like most databases do)?

Power failure comes in many forms. “Human nature” runs deep, and I’ve seen power failure result from inadvertent use of what looks very much like a floppy eject button on the front of certain models of Macintosh (e.g. my PowerMac 6100). My 18-month-old daughter, who seriously enjoys inserting floppies into floppy slots, one day put one into my 6100.

When I explained that it can only hold one, and you have to take it out before you can put another in, she decided that she’d better get that first one out of there. Without hesitation, she reached right up to push the floppy eject button. The next 60 ticks flowed by as slowly as a glacier’s movement as I (calmly?) said, “NO!” and rushed to avert disaster.

If only I’d had protected memory, right? A system design along the lines of a PowerBook (such as a soft power switch and battery backup) might prove more efficacious. (Of course, moving the switch elsewhere might work, too!)

Will memory protection defend against poorly-written system software? Having written some Apple system software myself, I can assure you that it’s entirely possible that Apple might accidentally ship some system software that has a bug in it. Not that I ever shipped any bugs (not on purpose, at any rate), but I did ship a few bug fixes, some for buggy Apple code, some for buggy 3rd-party code. Any errors in the system software may bring it to its knees, no matter what kind of protection is in place. Ever see a unix kernel crash? I have. Ever see the Power Macintosh memory-protected nanokernel crash? I have (three times yesterday, and twice today, unfortunately). Computers are complicated beasts, and it’s extremely tough to cover all the possibilities, memory protection notwithstanding.

Will memory protection protect against someone writing to the system file directly? Nope. How about protecting against someone adding or changing resources in the system file? Again, nope. Is it possible to protect the system file? Sure. One example is the Macintosh Classic, which can boot from ROM (just try to change that system file!). By the same token, anything that is protected by a software mechanism, yet offers an API for writing, opens up the possibility that someone may use it incorrectly. This same reasoning covers what happens with PRAM. It’s generally pretty difficult to write to PRAM without using the API. Yet we still see situations where the PRAM (or the CUDA, which handles serial on the AVs) gets incorrectly configured. Bugs in Apple’s code? Bugs in 3rd party code? Sure. Will protection help? Not really.

What’s the solution? Modernization, certainly. Memory protection is a good thing (holy grails are nice to have), but it’s going to be a while yet. And keep in mind what it’s supposed to protect against - flawed software that goes astray. And who writes it? We all do! It’s time that we learn what mistakes we’re making, and then teach each other about them, and then devise methods to avoid them.

Finally, Apple could help out with overhauled and/or new APIs which help us avoid common pitfalls. Such APIs could help by making errors harder to make (reducing the error modes), and by offering services so we can stop writing some of the same old code for the umpteenth time. And how about offering only the calls we need, and not a few thousand calls of everything you could ever think of?

On a Slightly Different Topic

So you want to start a company and you’re sweating it out at your “real” job while developing your killer idea? Maybe you’ve taken the big step and gone out on your own to bring the killer idea to market. Maybe, just maybe, it looks almost like a product. Now what do you do? Why, marketing, of course! And how better to start than by building a “presence”? Not every upstart could pull it off, but the odd assortment of Collaboration Technologies, Mark/Space Softworks, MacUp, Mac the Knife, and even Apple filled Bondage A Go Go with wide-eyed MacWorld show-goers to mingle and gawk at people in black/leather/fetish attire. As with many marketing efforts, it’s hard to know whether Mac Black ’95 achieved the desired effect, but no doubt remains about whether the attendees will remember it!

Food For Thought

Have Net, will travel! - Brad Kollmyer