Volume Number: 13 (1997)
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.