Be Newsletters - Volume 2: 1997
Life used to be easy. There was one machine to support, and the guy who designed it worked down the hall. There was hardware with logic analyzer cables draped everywhere, revealing the most intimate details of how the missing bits were being dumped on the floor.
Be's foray into the Macintosh market has complicated life considerably. The Apple Developer CD has block diagrams for what boil down to seven different PowerPC-based machine architectures. Clone vendors have added their own riffs on the theme—multiprocessing hardware from DayStar, graphics controllers from ATI and IMS, PCI-PCI bridges, ATAPI CD-ROM drives, and the list goes on.
Many people have asked why the BeOS doesn't run on THEIR Macs. Given sufficient time, effort, and money, the BeOS could run on anything. In the end it boils down to a business decision—how hard will the port be, how much time do we have, how many machines are there, and will there be and what are the technical and marketing benefits.
With your indulgence of one paragraph of whining, I'll offer the following. We're a small team of engineers—sixteen software, four Q/A, three documentation, one build guy, and one-who-must-be-obeyed project manager. We're constantly trading off between supporting more machines with our current software and moving the BeOS architectural stake forward. (To say nothing of distractions like the van that just burst into flames in front of our office—comments that there may have been a PowerBook on the front seat are completely uncalled for.) We want the BeOS to run everywhere, but we still have to finish the !@#$ thing. Developers need a stable API to write to, yet they require a sufficiently rich feature set to add their magic touches to. Venture capitalists are eager for some return on their investment, and Be's checking account balance only seems to shift right (fortunately the sign bit isn't set).
In the upcoming DR9 release we're laying the foundation to support a wider variety of platforms. The new extensible file system architecture is the first evidence of this effort. On the low-level front, our intent is to distill the experience of porting the BeOS from Hobbit to BeBox™ to Macintosh into the specification of a hardware abstraction layer (HAL). Ideally it will be possible for a company to slap together a new computer, write a little firmware, and poof! a new BeOS machine is born.
The HAL isn't designed yet, so I'll do it here. It should address the following:
Firmware-kernel interface: How and where the firmware loads the kernel and passes information to the kernel
Processors: How other processors are started, and how the processors interrupt each other
I/O: Which processor(s) handle I/O interrupts, and how they're dispatched
Physical address map: Where the memory, I/O, busses, and ROM are, and how they're mapped into the BeOS logical address space
Configuration: What I/O devices are present
Power: Controlling power consumption, and restarting or shutting down the hardware
Shameless imitation is an option as well. Our friends in Redmond have solved this problem, as have other operating system vendors. No point reinventing the wheel...
With the decision to stop making the BeBox, Be has committed to the path of supporting Other Peoples' Hardware. This road isn't without peril -- there's an incredible variety of hardware out there, all developed to work with some other operating system. We face a formidable challenge in propagating the BeOS across as much of this hardware as possible, while still improving the BeOS architecture. Time to get back to writing code.
So I was over at Nanny Jan's this morning trying to figure out the appropriate Georgism to introduce this week's article. As I was dropping off Yasmin, I found this toy on the table. It was some super destructor battle cart thingy that had a winch with string that was all tangled around it. Being the father that I am, I proceeded to try to unravel the string and restore the toy to its original place in the hierarchy of devices of mass destruction.
I struggled for a while, pulled here and there, managed to get quite a long way. Then I found that if I used a needle, it was a lot easier. Then it seemed I had come to an impasse. The work was too intricate and too tight, and I couldn't really see what I was doing. So Nanny Jan, in her infinite wisdom, asks me, "Should I turn on the light?"
One of the most fun things about being a pioneer on the bleeding edge is that you get to blaze new trails, creating a path for others to follow. The most successful pioneers didn't necessarily invent completely new wagons and horses in order to blaze the trail, but they used the tools at hand and improved upon them. As a programmer, I'm a scrounge. I've long since found that if someone has already created an algorithm or data structure that suits your needs, it's probably better to start from there rather than from scratch.
I'm continually amazed at the neat things that programmers do, and it's particularly amazing when someone explains a new algorithm or routine to you in such a way that the light turns on in your head and you think, "it's so obvious, I knew it all along." Well this week I choose to delve into my sordid Objective-C past and pull out what I've found to be quite a useful tool.
Way back in the days of Mission Critical Custom Apps we created two of the most important objects known to programmer: DataSet and TableField. Between these two objects, no typical MCCA stood a chance of evasion from our skills. Combined they form the basis of a nice RDBMS local cache with write-through persistence sort of thing. The basic idea is that you have a bunch of data that can be categorized into a bunch of 'records,' standard row/column stuff. You want to add records, delete them, find them, and all that.
It's similar to the BMessage object, but different in purpose. A BMessage can hold a bunch of opaque data, and it's primarily meant for messaging, not as the basis of a record manager. On the other hand, DataSet is the basis for in-memory relational set operations, among other things. We discovered that these objects have much greater use beyond that of their initial database design. So this week I present a shadow of its former self, the DataSet library:
ftp://ftp.be.com/pub/Samples/dataset.tgz
If nothing else, you'll find a bunch of funky C++ code straight from the heart of darkness.
Geoffrey Woodcock has been at it again. His multi-user scratchpad tutorial is coming along. It makes for an excellent tutorial on our developer web pages. You'll learn about networking in our multithreaded environment and some other funky threading issues.
But this guy just can't stop. No sooner does he finish his tutorial than he starts on our developer support system. Under promise, over deliver, that's our motto. When it's done, you'll be happy with the results. It's quite impressive stuff, and it makes me happy to know that he's on our side. This will be the basis for allowing our developers to be in closer contact with us and have a better handle on the pitfalls that might be known in the system.
Since we introduced the MacTech PowerPC version of the BeOS, there's been quite a flood of activity for technical support. Well now has come the time to differentiate "developer" support from "customer" support. Not all people currently using the BeOS are developers. Questions like "how do I partition my Mac hard disk" and "will the BeOS work on my PowerBook" are not really software developer questions. As DR9 approaches, I'm sure we'll get a rash more of these questions. So now you have a new place to e-mail to for answers.
custsupport@be.com
Our web page reflects this change, and you can use this address whenever you have a configuration type of question. The simple test is, if you have a programming question, then fill out the Developer Support form in the Registered Developer Area. This is also the case for questions related to developer IDs, conference registrations, and general introductions to the rich and powerful. If you have any other questions, such as what Power Macs are supported or why you can't configure your particular machine to run the BeOS, send them to the custsupport@be.com address. What you'll find right now is that all of the questions will be answered, no matter which way you send them, but it helps us to categorize them. In addition, we want to encourage you to use our web page for as much information as you can. It's extremely helpful if you read the FAQ in our support area for typical questions regarding installation.
Well the year's starting out smoothly, DR9 chugs along, and GCC has been ported to the BeOS.
See you next week.
Yesterday Heidi Roizen announced that she was leaving Apple by February 19. She's been VP of Developer Relations since January of last year. Her stated reason for leaving is her desire to spend more time with her two young children. There's enough press dissection of the circumstances surrounding her decision for me to leave it at that.
I'd rather pay tribute to Heidi. She came in and helped Apple through difficult times when developers, unsure of the future of the MacOS, needed someone to be their liaison with Apple's management, their visible, believable champion. Heidi is a former Mac developer herself: She headed T/Maker, sold in 1995 to DeLuxe. She had both the experience, the skills, and the charisma to be the standard-bearer for the Mac community. Words such as "irreplaceable" can sound excessive, but it will be hard to find someone to replace Heidi, someone who will enjoy as much trust and respect in the Mac development community as she does.
Closer to home, Heidi has been instrumental in helping us port the BeOS to Power Macs and clones built by Power Computing, Motorola, UMAX, and DayStar. She felt the PowerPC family needed more players, more momentum, more excitement in order to reverse the market share slide, and she thought we could help a little. When red tape or organizational flux got in the way, she got things back on track. As a result, we were able to show a first version of the BeOS running on Power Computing hardware in August 1996, at Macworld Boston. Without her support we wouldn't be where we are today. Her influence helped open a larger hardware playing field for the BeOS and, as a result, for our developers. Moving to the Mac hardware family and finding several attractive multiprocessor systems allows us to focus solely on the area where we add the most value, software.
We now have a simple goal: To become the OS of choice for creative digital media applications. And we're in Heidi's debt for her role in simplifying our business.
I don't know what Heidi will do now. Certainly she'll want to take a break after a tumultuous year at Apple and spend time with her family. Still, I can't imagine her not wielding her considerable skills and influence on the Silicon Valley scene. I imagine venture capitalists calling her, and I can see quite a few start-ups wanting to enlist her leadership skills. It will be fun to watch.
BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.
To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.
Religious question of the week: Is anything intuitive on a computer? Does the user bring inborn (or culturally developed) preferences for the placement of menus, their stickiness, "moused-ness," and so on?
Practical issues and sound bites:
Main Menu Placement
[H]aving a *defined* place for a main control menu is a good [idea]... It's a lot quicker... than [digging] through a mess of windows. | |
| — | |
For a [new] user... the placement of the main menu is probably not very easy to figure out. [But] once it's [found] I find it hard to understand anyone saying that it's hard to remember... I think the main problem with it is that it's awkwardly placed. It takes a lot of mouse movement... to access it. | |
| — | |
...in Windows you get a default menu by clicking on the left-hand-side application button (used to be the kill box)... I don't necessarily want BeOS to look anything like Windows, but the advantage of this extra menu is that it's logically part of the window it applies to. There's no need to mouse up to the top of the screen. | |
| — | |
Window Clutter
I (almost) always hold down the 'control' when opening windows, because I *know* where I want to go... Another cool thing to do would be able to open the *directory* a file was in with "open parent," in case you killed all the windows on the way to the file. | |
| — | |
Modal Dialogs
Maarten L. Hekkelman asked “when should a dialog be modal and when non modal?”
I would take the position that a dialog should be modeless unless the interaction HAS to be executed before it is meaningful for other activities to continue. | |
| — | |
Almost all algorithms can be structured such that the program doesn't NEED the information to go back and 'do nothing' until the information arrives. It's just a little more work for the programmer, but it gives a MUCH better user experience. | |
| — | |
General UI Look
Jon Ragnarrson has posted his opinions in the form of a Web page: http://www.vortex.is/Islenska/Notendur/jonr/Be/BeGui.html
A cleansing facial mask of eulogy and malediction for the late Blue Box punctuated by colorful slurs against the corporate persona.
Listeners expressed interest in the specifics of the PIOS box; some suggested that PIOS resurrect the BeBox design.
A particular cursor designation suggestion from last week—each window (or area within a window) could register (with the Application Server) a custom cursor image—was debated. The primary advantage of the system is that changing the cursor wouldn't require a lot of data to be passed between the client and the server. The primary objection from last week—context-sensitive cursors would be difficult in this scheme—was considered to be either a price worth paying or a feature that could be worked into the general plan.
Can you tell the mail_daemon to retrieve mail messages without deleting them from the server, such that you can read your mail from different machines without having to explicitly transfer the messages between computers?
A listener suggested that the easiest solution is an IMAP server (Internet Message Access Protocol; see www.imap.org/whatisIMAP.html).
Objections:
IMAP doesn't fit well with Be's philosophy of a-message- is-a-database-record.
If you don't delete your messages occasionally, you start to use up (possibly costly) server space.
IMAP security isn't strict enough.
As an alternative, a listener suggested POP3, which (it was claimed) has a feature set that's similar to IMAP—in particular, it can support multiple remote readers.
In DR9, every database record will be stored in its own file, and the notion of a table as a predefined template of attributes for a record disappears. The implications of these decisions were discussed:
File-based records mean there's no hidden data. Some folks fear that this could lead to hierarchy clutter; others think that the approach is a desecration of database principles—they *want* hidden data.
The lack of tables means that while you'll no longer be able to make assumptions about the structure of a specific file, you'll be able to query over a larger domain. A number of listeners wrote in to support the idea that optional table-like functionality be added to the new file system.
Most folks are pleased with the record-is-a-file business. As Ficus Kirkpatrick put it:
“'Hiding' things in the database is sort of a security- through-obscurity type of attitude. I've written a database editor that I can browse tables and modify records with easily. It's just something that you won't have to get a separate app to do anymore.”
Nonetheless, the database-only crowd was persistent. David Evans:
“What we seem to have... is a filesystem with some added database 'gizmos'... It basically removes the 'Record' abstraction and makes database items an extra to files.”
Other issues:
What happens to pre-DR9 tables? How are they converted?
Do the files that hold psuedo-records need to be named? Can the system generate noncolliding "anonymous" names automatically?
What about security? Geoffrey Clements says he's working on DCE (http://www.osf.org/dce) for the BeOS.
