ware? What if you made it inherently multiprocessing?
And what if you put that OS in a box with a consumer-friendly price?
Be, Inc., is attempting to do just that, with its new BeBox due to ship by the time you read this. The basic configuration is a dual-PowerPC 603 with built-in support for a multitude of I/O buses and ports, including Peripheral Component Interconnect (PCI), SCSI, and a "GeekPort" to give hardware experimenters an easy I/O interface to the BeBox.
A Be Bop-a-loo-bop
Harnessing all this hardware muscle is the job of the new Be OS. The OS is built in three layers:
-- A
microkernel
;
-- A number of
servers
; and
-- Shared libraries organized into
kits
that interface to the servers and provide the programming interface for applications (see the figure
"How Developers Interact with the Be OS"
).
The microkernel deals with the specifics of the hardware, much like the hardware abstraction layer (HAL) in Windows NT. The other two la
yers, the servers and the kits, are the heart of the Be OS.
The servers are the engine running under the hood, while the kits are the transmission and gas pedal. The kits provide the mechanism for requesting new objects, sending messages between objects, and so on. The servers are responsible for providing those requested services.
Applications for the Be OS are written to a set of APIs that have been organized into kits. There is an Application Kit, an Interface Kit, a Storage Kit, and so on. The kits are written in C++ and are in essence an object-oriented framework. Developers don't need to master both the native API and a separate application framework. In Windows programming, frameworks such as Borland's Object Windows Library (OWL) and Microsoft Foundation Classes (MFC) provide an object-oriented abstraction for the complex Windows API. But in the Be OS, the API and application framework are one and the same.
This duality of kits and servers is not just a convenient organizing pictu
re for the OS--it is an intrinsic part of the architecture. Like any good modern OS, the Be OS is multithreaded (see
"Weaving a Thread,"
October 1995 BYTE). But the servers and kits put these threads to good use throughout the OS. For example, each window in a Be application has two threads--a client thread and a server thread. The client thread receives and dispatches user events such as keystrokes or mouse movements, while the server thread deals with any processing chores requested by the window.
This architecture lets the application take advantage of the dual-processor BeBox without requiring extra work by the application programmer. And it can potentially improve performance and responsiveness, since the server thread can be run on one processor while the client runs on the other. That's assuming that the thread scheduler is able to put the two threads on separate processors. That might not be the case if, say, an intensive and high-priority process is already running on one of the proce
ssors.
The OS is simply crawling with threads. For example, during boot-up, separate threads are instantiated to handle kernel debugging, turning off the floppy drive motor, and managing the disk cache. There's also a special thread called psycho_killer, which is used to terminate other threads.
Even the boot process itself takes advantage of the inherently multiprocessor nature of the BeBox. While CPU 0 goes searching the available disk drives for an OS kernel, CPU 1 displays the Be logo on the screen.
Being There
Many compatibility problems in today's OSes can be traced to various other system-level extensions. Extensions are supposed to add some functionality to a system, such as a device driver or a network protocol stack. In a legacy OS such as Windows, some extensions can be loaded dynamically as needed, in the form of DLLs. Others have to be installed in a remnant of DOS, the CONFIG.SYS file. While both mechanisms extend the basic OS, conflicts between the two are
inevitable and too common.
Be's solution is to devise a new OS where all extensions are dynamically loaded, shared code. It probably won't eliminate all software-related conflicts, but a consistent approach to OS extensions should make it easier to get various device drivers and shared libraries to coexist more peacefully.
The Be OS features additional innovations and interesting components. Just as each window in a Be application runs in a
separate thread
, each window also gets its own graphics environment. So every window can draw to any color depth, and the Application Server handles either dithering down to 8 bits or expanding to 24/32 bits, depending on the depth you've set on your display.
One of the more interesting features in the Be OS is the built-in relational database. You treat everything stored on a disk drive as if it is in a relational database. The database can have tables with information on files (e.g., size, creator), another table with informatio
n on your E-mail (e.g., date received, from), and so on. In addition to traditional file-based views of your data, you have the option of running relational queries to locate pertinent data.
For applications programmers, there is an interface to the database in the Storage Kit. Users can interact directly with the database through the built-in Be OS Browser, which is somewhat analogous to the Mac Finder. A Find option in the Browser lets you search for any entity in the database; the query results remain "live" until the window is closed. So if you have queried for all JPEG files that are larger than 25 KB, the Browser updates the query window appropriately when you delete an existing file or create a new file that matches the criteria.
And despite the stated goal of breaking free from legacy systems, Be OS developers have managed to steal some good ideas from present-day OSes. The
libpos.so
shared library emulates some of the Posix API to simplify porting Unix-flavored software.
Development Tools
Developing the Be OS has, of course, required development tools, most notably, a compiler. The Be OS is written in C++ and compiled using a version of the Metrowerks CodeWarrior compiler. Version 8 of that development system for the Mac also cross-compiles for both Win32 and Be OS. CodeWarrior and the Be OS have evolved together, which has put some limitations on the Be OS. Because of its Mac heritage, CodeWarrior has not traditionally generated thread-safe exceptions. Version 8 fixes this shortcoming, but because Be developed the OS using earlier versions, it does not yet incorporate C++ exceptions.
Currently, a native Be version of the CodeWarrior integrated development environment (IDE) ships only on the Be OS CD but not with the commercially available CodeWarrior 8 CD. The native Be version still lacks some tools, such as a source-level debugger. For now, Be developers have to cross-debug their Be applications from a Mac--the application runs on the BeBox, while
the debugger runs on the Mac. A native Be debugger should be available soon, possibly by the time you read this.
Though it may still be a bit immature, the native Be IDE already shows off features not possible with the Mac version. Brian Stern, the Metrowerks software engineer who is developing the native Be IDE for CodeWarrior, is especially proud of the multithreaded compilation. After an initial parse identifies dependencies in the source code, separate compilation units can be handed off to separate threads to allow concurrent compilation. The current version supports four concurrent compilation threads, but further development will lift that limit.
Will You Be There?
There's no question that the Be OS is packed with cool stuff. But is that enough to make a go of it in a Windows-dominated world? The former Apple executive who started and still runs Be, Inc., Jean-Louis Gassée, has stated that he does not want to go after the corporate desktop. He envisions the BeBox
as a perfect machine for emerging markets that demand responsive computing, such as multimedia development and digital video editing.
Of course, to succeed in any market requires software. There are plenty of Be enthusiasts out there: Just check out news:comp.sys.be. But will there be enough Be developers to create the applications to take advantage of the Be OS? While it is too early to tell if this is the next revolution in computing or simply son-of-Amiga, the new Be OS is a nifty piece of software.
WHERE TO FIND
Be, Inc.
Menlo Park, CA
Phone: (415) 462-4141
Fax: (415) 462-4129
Internet:
http://www.be.com
New: news:comp.sys.be
The Be-All of Operating Systems
