|
Be Newsletter
Issue 3, December 20, 1995
Table of Contents
BE ENGINEERING INSIGHTS:
"Our" Toy Story
By Steve Horowitz
The BeBox you see today is actually quite a bit different
than the one that existed four years ago. Both the hardware
and software have come quite far since the version we had
running in our old offices, in an industrial park in San
Jose in 1991.
The original design of the BeBox was actually implemented as
a dual-Hobbit processor machine, with three digital signal
processing (DSP) chips on the motherboard. The bus
architecture was proprietary, but memory, hard disks, mice,
and keyboards were all borrowed from what Jean-Louis likes
to call the "PC clone organ bank."
The software at that time consisted of just a
multiprocessing, multitasking kernel and a command-line
shell for launching applications. There were no graphics, no
windowing system, and no integrated database -- although all
of these items were planned.
The first attempt at bringing some graphics capabilities to
the machine came in the form of an evaluation of the NeWS
windowing system from Sun Microsystems. My first job at Be
was to learn PostScript to see what it was like to program
in the NeWS environment. While NeWS did offer us a
client-server approach to graphics and PostScript as a
graphics model, it was rather large and the programming
model, as well as the port to the BeBox, seemed complex.
While this evaluation was taking place and while we
continued to evaluate other user-interface tool kits and
graphics systems, an engineer named Benoit Schillings was
quietly developing his own graphical windowing system. Using
his intimate knowledge of the Be kernel, he optimized his
graphics system to run extremely fast on the BeBox. To this
day, Benoit remains our primary resident "speed freak."
The decision at that point became obvious. Although writing
the entire graphics system from scratch was never our
intent, we could see that it was the only way to achieve the
kind of responsiveness and usability that we wanted for the
BeBox. I abandoned the evaluation process and set out to
help Benoit write the first version of the Be class library,
which would interact with his speedy graphics server. Using
the initial classes we developed (including windows, views,
scroll bars, buttons, and menus), we set out to write a
number of applications, including the file system Browser,
to demonstrate and test the system. We were later joined by
Eric Knight, who worked on the class libraries as well as
several key demo applications, such as MIDI, MessageCenter,
and FontDemo.
While all of this "high-level" work went on, the kernel,
file system, I/O system, and device drivers continued to
evolve and improve under Erich Ringewald, Bob Herold, and
Cyril Meurillon, who had all been with the company since its
inception.
In early 1994, Peter Potrebic joined the Be team and was
given the responsibility of maintaining and enhancing the
class libraries. Under Peter, the application framework saw
a number of significant enhancements, including an improved
application messaging system and the addition of threading
classes. During release 2 of the software he was absolutely
zealous in tracking down a number of extremely difficult
bugs, which resulted in the system reaching a level of
stability that we had never seen before. Our technical
writers, Don Larkin and Doug Fulton also helped tremendously
to make sure that the design of the class libraries and APIs
were coherent and consistent.
Shortly after Peter joined the team, we hired another
engineer named Robert Polic. Robert started out by helping
Benoit with the graphics server and then showed tremendous
versatility as he went on to work on many different levels
of the system, from the SCSI and video drivers to many of
our utility applications, such as IconWorld, CDPlayer,
Keyboard, and all of our preferences applications.
By this time the team had grown large enough that certain
development tools, such as source control and a bug-tracking
system, became essential. Ming Low, who had been in charge
of all of our builds, developed both of these tools and many
others to keep the development effort running smoothly as
the team grew. As the team grew, so did Ming's
responsibilities, which included system configuration,
network debugging, testing, and helping with each release of
the software.
All of our software, of course, was still running on the
dual-Hobbit, 3-DSP machine. While we were questioning the
wisdom of having specialized DSP chips on the motherboard,
we saw the entire future of the hardware cast in doubt when
AT&T canceled the Hobbit processor line. It was
decision-making time at Be again, and this time we saw the
opportunity to make improvements in several areas. We needed
a new processor and the PowerPC line seemed appealing on a
number of fronts. First, it offered pretty good performance
for the price. Second, it had the backing of a number of
industry leaders (Apple, IBM, and Motorola) who assured its
existence and design evolution. Last, but not insignificant
from our perspective, was that unlike the Hobbit, the
PowerPC chips had the ability to handle floating-point math
very quickly. We saw this as our opportunity to abandon the
specialized DSP chips and gain a much simpler system design.
This new design retained the ability to process
floating-point numbers very quickly, and was also able to
throw both PowerPC chips at general system tasks if
needed.
The entire PowerPC motherboard design, including the use of
industry-standard ISA and PCI buses, was accomplished by a
single hardware engineer, Joe Palmer. The port of our
software to the PowerPC processor was basically the work of
two engineers, Bob and Cyril. Bob worked magic as he
single-handedly brought up each revision of the new hardware
and debugged impossibly complex interactions between the
lowest levels of our software and the new hardware. Cyril,
meanwhile, rewrote a number of speed-critical,
machine-dependant pieces of the kernel, including the
interface to the memory management unit. The rest of us
"high-level" guys basically just continued our work on the
Hobbit boxes until the day Joe showed up in our offices with
new PowerPC machines. With a new compiler and literally a
simple recompile we had all of the applications, including
the Browser, running on the new PowerPC boxes.
There was another benefit from the switch to the PowerPC,
which we came to appreciate a great deal. Having designed
all of our software for the Hobbit we were forced to spend a
lot of time looking at performance issues, which we might
have ignored had we started with the faster PowerPC. This
resulted in a system that ran very well on the Hobbit
processors, but was noticeably snappier on the PowerPCs.
As the PowerPC design took hold we added another key
engineer, Brad Taylor, who quickly became the most popular
guy on engineering row when he implemented the TCP/IP
networking stack on the BeBox and ported the ftp tool for us
to use for file transfers. Before Brad ported ftp, we had
agonizingly used the tar tool to transfer files on floppies
from our UNIX development machines to our BeBoxes. With ftp,
Brad turned my transfer time for the Browser from one minute
to three seconds. Since most of you reading this are
developers, you know what a tremendous difference this makes
in the development process.
The team itself was run by our VP of engineering, Erich
Ringewald. Erich's contributions to the BeBox are
considerable. Along with writing kernel code, keyboard
drivers, and porting UNIX tools he has kept the team on
track throughout its existence. He has refereed fierce
battles in the engineering team and has made critical
decisions throughout the design process. Without actually
micromanaging any individual, Erich has managed to keep a
team with extremely diverse skills and personalities all
focused on the same goal.
Some of the other later additions to the Be product team
have been Melissa Rogers, Rico Tudor, Roy West, and
Guillaume Desmarets. Melissa is the self-described "chief
pitbull." She keeps the engineering team in line and is
responsible for the project schedule and about fifty other
things at Be. Rico was given the task of porting the bash
shell to the Be environment and writing a new ansi terminal
application to host bash. Roy thought he was just going to
write user documentation, but has ended up becoming our
webmaster, writing and editing marketing materials, and
proofing this newsletter. And he's even managed to write
some user documentation. Guillaume has joined us to help Joe
with future versions of Be hardware.
I hope this article has given you a feel for the evolution
of the BeBox hardware and software and for some of the major
milestones along the way. Even though we've worked on the
BeBox for a number of years there's still a great deal left
to do. With your help and feedback we'll continue to improve
the Be hardware and operating system to give your software a
solid base to run on. I hope to write a similar article in
the coming years that will continue the story, with all of
the incredible innovations you'll bring to the BeBox in the
form of enhancements, utilities, and ground-breaking
applications.
Be Developer Profile:
BoxTop Software
Anton Travis is looking for a better way to do things.
That's why he started BoxTop Software in Starkville,
Mississippi, last year. And that's why he's developing
software for the BeBox. BoxTop is a small (four person)
graphics software developer. They're marketing a new
graphics file format support library for Macintosh
developers, called the Box Graphics Library. An annual
license costs between $800 and $1,400. Travis expects to
have a version of the library available for the BeBox by
mid-March. The company is also working on a low-cost
alternative to Adobe Photoshop. It will sell for $90. BoxTop
plans to ship the imaging program for the Mac in the middle
of next year, and for the BeBox shortly thereafter. Anton
says the new, as yet unnamed, product will have a faster
memory management model than Photoshop, smoother editing of
large images, and significant improvements in layering
capability and text handling. The company has also produced
a couple of low-cost GIF and JPEG management shareware
programs for the Macintosh, called PhotoGif and ProJPEG,
that it distributes over the Internet.
Anton has spent the last ten years as a graphic artist and
creative director for his own graphics design agency. Over
the last few years, he's grown frustrated. "I got sick of
the graphics software tools that I had available and I
decided that I could do it better myself," he says. He's
also frustrated with Apple's "consistent blundering" of the
Macintosh platform. "I wanted something new," he says, and
the BeBox appears to be what he's looking for. We have high
hopes for the Be dual-PowerPC architecture. It's a perfect
platform for pixel graphics."
In fact, he predicts that with its low price, the BeBox
"could replace the Macintosh in desktop publishing if it has
the right software." Anton speculates that it will take two
years for the software to arrive, and then another three
years after that for Be to build a dominant position.
Anton says he is intrigued by Be's promise of an electronic
distribution system because it offers "low-cost product
launches with not much advertising." His goal is to use the
Internet and the world-wide web as his entire marketing
vehicle.
For Geeks Only
By Jean-Louis Gassée
Unfit for Consumption by Normal Humans
Why do we say such things about our products? What possesses
us? Are we suicidally trying to turn business away? Is it
some kind of perverse reverse chic, some image of
exclusivity we start cultivating in order to raise prices
later? After reading me today, I hope you'll conclude we're
merely using plain old common business sense and effectively
positioning our product in a way that makes the best use of
our resources.
Let's observe the record. Many new (and not so new)
companies enter the market with a great deal of
self-inflicted pressure. They feel they have to offer the
best of the past as well as the benefits of the future. Or
they think they must represent their products as fully
evolved, mature. In other words, they strive to represent
themselves, or their products, as adult at birth. Hardly a
comfortable position. I know from experience. The reasons
are many: Ignorance, political pressure, variations on
launch-pad chicken, denial, or simply greed. The litany of
consequences is well known. Much money and precious
reputations are invested and lost. Feeble and trite excuses
are made: The market wasn't ready, the infrastructure didn't
materialize, partners bailed out of the alliance.
It doesn't have to be this way. Let's review a well-known
example: Newton. Its birth was preceded by much hype. We
were witnessing the birth of a new genre, Personal
Intelligent Assistants. The total market for products,
contents, and services was going to exceed a trillion
dollars by the year 2000. And... handwriting recognition
worked. Now, imagine another scenario. The Newton is
announced as new technology, not a product, from the
Genuinely Exciting Evaluation Kernel of the company. Instead
of disappointing many early adopters, Newton is viewed as
interesting technology by fewer but happier customers. No
money is wasted in creating mainstream demand for a product
that doesn't exist yet, volume expectations are much lower
and met. As a result, when a promising product such as the
Message Pad 120 finally emerges, it's preceded by good
word-of-mouth, the money saved earlier is available, and it
easily and happily reaches the mainstream.
You see where I'm heading. I'd rather present the BeBox as
an infant product -- because it is. In its current state, it
can only satisfy two kinds of users: C++ programmers who
program for others, also known as software developers, and
C++ programmers who write code for their own projects. I'd
rather work with these users and raise the baby with their
help. This is not to say we don't have high ambitions for
the BeBox. Au contraire, we don't want to jeopardize
its future. For the time being, I'd rather narrow our focus
on the more technically competent and enterprising users,
learn from them, improve the product and our services, and
gain a decent reputation and interesting application
software. In our industry, word-of-mouth is still the most
potent marketing weapon. Advertising budgets and marketing
programs can build on a reputation, they cannot create and
sustain it.
Be in Europe
In early '95, Be, Inc. created a European office in
Paris. The European team is composed of: Jean Calmon, V.P.
Europe; Christophe Droulers, Developer Services Director;
Georges-Edouard Bé:ranger, Developer Technical
Support; and Marie-Claude Levrat, Administrative Assistant.
Our mission is to create a distribution channel for all of
Europe and to support our European developers, customers,
resellers, and "aficionados."
At Be, we all know that the BeBox needs the experience,
creativity, and talent of you -- the developer. For this
reason, our first efforts are to serve the developer
community. We'll give you all the support you need to create
powerful, reliable software and to break down market
barriers.
We know that developers often have the answers to other
developers' questions, so we've established a mailing list
for developers who want to chat, share experiences, and help
each other. If you'd like to join this list, let me know by
e-mail (my address is
droulers@BeEurope.com).
Another good way to sharpen your ideas is to share them in
person. So we're planning developer meetings in Paris, where
you can show your work to other developers. We'll stock an
office with everything you need to demonstrate your product
-- and even to work a few hours with other developers.
We want to do all we can to help you get your software on
the market. Do you need beta-testers? Tell us and we'll
provide you with the e-mail addresses of developers and
customers who want to help.
When your software is ready, you'll benefit from our
European commercial FTP site, where customers can download
demo versions or upgrades of your products.
On the Be Europe area
of our world-wide web site, you'll soon find a current list
of who's developing what in Europe. If your project's
missing, send me e-mail and I'll add it to the list. (Of
course if you don't want your name or project to appear,
we'll respect your privacy.) The list also contains links to
developers' own web pages, where you can learn about their
projects in greater detail.
Remember, my goal is to help you become the most productive
and successful Be developer possible.
Send me e-mail
with any questions about developing Be products in Europe,
or with ideas for how we can improve our developer programs
and services.
Sincerely,
Christophe Droulers
Developer Services Director
Be Europe
|
