Mar 97 Factory Floor
Volume Number: 13
Issue Number: 3
Column Tag: From The Factory Floor
Jon Watte, Metrowerks BeMeister
By Dave Mark, ©1996 by Metrowerks, Inc., all rights reserved.
This month's Factory Floor interview is with Jon Watte, leader of Metrowerks BeOS
tools effort. With all the interest in the BeOS brought on by prospective deals with
Apple (as of this writing, not yet decided) and a bundling deal with Power Computing, I
asked Jon if he wouldn't mind answering some questions about his involvement with
Be.
Dave: How did you hook up with Metrowerks?
Jon: All the applications I wrote and designed at SCOOP were coded using the Think
Class Library, using Think C versions 6 and 7. When the time came for Apple to roll
out the PowerMacs, Symantec did not have a solution for us, so I went ahead and ported
the TCL from Think C+- to "real" C++. I also wrote some utilities that would do the
hard work of converting a TCL application to use this TCL version for PowerMac. I
released this port publicly in several versions and, through it, got the attention of
people at Metrowerks.
Meanwhile, my wife and I entered into something called the Diversity of
Immigration Visa Lottery, or "green card lottery" for short, where US immigrations
randomly selects among qualified applicants from nations with under-representation
in US immigration statistics. Most people don't "win" this lottery, but my wife did. The
only crux was that you had to secure an offer of employment from the US to be able to
enter. I guess they were afraid people would move from the Swedish welfare system to
live on American welfare. I e-mailed everybody I knew in the US from the ‘net and
visits to trade shows, and literally thirty minutes later I had a reply from Greg
Galanos, saying he had just thought about me for this secret new project they were
starting... the Be port of CodeWarrior.
Dave: What were the early days in the Be universe like?
Jon: I actually had one of the first BeBoxes at home in Stockholm, a machine based on
the AT&T Hobbit. The hardware wasn't very fast, but the machine was nice anyway.
Once I managed to clear through the US visa process (which took much longer than I
would have liked), I moved to the US at the same time as the PowerPC-based BeBox
prototype appeared.
At first, the machines were very bare-bones; I had the deluxe model with a sheet
metal frame (no cover) whereas people at Be usually kept their machines as circuit
boards laying on their desks (they still do.) Back then, there wasn't even any
debugging except for printf(). You compiled your program on a Mac using
CodeWarrior, FTP'ed it to the BeBox, ran it there and watched it spit out text in a
terminal window.
There was only a small circle of developers then, many of them from France
where Be got much of their initial capital. There were also no mailing lists or news
groups in which to discuss the system - they were keeping a very low profile in order
not to hype the machine before it was ready to be shown. We all worked under NDA and
had to cover the machine with blankets when relatives were visiting. Every two to
three months, we would go to Be to talk about what we were doing and in which
direction to move, as well as bug them until they fixed the bugs we were running into.
Dave: How did CodeWarrior for BeOS evolve?
Jon: My initial task once I moved to the US was to design and write an IDE, while the
other team member (another John) ported the compiler and linker. One interesting
quirk soon developed; Be was doing all the compilation under SCO unix and Linux,
because those boxes could run NFS which was needed for their source-code control
system. In fact, I think they still do. That meant that we had to port our compiler to
run under unix on a little-endian machine, a job which later turned out to benefit us
when we ported to Windows.
Anyway, while we were cross-developing from the Mac, we soon felt the need for
a cross-debugger as well. The only problem was that the BeOS did not support
debugging - and since it has protected memory, you can't just write breakpoints into
code as you can on the Mac. I put the IDE work on the back-burner and helped Be
co-design the system API for debugging, based on the requirements the Metrowerks
debugger had at that time. Once that was done, I could write a debugger Nub that ran on
Be and adapt the Metrowerks debugger to talk to this Nub instead of a local Mac Nub.
This was still back when the machine was secret, and we wrote the debugger mostly for
our own use and that of the few select developers in on the secret.
When I was almost finished with this, the other team member left Metrowerks,
and I was left alone in charge of the Be team. Quickly finding another programmer to
help out (Brian Stern) as well as leveraging the skills of the MPW/command-line
tools guy (Mark Anderson) I put together a new Be team within Metrowerks, and
showed Brian the design I had for the IDE. Mark already did MPW compilers and
linkers, and quickly caught on to Be, which left me with the task of writing the "real
Be debugger.
Dave: Is that where the Be version of PowerPlant came to be?
Jon: Yes. We looked at the cross-debugger, and wondered how to move the technology
over to BeOS. It turned out that the debugger source code had some ugly interrelations
between UI and functionality that made perfect sense on the Mac but wouldn't work in
the multi-threaded Be world. So we had the choice of developing a new debugger from
scratch, or somehow porting the MacOS debugger. After some going back and forth, we
settled on making the debugger believe it was running on a weird kind of Mac. Since the
debugger code was non-reentrant, we had to re-implement the entire event loop layer;
the current Be debugger still sits in WaitNextEvent() waiting for things to be thrown
at it. Since all of the former Mac code runs in the same thread because of that, the
reentrancy problems went away, at the cost of implementing about 300 toolbox calls
and some PowerPlant classes.
Dave: What is the state of Be development today?
Jon: The larger companies that have lots of code vested in other OSes are being silent.
I'm sure they're working with BeOS internally, but need more time to see if it'll be a
viable platform. Meanwhile, smaller, nimbler developers who don't mind throwing
away lots of code and starting over are waking up and smelling the coffee - a brand new
frontier waiting for fortunes to be made off of it.
If you're thinking of moving a Mac program to the BeOS, you have to realize that,
PowerPlant portability or not, it may be hard, or not even make sense. The BeOS is
different; it has a different UI and a very multi-threaded concept. Users are quickly
getting used to being able to perform all kinds of actions simultaneously, and modal
dialogs are few and far between. Mostly because they're so hard to implement, I think,
and I love it that way. It's easier to create a modeless dialog than a modal!
If we make the PowerPlant layer available, it'll probably be useful if you have a
PowerPlant application on the Mac, but it'll also still require work in the app. It's not
a miracle pill. The current version "solves" the re-entrancy problem by having all
the windows and menus send messages to the one "Mac Toolbox" thread, which means
that the program will never truly feel and behave like a real Be program.
The right thing to do is to re-map the interface classes you may be using
currently onto Be classes, and make sure that the underlying "engine" code is
thread-safe and re-entrant. Maybe you can even take advantage of some BeOS features
on your code, such as easy add-ins, pre-emptive multitasking or memory mapping of
data files. That will make an application sing, and is of course the direction we want to
take our internal code in. Whether this will be done in the PowerPlant context, or by
separating engine from UI remains to be seen.
Dave: How stable is the Be platform for development?
Jon: Well, I don't have to reboot the machine every time I crash. It's sometimes also
nice to have a command-line in the system - even though I'm a die-hard CodeWarrior
IDE user, I had to go to MPW now and then on the Mac. On Be, it's GNU "bash" that's the
shell, and there's a gazillion little utilities already written for it that you can use.
CodeWarrior runs well under the BeOS, although we spend much time waiting for
the file system. The new file system promised in DR9 looks as if it'll fix that problem.
Being able to type and edit unhindered while running a compile - or two! - at the same
time is something I miss everytime I go back to the Mac.
However, every four or five months, Be comes out with a new version of the OS,
and lots of things changed that you have to catch up with. Old programs don't usually
work on the new version of the OS, since they have the luxury of changing the APIs.
That will stop once they reach larger, non-developer markets; currently release DR9
(the next after the MacTech release) is supposed to be "Compatibility Lock".
It's extra hard for us, because our tools ship with the OS and have to be
developed, debugged, and tested by the time the OS ships - but Be typically fixes bugs
that breaks compatibility while we do that, and once the "last bug" is fixed, they
document it, test it, and ship, so we have to get in early, roll with the flow, and hope
the APIs work as we think they do...
Dave: How do you feel about Be's choice of C++ as the Be API standard?
Jon: I don't mind C++. It's certainly a language with wide industry adoption and also
well understood system characteristics. Many of the nicer, more dynamic languages
would need special hardware (mark and type bits in memory) to run really well,
which would drive prices up. Meanwhile, there's a lot of C and C++ source available
for porting; most public source is C or C++, so it's an obvious language to support.
Pascal affecionados will of course be somewhat unhappy, but in the grim world of
business, I think the sentiment is that they're not a big enough force to cater to
initially, although I hope Pascal and other languages will arrive at some point. We've
done some looking into this at Metrowerks, and there is no reason why you can't make
Object Pascal code generate C++ compatible objects; it's just a SMOP. ("Small Matter
Of Programming" - a term that means lots of sweaty work.)
The fragile base class problem has several different solutions, and I think it will
not be a big impediment to the BeOS. We've talked to them, and they're on the ball with
a solution.
Dave: Many prospective developers ask about the types of software they should
develop for the BeBox. Any advice?
Jon: There are lots of things I want to see. Sticking to the "content development" niche
that Be says they want to target, I could see how you could write an integrated radio
station program that kept all of the play lists, spot lists, helped out with traffic
planning, and generated all the reports you'd want. Storing the actual songs and
"canned" shows and interviews in MPEG and playing them back in real time from disk
or network would also come in handy. The BeOS is really tuned for this combination of
"soft real-time" and GUI tasks. Connecting back to my previous work in publishing,
given some people and some dollars, the right person could create a kick-ass
integrated newspaper publishing solution; the only problem being that Quark XPress
is a formidable competitor in page layout. But that is only part of the publishing chain;
the BeBox has everything else it takes to implement that kind of solution already.
Dave: Can you tell me about Datatypes.lib? (a data translation library Jon
wrote in his "copious" spare time and which is starting to see major adoption among Be
developers.)
Jon: The cool thing about BeOS is that everything is new. The bad thing is that it's
pretty sparse on the nicer amenities. However, the design of the BeOS makes it so that
Be doesn't have to provide every system service an application might want to rely on.
A case in point is Datatypes.lib, a generic data translation service much like
EasyOpen on the Mac, except with an API mere mortals can understand. It started as a
request to Be from some old Amiga developers to adopt the Amiga "datatypes" system
service, which apparently is a very basic way of identifying and loading the contents of
a disk file into an application. Many people liked the idea, but thought the Amiga
implementation was flawed, and a lot of discussion ensued. To cut down on the clutter
and flames, I decided one weekend to take the best of the discussion and just implement
it. I did, and posted the result for comments. The first round was pretty harsh (and
rightly so) but version 1.1 really had everything you'd need in a basic data translation
package, including identification, import, export, making it easy to write add-on
translators, and abstracting translation from storage so you could use any translator
going to/from any source (such as disk, memory, or a network connection). Judicious
use of C++ abstract base classes made this both forward compatible and easy to
implement.
The library wasn't all that hard to write, thanks to the Be kernel threading and
code add-on model, and people are already both using it in applications and writing
translator plug-ins for it. This means that your, say, sound editor program doesn't
have to know about every imaginable sound file format, just the "standard" format and
rely on Datatypes.lib to provide translation.