Jan 97 Factory Floor
Volume Number: 13
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.
