| Volume Number: | 11 | |
| Issue Number: | 10 | |
| Column Tag: | Viewpoint |
Viewpoint 
By Scott T Boyd, Editor-at-Large
What is Copland? Just the other day I was trying to explain it to someone, and found that I was stumped. It’s not that I don’t know about the feature set. That’s easy enough. For example, here’s what Peter N. Lewis recently offered as a quick summary overview on the Semper Fi mailing list. First, for developers:
• Preemption
• Memory protection
• Threaded file system
• Server processes
• Replacement system extensions
• QuickDraw GX and OpenTransport built in
And for users, Peter listed:
• Threaded file system
• Fancy new Finder
• Appearance Manager
• Native speed
Preemption and memory protection, well, you just have to have those in a modern operating system. At least that’s what the pundits have been teaching for some time. Besides, NT, OS/2, and Windows 95 all have it. Why doesn’t Macintosh? Technical merit aside, the lack of these two items makes it harder to sell Macintosh, so having them should help.
We also know that we all spend too much time blocked, waiting for the file system to finish what we last asked it to do so we can get on with the next thing we want to do (phew, all in one breath?), so a threaded file system should be a great thing, too.
Support for server processes has to be great for people writing server software. No argument there. And, since we’ve been told that the current mechanism is terrible, getting rid of the extensions mechanism (breaking existing extensions in the process) and replacing it with something new will give us what we need - a stable Macintosh with no extension conflicts (that’s what we’re told).
I mentioned above that I was having trouble explaining the essence of Copland. The reason? Because I couldn’t figure out who it’s being built for. I suspect, but don’t really want to admit, that it’s being built for a bunch of unix-head computer science types rather than the millions of computer users (present and future). The Copland feature set may be essential for effecting a rearchitecting of the Macintosh, but it’s solving the wrong problems. In fact, it’s solving some things which aren’t problems.
Apple needs to be fighting for its life, not doing a course correction towards server operating systems.
What do people want? To begin with, people want an interface that’s multitasking. Unfortunately, Copland does very little to make this happen.
People also want a system that doesn’t go away when something crashes. Copland protects portions of the system, and it also protects server tasks that have been spun off into their own threads and spaces. Unfortunately, the user interface toolbox is not protected. One crashing application still has the opportunity to take down all of the other applications, and all of the user’s unsaved work with it. As Andrew Donoho has said, “All the protection for background server processes in the world does not bring that data back.” The fact that the machine didn’t go “Bing!” will be of little consolation to the poor user who just lost all of their work. If a user had to choose, do you think they would rather lose the servers they’re hosting, or the applications they’re running?
Do As We Say, Not As We Do
The typical Macintosh user doesn’t know what the Finder is. It’s not that they don’t know how to use it, they simply don’t know what it’s called. It embodies what they think of as the machine itself, “The Macintosh”.
Users have long wondered why they can’t do “Finder things” in their applications, and why they had to go somewhere else to do them. Developers have long wanted Finder functionality in their applications.
Is Apple serious about meeting the needs of the user?
Is Apple serious about the marketing messages they are sending to developers?
With the advent of OpenDoc, Apple has the opportunity to ship something that hits both of these needs right on the head - the OpenDoc-savvy Finder. Each piece of the Finder needs to be an OpenDoc component so that other applications can embed them, lending 100% Finder-fidelity to their software.
In addition, the Finder needs to lead the way as a premiere embedding application. SimpleText can and should go away and be replaced by editors and viewers for text, pictures, QuickTime movies, clippings, sounds, etc .
Here is an opportunity for Apple to take its own advice, and do as it says, not as it often does. Apple’s efforts to convince you, the developer, to adopt OpenDoc technologies surpass many of their efforts on other technologies. They’ve put out CDs, they’ve made countless presentations, they’ve formed a large consortium, and they tell us that they’ve bet the farm on OpenDoc. It remains to be seen, however, whether Apple will follow its own lead. Perhaps they’re keeping it under wraps, but if they’re not, they’d better getting to work on turning the Finder into the premiere showcase for OpenDoc.
It’s fine to attempt to improve the overall architecture, but let’s not forget to get some solutions to solve user problems.
Food For Thought
“The ROM is a big place, Steve.” - Allan Foster
“RAM’s even bigger.” - Steve Kiene
In response to “CNN just announced that there were
8 million copies of Windows 95 sold since 12 midnight !!!!”:
Those guys are like arthritis patients. They’ll buy anything if
they think it’ll finally stop their pain.
- Todd Blanchard, SuperTodd@eworld.com
