One of the main design goals of the Be OS™ is to support easy and efficient sharing of data. I definitely won't claim that the Be OS has the end-all, be-all IPC, or that we've completely flushed out all the issues related to moving data around our system. However, I do believe we have a good start: The Be OS provides many useful data-sharing facilities you can use to write really exciting applications.

At the lowest level, the kernel provides three data-sharing facilities: Thread messages, areas, and ports.

Thread messages use the simple API of send_data and receive_data. This is perhaps the most basic messaging mechanism in the system. These messages aren't buffered, so a call to send_data will block until it's read by the target thread. This mechanism is used in several places in the system, including the initial bootstrapping of applications with the app_server. When an application launches, it uses send_data to send a message to the app_server's 'picasso' thread. This message contains the IDs of a couple of ports; further messaging between the application and the app_server will use these ports.

You can use the kernel's second data-sharing facility, area, to create new valid regions in the virtual address space. The kernel allows the same area to be mapped into the address space of different teams (processes). One team can create the area and pass the area_id to other interested teams. These teams can then map that area into their address space. This allows applications to share memory. The BMessage class, discussed below, relies on this facility.

It's worth mentioning a couple of caveats about using shared memory. If you plan to share pointers, make sure that all the pointers point within the shared area, and that all teams map the area into the same virtual addresses. Otherwise one team's pointer may be another team's data exception! Another issue is synchronizing access to the area. You can use a semaphore to ensure that memory is only accessed when in a consistent state. Semaphores are a system-wide resource and the IDs are valid across all teams.

The third kernel facility that supports messaging is the port mechanism. Ports provide a system-wide buffered messaging system. These messages can be of arbitrary size. Anyone with a port_id can read from or write to the port. When you create a port, you specify the number of messages that the port can hold. If the port fills, the next call to write_port will block. At first glance this might seem undesirable, as code cannot assume that write_port won't block. We chose this design to prevent an orphaned port (a port that never gets read) from consuming all of system memory. Those buffered messages have to be stored somewhere—the system wouldn't be too happy buffering 1,493,467 1 K messages or around 1,500 MB of data. The BMessage class, along with BMessenger and BLooper, make use of ports to pass messages between teams. When using ports, take care to synchronize the writing and reading of messages. If the 'virtual' message spans multiple calls to write_port, you must take steps to correctly deal with other threads that might be writing to the same port. Similar issues arise if multiple threads read from the same port.

That gives a basic overview of messaging, from the kernel's perspective. The Be OS also has several higher-level messaging systems, used for different purposes, that are implemented on top of the lower-level services. The most visible form of messaging in the Be OS is defined by the BLooper and BMessage classes. A BLooper is an abstraction of the thread running a message loop. BMessages are posted or sent to a looper and then dispatched to a message handler. (Release 1.1d7 sneak preview: The BReceiver class will be renamed BHandler.) A BMessage is a structured collection of data. This data includes a single 4-byte 'what' identifier. To this you can add arbitrary data entries, each entry having both a string name and a 4-byte type identifier. You can add multiple chunks of data under the same name and type. The data in a message is kept in what we call the "shared heap," a heap shared by all applications in the system. This heap is created using the kernel area API. When messages move between threads in the same team—typically using BLooper::PostMessage()—the team is simply given the pointer to the shared data. Things are a little more complicated when using BMessenger::SendMessage() to send a message to another team. In this case, the address of the data in the shared heap is written into a port. Once the destination reads the address out of the port, it has complete access to the data of the message. This design provides for fairly efficient messaging, as the data is only copied once—into the shared heap. From then on it can be passed among many different threads and teams.

The Be OS clipboard and drag-and-drop mechanism are both based on the BMessage object. Adding data to the clipboard is just like adding data to a BMessage. Responding to a PASTE message is just like being sent a message containing some data. Drag-and-drop works the same way. Our hope is that leveraging the BMessage system makes for a simple and reusable API.

The final data-interchange mechanism is defined by the Media Kit. The BeBox is designed to be a dream machine for audio/video developers. One of the big hurdles in developing applications that deal with audio/video data is being able to efficiently move very large amounts of data between interested parties—even those in different address spaces. The Media Kit is designed with this in mind. At its core is the BStream class, which implements a data-streaming facility using shared memory (there's that kernel area mechanism again). The BStream class synchronizes access to data that lives in dynamic areas of shared memory. Each participant in the stream is given access to the buffers present in the stream. Although BStream is defined in the Media Kit, it isn't constrained to just media data: You can use the class can for all kinds of tasks. If the API looks interesting, give it a try.

That's a brief overview of the various messaging options provided by the Be OS. Let us know if these features suit your needs—or more important, if they don't. Have fun!

For years, people have spoken of the Amiga as a sort of computer Shangri-la—a great, innovative personal computer platform that was doomed to oblivion by its manufacturer's indifference.

Fred Fish, owner of Cronus, is one of the Amiga faithful. His Tempe, Arizona, company (formerly Amiga Library Services) still supports the platform. But even he admits that although the Amiga is "not dead yet, it's certainly starting to smell a little funny." He hopes the BeBox will be able to step into the spotlight that the Amiga deserved but never got.

Fish became interested in the BeBox because "in a lot of ways, it's very similar to how the Amiga was—with very new, innovative technology. Who wants to work on PCs and Macs anymore? They're just not that exciting. I know there are a lot of other people who feel that the BeBox brings back some of the excitement that the Amiga generated. It's a good blend of hardware and software."

Cronus has been compiling public domain software for the Amiga since 1985. "It seems obvious that one thing we might consider is doing a compilation of freely distributable software for the BeBox" as well, Fish says. Currently, Cronus supports the Free Software Foundation's suite of UNIX tools on the Amiga and Fish is thinking about doing something similar on the BeBox.

Later, he'd also like to produce a digital signal processing toolkit for the BeBox. This toolkit would consist of "lots of utilities that would connect together to produce simulations of larger systems," Fish says.

Eventually, Fish hopes the BeBox will become "what the Amiga should have become, gaining very widespread acceptance." Fish hopes that one day, the BeBox will be "one of the top three choices for people who walk into a computer store—you'd choose between a Mac, a PC, or a BeBox."

When that day comes, the Amiga faithful will be avenged at last.

Cronus is constructing a mirror of the Be ftp site, which you'll soon be able to find at http://ftp.ninemoons.com.

We're often asked what we think of the $500 Internet Terminal, of the Hollow Computer, of the NC (Network Computer). All these monikers refer in one way or another to the concept of an inexpensive Internet appliance. This is a great concept. Who wouldn't like to have a nice $500 device for surfing the web, exchanging e-mail, and arguing in Usenet newsgroups. And buy things, listen to news, play virtual reality network games...

Before we look at the implementation issues, let's first deal with personalities and human emotions. A few people and companies have given the NC high visibility and a strong anti-Microsoft flavor. It might be amusing to see Larry Ellison throwing barbs at Netscape, charging them with wanting to be the Microsoft of the Internet, or to see Microsoft dressed in the same Big Brother clothes as IBM used to be. But it doesn't tell us much about the technical, the financial, and ultimately the market feasibility of the NC. Even the hype doesn't matter much. It didn't help Interactive TV or PDAs. It might even hurt, as the example of the Newton shows. Now that it has become substantially closer to its original claims for function, its credibility is spent, making a comeback a long, tricky exercise. Compare this with the Psion, which sells solely on the word-of-mouth of proud owners.

On to the implementation issues. Today, one can buy a 486-based PC for a little over $700 retail. At Demo 96, Jim Louderback, the Editor-in-Chief of Windows Sources, built one on stage for a little over $600, modem included. So what is the difference between that PC and the NC? The PC is just as capable of surfing the Net as its younger brother, it runs all sorts of applications from games to spreadsheets, it sports a monitor and a hard disk, and it can use inexpensive peripherals. The NC proponents will point to a few advantages. The NC doesn't need a hard disk, applications will be either in ROM or downloaded from the Net, including spreadsheets and word processors. Nor does it need a monitor. To reach the $500 retail price, not cost of goods, it will use your TV as a screen.

I have a hard time with both points. I just bought a 240 MB hard disk for my daughter Sophie's Mac, whose older drive had died. It cost me $77, reduced to $70 a week later. There is too much of an imbalance between the savings realized and the loss of the nice functionality provided by a hard disk. The applications are supposed to be loaded from the net, each time we'll need them. They'll generate data. Where are we going to store that data? On the net? This is "The Network Is the Computer" theory. It works for some applications, with some customers, and with some fast, expensive hardware and networks. Also, today's browsers need disk caches for decent performance. Factoring caches out will require a faster network or beaucoup RAM. More money one way or the other. As for the TV as your screen, we know it works for games. Beyond that, it's doubtful. In France we have the Minitel experiment, where attempts to use the TV as a screen for the terminal were short-lived. Even with less demanding text and graphics and direct RGB input in the back of those TVs.

The other argument in favor of the NC is the decrepitude and irrelevance of operating systems. I have a little or a lot of biases here. Somehow, I think, the NC will need system software to orchestrate the whole works. The next thing you know, it will sprout a disk, a monitor, and a printer and we'll have a web-oriented PC, at PC prices. Perhaps Oracle will sell its reference design to the folks at AT&T. After passing up on buying Apple in 1990, buying and reselling NCR instead, investing in EGO, General Magic, and Ziff-Davis' Interchange, AT&T now enters the Internet business. Regardless of the cost of goods, they could offer an Internet appliance for "free" as part of a marketing campaign targeted at the unconnected masses. The French PTT did just that with the Minitel. But that was 15 years ago. There was no Internet and, if memory serves, it sold a lot of Macs sporting a nice Minitel emulation.

Which leads me to my conclusion. Whether the NC evolves into a new personal computer platform or is used as a loss leader to develop the Internet market, it's good news, creates competition, stirs up creativity, and makes life more interesting.

Of course, I could be all wrong. I remember the mainframe stakeholders pooh-poohing the minis, the mini elders discounting the workstations, and the workstation ayatollahs explaining how PCs couldn't exist by reason of their lacking a true OS and a true network. So, I could be one of the PC dinosaurs not seeing the combined wisdom of Lou Gerstner and Larry Ellison. Time, or rather, customers will tell. So far, large companies have had little success imposing new platforms. PCs, minis, workstations, Ethernet, and the web come to mind. None have been spawned by corporate giants.