Mar 95 Viewpoint
- Jan 95 Viewpoint
- Feb 95 Viewpoint
- Apr 95 Viewpoint
- May 95 Viewpoint
- Jun 95 Viewpoint
- Jul 95 Viewpoint
- Aug 95 Viewpoint
- Sep 95 Viewpoint
- Oct 95 Viewpoint
- Nov 95 Viewpoint
- Dec 95 Viewpoint
Volume Number: 11
Issue Number: 3
Column Tag: The Editor’s Viewpoint
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