Issue 1-5, January 10, 1996

Be Engineering Insights: From Power Up to the Browser: How the Be OS Starts Up

By Bob Herold

The Be OS is composed of a boot ROM, a kernel, several 'servers,' and a shared library that exports the Be API. If you issue a ps command in the Terminal window, you will see that many of these components have several threads. This article describes all these items, how they get started, and what they do.

The Boot ROM

The flash memory device on the motherboard contains the boot ROM. It's partitioned into sections, including a small "nub" and a main part.

When you turn on the BeBox, CPU 0 starts running in the nub, while CPU 1 is held in reset. The nub's job is to locate, size, test, and configure the memory, check the floppy drive for a special Boot ROM Upgrader disk, and then pass control to the main part of the boot ROM.

The main part of the boot ROM has the single-minded task of locating a kernel on one of the disks attached to the BeBox. It searches in a particular order: Floppy, removable disks (such as CD-ROM drives or removable hard disks), the disk specified by the boot preference (set by the Installer or the boot command), SCSI fixed disks (scanning from SCSI ID 0 to 6), and IDE disks (master first, then slave). If a kernel is found, it's loaded and run.

Before CPU 0 rummages around for a kernel, it releases CPU 1 from reset. CPU 1 quickly jumps from the nub to the main part, and displays the swirling Be logo. CPU 1 then idles until CPU 0 is in the kernel and ready to run with both CPUs going full bore.

The Kernel

The kernel is started by CPU 0. It sets up all the basic necessities (semaphores, threads, teams, the scheduler, areas, ports, interrupts, inter-CPU communication, virtual memory, idle threads), and then lets CPU 1 join the party. Either CPU can run any thread from the ready queue, so multiprocessing just happens naturally when the code is structured into separate threads.

The kernel starts up several internal housekeeping threads:

idle threads 0 and 1:

Each CPU must always run something. The idle threads are simple spin loops, with a scheduling priority of zero. They never block, so they're always around when there's nothing else to do.


Having a thread kill itself is tricky. It's much easier to hire out for the job. The psycho_killer thread assassinates threads that wish to die, and removes a team when the team's threads have all died.

idle debug 0 and 1:

These are around in case something bad happens in the idle threads. They take over debugging chores from the idle threads, thus allowing the idle threads to continue loafing on the street corner.

dprintf and dgets:

These are for kernel debugging. If you hold down the F1 key when you boot, all sorts of debugging spewage comes out of serial port 4 at 19.2 kilobaud. Should the kernel crash, a primitive debugger is available there. These two threads manage the debugging I/O to the serial port.

floppy motor off:

A floppy drive takes half a second to spin up to speed. Rather than turning the motor off after each read or write, it's left running for a few seconds in case another access comes along. This thread turns the motor off after this grace period.

disk cache:

The file system has a cache. This thread periodically writes dirty sectors from the cache to disk. Note that disk accesses greater than a certain size bypass the cache entirely.

Once these niceties are set up, the kernel mounts all available disks and looks for a disk from which to boot the rest of the system. Disks are examined to see if they have a complete set of system software: the Browser, the Application Server, the Storage Server, the Zoo Keeper, a drivers directory, and the shared libraries and If any of these files are on the floppy, they take priority over these files on other disks.

The kernel looks for system files on disks in the following order: The floppy disk, the volume where the kernel was found by the boot ROM, the disk specified by the boot preference, SCSI disks 0-6, IDE master, and IDE slave. The first disk with all the system files, minus any contributions from the floppy, becomes the "boot volume." If the boot volume is writable, it's also used as the volume where the virtual memory backing files are kept; otherwise, virtual memory is disabled.

Once the boot volume is identified, the Application Server, Storage Server, Zoo Keeper, and the Browser are started from the boot volume (or the floppy). Additionally, the kernel looks for a file called Bootscript, and starts up a shell to interpret it. The current Bootscript launches the ANSI Server, the Audio Server, the Debug Server, the Name Server, the Net Server and ftpd.

The Shared Library:

The shared library exports the API described in The Be Book. Applications link with the shared library at compile time, and are bound to the shared library when they are loaded at runtime.

The shared library together with the various servers implement the API. The library uses the kernel's port mechanism and shared memory to communicate with the servers. API calls are converted into messages and sent though a port to a thread in the appropriate server. Servers usually allocate a single thread to manage each client, allowing for concurrent access to the functionality each server provides. The allocated thread receives the message, carries out the call, and often returns results to the client via another port.

The Shared Library: provides an emulation of some of the Posix API. This makes porting of UNIX-flavored software much more feasible. Many of the command-line tools available in the Terminal application use this library.

The Application Server

The Application Server, in conjunction with the Application Kit and the Interface Kit, manages an application's user interface, graphical environment, and messaging infrastructure. All these are extensively documented in The Be Book.

The Application Server has a few permanent housekeeping threads, plus a separate thread for each client application and each client window. The housekeeping threads are:


Collects keyboard and mouse information from the kernel, forwards it to the app_server thread, and displays the on-screen cursor


Handles set-up of new applications; dispatches keyboard and mouse events to the appropriate window thread, which sends them to the client


Receives notification from the kernel of various interesting events, such as a thread being destroyed

The Storage Server

The Storage Server is the database engine. The Storage Server manages the index into the databases and performs the queries associated with each database.

The Zoo Keeper

The functions described in "The Storage Kit" chapter in The Be Book are actually split between the Storage Server, the Zoo Keeper, and the shared library. The Zoo Keeper, keeps track of volumes, ensuring that every volume has a database that describes the volume's file system hierarchy. The actual management of files and directories (BFile, BDirectory, BVolume) is split between the shared library and the Zoo Keeper. Both use the Storage Server to maintain the database view of the file system. Interestingly, the Zoo Keeper and Storage Server are also linked with the shared library to gain access to each other, the kernel, and the Application Server.

The Browser

The Browser is what you see when the machine has started up. Its powerful capabilities are sure to be the subject of a future newsletter article. Strictly speaking the Browser is an application like any other—it links with the shared library and uses the various servers and the kernel to go about its business. Obviously it's one of the more important applications shipped with the BeBox.

The ANSI Server

The ANSI Server is an anachronism, which will soon go away. It provides ANSI-style terminal windows to clients, communicating through named pipes with the client. It has been replaced by a new TTY driver, which understands how to emulate an ANSI terminal. In earlier releases, the shell used the ANSI Server, but it has been converted to use the TTY driver. The Debug Server has not yet been converted, so we'll have the ANSI Server around for a little longer.

The Audio Server

The Audio Server provides the functionality described in "The Media Kit" chapter of The Be Book. Streams, Stream Controllers, and the Subscription mechanism are all handled here.

Two housekeeping threads, DAC Feeder and ADC Feeder, keep sound buffers flowing smoothly to and from the sound driver (which manages the audio CODEC). Requests to play or record sounds instantiate a thread that manages the process.

The Debug Server

The Debug Server implements the assembly-level debugger. When an application crashes or runs into a debugger() call, the kernel spawns a per-team debugging thread in the application's address space to manage communication with the Debug Server. The Debug Server, in turn, spawns a thread to put up a window for that team (currently using the ANSI Server) and to process debugging commands. The kernel provides hooks for installing a different debugger on a per-team basis. Our friends at Metrowerks are creating a source-level debugger using this facility.

The Net Server

The Net Server implements the TCP/IP protocols needed to communicate with other devices over an Ethernet or PPP connection.

The Name Server

The Name Server assists the Net Server in managing various system resources, such as ports and semaphores.


ftpd is the ftp 'daemon.' It runs in the background, silently providing ftp access to the BeBox.


The Be OS is divided up into many different components. Hopefully this article has shed some light on how they are started up, and what they do.

MacWorld? What Are We Thinking?

By Jean-Louis Gassée

This is a Macintosh trade show. You're not selling Macs, you're not a Mac OS licensee, the BeBox isn't even a CHRP platform, and in any case, with your "geek" positioning, you're definitely not addressing the needs of mainstream Mac users. So, what are you doing here?

Good question. A few months ago, I would have agreed we had no business going to MacWorld. And today, I agree with all the facts stated above. But they're not relevant to our decision to exhibit in San Francisco. Here's why, with the hope it will shed some light on our marketing strategy. No, we're not selling Macs and we're not a Mac OS licensee although,at some point, we considered it. Early in 1995, friends at Apple advised us to wait for a new hardware reference platform. Eventually, Copland would run on that platform and all compliant hardware would run the new Mac OS. No need to be a licensee, just buy the OS off the shelf and you can run Mac applications.

Indeed, the CHRP platform was announced at Comdex, with a partial release of technical data. Specs for the ISA system and a few other details are expected soon and, given the updated Copland schedule, Apple announced it will make a 7.5.x version for CHRP, with the first machines to appear in late 1996 or the first half of 1997, depending on the source. As the CHRP specs are finalized and parts vendors start supplying chip sets, making a CHRP compliant multiprocessor BeBox with its rich, geeky I/O becomes an attractive proposition. As the current BeBox is based on the ancestor of CHRP, PREP, it's logical for Be to make CHRP an important part of its product strategy. Today's PC clones are still built around a core of PC/AT design. Compliance to these specs has allowed PC buyers to benefit from a number of operating systems: DOS, Windows and Windows NT, of course, but also a number of UNIX variants, NEXTSTEP, Linux, OS/2, and I must forget a few. The CHRP partners hope to see a like diversity of system software on the PowerPC side. We'll be happy to help and benefit as the new platform gains momentum. But this is for the 1997 horizon.

What about MacWorld in January 1996, geeks, and mainstream Mac users? Representing MacWorld as only attended by bourgeois mainstream users is quite a stretch. Yes, we see more suits than T-shirts today than ten years ago, but there's always a strong contingent of aggressive, knowledgeable users, exhibitors, and software developers. They're not always found around the bigger, jazzier, and more expensive booths, and that's fine with us. They're our audience—they come to MacWorld in sufficient numbers to more than justify our presence. Three months ago, at the Agenda conference, we showed the BeBox to an audience of professional cynics—or cynical pros. We were surprised by the exceptionally warm reception. This continued as our Web site opened. We now have more than 900 requests for development systems from all over the world, and the new newsgroup is lively. As a result of a higher than expected level of interest, of "pull," we decided to go beyond the "Demo Days" at Be in Menlo Park. Three months after Agenda, MacWorld happened to be a nicely timed and geographically positioned venue.

For the more committed, you decide the sense, we'll host our first software developer conference, our first "GeekFest," right after MacWorld on Saturday, January 13, in South San Francisco Convention Center.

Back to our MacWorld booth: We'll make sure mainstream users aren't misled. We'll prominently display a surgeon general's warning: Unfit for consumption by normal humans. We'll focus on software development tools, the new version of CodeWarrior by Metrowerks, prototypes and works in progress from early Be developers, and BeBox demonstrations every 20 minutes. This is our first public appearance. Come by if you can. You'll get your free We Be Geeks pocket protector.

Be Marketing Questions and Answers

Here are a few answers to a number of the most common questions you've been asking about Be. We'll keep you informed regularly about Be marketing, sales, pricing, and the like.You can also check out our web site at:


When is the BeBox going to be on sale?


Be plans to make the BeBox available to the general public in the first quarter of 1996. This means that you will be able to purchase a BeBox (configured with peripherals or not) from Be or from one of its resellers or VARs, with the native Be CodeWarrior development environment bundled. During 1996, we expect most purchasers to be programming hobbyists and professionals who are developing software for their own use, or for eventual sale to other BeBox owners.


What will it cost?


Be has not set its final pricing for the initial BeBox configurations, partly because we expect component prices to continue to change (read "fall") prior to our release date. We've announced that we expect the pricing to be about $1,600 for a bare-bones (non configured) system, and estimate that a configured system will be in the $2,500 range. We'll announce firm prices as the release date approaches.


Where can I buy a BeBox?


Initially, we expect that you will be able to purchase the BeBox from three sources. First will be through our resellers and VARs. Second will be directly from Be, via the Internet. In this case, your order will be sent to one of several partner companies, depending on the configuration you order. Last, we expect the BeBox to be made available through organizations such as universities. More details will be available as we approach our initial ship date.


What are Be's plans for distribution outside the U.S.?


Be does plan to distribute outside the U.S. In fact we already have a developer program up and running in Europe and have established corporate offices in Paris, France, for developer services and marketing activities. European developers can contact our Paris offices directly at:

Be plans to initially release the BeBox in the U.S. and France. After the initial release we plan to expand distribution to other European, Asian, and Pacific countries as quickly as we can. Our main gating item will be identifying distribution and other partners in the various countries and regions. We invite interested parties to send us questions and information to either or

To set expectations correctly, the Be OS will initially be released in English. We expect to release other versions of the Be OS in other Roman-character languages as quickly as possible. We will post information about these releases to the Be web site after the initial English release. Be is committed to developing the Be OS in multibyte language forms, but we haven't announced our plans yet.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.