Volume Number: 13 (1997)
Issue Number: 1
Column Tag: From The Factory Floor

The Wizards of Be, Inc.

By Dave Mark, ©1996 by Metrowerks, Inc., all rights reserved.

The BeBox is a rare beast indeed. A very cool piece of hardware coupled with a brand new, "from the ground up" OS. This special Be-oriented issue of MacTech just wouldn't be complete without a chance to speak with two of the principals of Be, Inc. - Jean-Louis Gassée and Erich Ringewald.

Dave: Can you tell us a little about the birth of Be, Inc.?

Jean-Louis: While at Apple, I saw the problems arising from the growing complexity of the MacOS. At the same time, we envied some of the features of the Amiga - its support for audio and video applications and a truly multi-tasking OS, to name a few. We started Be with the idea we could free ourselves from the problems of the MacOS sausage factory, and build something like the Amiga - without Commodore.

Dave: How does the BeBox fit in with its peers - computers such as the Mac or WinNT box?

Jean-Louis: One of the things we've tried to emphasize is that we don't see the BeOS displacing Windows or the MacOS, or trying to slay any other Goliaths. There will be nearly 70 million PC's sold this year, many of them into office automation or home productivity and other non-performance oriented audiences.

However, part of the computing audience today, the "bit-flingers", are consuming processing power faster than it's coming to market. They've reached and passed the limits of today's OS architectures and need something more. This digital design crowd, the content creators for the rest of us, are handling digital audio, digital video, 3D, heavy image manipulation, and integrated web site design. They need something beyond the mainstream OS offerings they have today, and that's the center of our product focus. The BeOS may go other places, but the design point at the center is with this crowd.

Over the last year, we have focused on an even tighter segment - computer developers and "geeks." We're looking for the "guide geeks" in the market - those individuals who define new directions and new applications. We're not going to pretend that we are smart enough to predict the future all by ourselves, we need help. That's why our relationships with developers are placed at the center of what we are doing.

Dave: I know that CodeWarrior is the principal development environment for the BeBox. I've also heard of a tool called AppSketcher. Can you talk about your overall tools strategy, and describe the development cycle?

Erich: As a small company, we didn't set out to do a new OS and a new development environment. We couldn't help but notice that just about every PowerMac developer on the planet was using CodeWarrior from Metrowerks, so we decided to build our system around that. That meant adopting the Apple proprietary executable file format known as PEF, which is what CodeWarrior emits. It also meant supporting the Apple/IBM runtime environment for the PowerPC under the BeOS so that code generated by the compiler, and files emitted by the linker would be 100% compatible. Early developers did cross development with the standard issue CodeWarrior on the Mac, and when the native version of CodeWarrior became available, they could easily switch over to native development.

Developing a BeOS application under CodeWarrior is no different than developing one for the MacOS. The headers and libraries for MacOS are simply replaced with BeOS headers and libraries, and off you go.

AppSketcher is an "Interface Builder" like tool designed to work with the BeOS class library. It was developed by an enthusiastic Be developer called Lorienne International. It's really going to help with the busy work of designing UI's on the BeOS.

Dave: Let's talk about the BeOS API. When you say it is object-oriented, what does that really mean?

Erich: Essentially, the entire API of the system is presented to the application developer as a collection of C++ classes. With very few exceptions (no pun intended), these classes are organized into Software Kits, then segregated by function. For example, the Interface Kit contains all of the classes associated with UI and drawing on the screen, while the MIDI Kit contains classes encapsulating the MIDI functionality.

Of course the Mac has an API which is a flat collection of Pascal/C procedure calls. Any attempt at bringing object-oriented programming to the Mac have taken the form of class libraries "layered" on top of the native API. All the current frameworks (e.g. Power Plant, MacApp, TCL) are additional layers of code standing between the application programmer and the native OS implementation.

It is not hard to see the benefits of having an API that was conceived from the ground up as being object oriented; it is less a question of "lipstick on a chicken," and a much cleaner and more natural way to program.

Dave: The BeBox is said to be Multithreaded. What exactly does this mean on the BeBox?

Erich: Well, the underlying kernel provides the capability of running separate threads of execution with protected address spaces. However, when we say the entire OS is multithreaded, we mean that not only is this raw capability there, but the rest of the system (the UI implementation, the file system, the storage server) actually make heavy use of the multithreading and multiprocessing capabilities of the kernel. This ensures that all applications benefit from the MT/MP nature of the kernel and hardware without having to explicitly code for it.

The Application Server that implements the UI is a good example of this. Every time an application creates a window, two threads are created by the system. One runs in the Application Server's address space, the other runs in the application client's address space, and both interact to maintain the contents of the window in a lively and resposive fashion, regardless of whatever else is going on in the system. This kind of re-entrant, multithreaded implementation of a basic system service makes sure that the fundamental advantages of an MP/MT system are consistently delivered to the user without requiring explicit programming from the application developer.

Dave: The other mainstream multithreaded OS on the market is NT4. Can you draw some differences between BeOS and NT4?

Erich: NT4 has a great OS kernel. It's fast, reliable, and feature rich. However, not all of what the user sees with NT4 is written this way. At the risk of repeating myself, although the NT4 kernel does provide MP/MT capabilities, the Win 32 API and UI implementation that sits atop the kernel is not written to take advantage of MP/MT features. So, even though it's sitting on top of a great kernel, you can still click in title bars, bring down menus, drag windows around, and cause other visual components of the system to lock up while the mouse is down, just like on a Macintosh. So, while I'd recommend that my grandmother use NT4 in a closet, for a high-performance, reliable file server with no user interface to speak of, I don't think it stacks up to the BeOS as a next generation platform for highly responsive graphics and multimedia where interactivity must be maintained despite a collection of real-time demanding interface intensive applications.

Dave: How much of the BeOS was written in C++?

Erich: Almost all of it. The kernel itself is in C, along with about 3000 lines of assembler to handle the very lowest, processor-dependent pieces. The Kernel Kit and Network Kit both have low level C interfaces along with higher-level C++ interfaces. The rest of the BeOS is C++.

Dave: How are you dealing with the fragile base class problem?

Erich: We've spent a lot of time looking at the problem from many different angles. Obviously, a solution has to be provided in order to allow us flexibility to change the system, while ensuring developers compatibility in the future.

We've looked at SOM for some time now. We're concerned with a couple of issues related to SOM. There are many (many, many) restrictions imposed on language features using SOM. No function overloading is permitted. This is a major issue since it is a key feature of object-oriented programming. No parameters can be passed to constructors. You can't have static data members, or public data members. The list goes on.

On top of this, our tests on SOM indicate that it would cause a large performance hit to the overall system, something that goes against the very grain of our company. Basically, SOM gives us much more than we want. It solves more problems than the fragile base class problem, and it tries to solve binary object compatibility between languages and distributed objects. At this point, we're mainly interested in solving the first problem, and delivering performance. While SOM would provide solutions to other problems as well, we're not sure how many applications would actually take advantage of this. Given that every app would experience the performance hit, SOM is probably a case of using an atom bomb to remove a wart.

We also considered the simple solution of padding our classes with extra data and extra virtual functions. This isn't very elegant of course, but has a number of positives. It doesn't impact performance at all, except for slightly more memory required within objects. It is a simple solution that allows us to transition to a better solution, should one become available - specifically one that has less of a performance hit.

Most of all, this solution places no burden on the developers. Unlike SOM, it does not impact the way they write code. They can exploit all of the features of C++, including overloading, static data, etc. This is extremely important to us. An OS shouldn't put up more hurdles than it has to in order to develop new code. Furthermore, it shouldn't needlessly suck down performance.

So, we're going for the simpler solution now. It's not perfect but we're not willing to take the performance and complexity hits within SOM. We'll also investigate a versioning system so that the BeOS supports multiple versions of the same library (transparently.) This will enable us to gracefully transition to an improved scheme down the road.

Dave: Since many of our readers have not yet gotten their hands on a BeBox, can you tell me about the box itself? Why did you do the BeBox hardware implementation (rather than using other vendor's boxes)?

Erich: We're producing the BeBox for two key reasons. First, from a purely tactical perspective, we needed low-cost multiprocessor hardware in order to build the BeOS itself, and to prove out the MT/MP architecture. Second, we're committed to the idea that multiprocessing hardware should not be expensive - it should be a mainstream solution anyone can take advantage of. So, from Be itself, you'll see only multiprocessor, media feature-rich BeBox designs, since that is where we see the future of personal computing centered.

The BeBox Dual 603 that we sell today is a machine that mixes multiple processors with mainstream, low-cost, standard PC components. Two PowerPC microprocessors power the motherboard, which also features 3 PCI slots, 5 ISA slots, standard 72-pin DRAM SIMMS, and IDE and SCSI drive connectors. There are no "custom" components on the board, we've intentionally stayed away from that resource-sink.

On the back of the BeBox, you'll find SCSI, parallel, keyboard and mouse ports, along with a 16-bit stereo sound system (RCA and mini jacks provided), 4 serial ports, 2 joystick ports, 2 sets of MIDI ports for dual-channel MIDI, and 3 IR control ports. In addition, there's the GeekPort, which gives hardware specialists access to D/A and A/D convertors on the motherboard, as well as power. The GeekPort is protected by a set of fuses to prevent you from accidentally frying your motherboard.

The BeBox uses standard IDE and SCSI drives, standard floppy drives, and standard SCSI CD-ROM drives. In addition, graphics are supported by standard PCI graphic cards, and network connectivity by standard PCI or ISA cards. We have really tried to make a system that is as configurable and inexpensive as possible for a multiprocessor system.

Dave: Will I be able to build a MacOS app on the BeOS? Will I be able to run a Mac app on the BeOS?

Erich: Your first question, building MacOS apps on the BeOS, is really a question for tools vendors like Metrowerks. There is no reason this can't be done. We're using PEF, PowerPC, other standards so an application can be built. As we know from our early-days experience with creating BeOS applications on MacOS (which you can still do), cross platform development usually requires a few more tools to support debugging, etc. However, there is no reason this couldn't be done.

The second question, MacOS compatibility with the BeOS, can probably be broken into two parts. The first is data, hardware and network compatibility. We are intensely interested in this area. With the BeOS for PowerMac product, we are supporting standard PowerMac hardware. Why didn't we wait for CHRP? Because we are impatient. CHRP wasn't coming fast enough for us, and we decided it wasn't that hard to get the software running on current Apple hardware designs. So, you'll be able to set up both the MacOS and the BeOS on a PowerMac, in a dual boot setup, just as you would be able to do with CHRP. Basically, we're delivering CHRP today.

The BeOS is TCP/IP native, which is proving to be the single protocol that all platforms can agree upon (mainly due to the Internet.) We're also going to be looking at AppleTalk in the future, but first we'll see what initial customers tell us. Obviously, we want to support the printers and other devices currently available. Data compatibility, both standard data and the ability to read common application formats, is at the top of the list for us, and for most of our developers. In addition, the BeOS in the Q1 release will be able to support the MacOS HFS disk format as an external file system. This will allow you to see all of your Mac files and data from within the BeOS, and make use of it in BeOS applications.

The issue of MacOS application binary compatibility is more complex. Based on the discussions within the development community over the last few months, it is accepted that it is possible to provide this capability. One approach is similar to MAE, Apple's product for UNIX systems where the MacOS runs in a window. It may be somewhat simpler because you know you are running on a PowerPC, and you have the ROMs in the hardware! Another approach is to do what Windows NT does with DOS applications - build each old binary a "virtual Mac." The advantage of this approach is that you get some of the benefits of memory protection, even with older applications. However, there are other issues to this approach that might make it more difficult to deliver.

Be is committed to delivering the first hardware, network and data compatibility. We're looking at MacOS binary compatibility, as are a number of our developers, but we haven't made any decisions in that area yet.

Dave: How do you feel about Apple's recent troubles and their future?

Jean-Louis: I signed up with Apple in December of 1980, the day of the IPO. Doomsayers were already predicting Apple's demise for failing to support standards such as CP/M and 8 in. floppies. In 1982, there was the Apple /// fiasco, then the Lisa in 1983. In 1985, common wisdom declared the Macintosh stillborn - yet each time it managed to rebound. Apple enjoys a strong following in the developer community, as well as with users. With a new management team and healthier finances, I see every reason for Apple to come back.

Dave: Where do you see the computer industry going from here? Are there still frontiers to be explored? Still money to be made for the small developer?

Jean-Louis: The computer industry keeps renewing itself for simple, well-known reasons - there's never enough computing power, never enough bandwidth, never enough storage, and fortunately, semiconductor and other material technologies keep providing more capacity that software is only too happy to fill. As for new frontiers, three years ago the Web wasn't visible, and there is plenty to do in digital media simulations of all sorts that will keep the industry humming for a long time. Then we will have to expend all sorts of creative, technical and financial resources to make machines simpler. This will continuously create new opportunities for software developers, especially with new Web-based distribution channels.