Mar 95 Viewpoint
|Column Tag:||The Editors Viewpoint
The Editors 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, dont 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 - its got to be good. Make sure that stray writes wont damage anything else, and the machine will stand solid as a rock, impervious to the vagaries of programmer error and lack of foresight. Lets go march in front of Apples R&D center with placards, bullhorns, and riot police, and demand our memory protection now!
panacea n. a supposed remedy, cure, or medicine for all diseases or ills; cure-all [Websters New World Dictionary, 2nd College Edition]
Memory protection sounds so good, but its a panacea, a holy grail. Now, thats not to say that its necessarily a bad thing; far from it. Nevertheless, its not the solution. If it were, unix systems wouldnt crash, and wouldnt get corrupted, but they do.
What is the solution? Ill 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. Lets 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 theyre intact or corrupted.
Unknown crashes. Workaround - power down the machine for a few minutes. Reason - dont know, but it seems to work sometimes when simple rebooting doesnt.
Incorrect parameter RAM settings. Workaround - zap PRAM. Reason - bad settings can result in improperly configured hardware and software.
While this list isnt complete, lets see what we can quickly figure out about whats 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. Its hard to write system software, and thats 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 doesnt 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? Wouldnt 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 Ive 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 shed 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 glaciers movement as I (calmly?) said, NO! and rushed to avert disaster.
If only Id 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 its 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 its 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. Its 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 Apples code? Bugs in 3rd party code? Sure. Will protection help? Not really.
Whats the solution? Modernization, certainly. Memory protection is a good thing (holy grails are nice to have), but its going to be a while yet. And keep in mind what its supposed to protect against - flawed software that goes astray. And who writes it? We all do! Its time that we learn what mistakes were 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 youre sweating it out at your real job while developing your killer idea? Maybe youve 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, its 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