Issue 2-24, June 18, 1997

What I Did On My Summer Vacation

By Pierre Robert Chinn

My first day at Be happened to coincide with the start days of two interns, William Bull and John Standerfer, both gone now but with a lasting impression left in their wakes. For some time I was viewed by others as just another intern with a finite time-span in the company. Maybe it's because of how I look or carry myself or the inane questions I ask. Perhaps it's because I feel comfortable just sitting behind a computer and trudging through header files. Now, as the interns leave and new ones enter our doors I have often been stopped by other Be employees who ask how much longer I will be around. I think to myself, "Do they want to get rid of me so soon?"

Playing with software or hardware in development (that "Bleeding Edge" stuff) has often been called living life dangerously, working on the high wire without a net. One might get a shock from a piece of hardware (yes, I've done that many times); one might fry a new board or hard drive (yup, made that happen); or, you might start a little fire (well, it was little before I left the room!).

It really isn't dangerous, though. Have you ever thought what a test pilot thinks before he takes a new plane up? "Well, gee, it's not preventing me from doing this, so I guess I'll just have to try it." Ever heard of a test pilot, after crashing, ask the engineers where the reset button is? Okay, so I will admit that corrupting an OS or losing lots of data is a real pain and can get quite tedious day after day, but it is kind of amusing in a masochistic sense.

When I arrived, we were in the middle of Mac compatibility testing, for DR8 that is. Often times someone would come in and ask, "Where's the 8500?", "Is that computer a Tanzania?", "Have you tried, 'such and such' on Power Computing 'foo'?" Then I started to realize that there are a lot of configurations to deal with nowadays. So, we started to build a lab, of sorts. We acquired many different models of Macs (still only a small subset of what exists), wired them all up, and turned the switch. "Damn! Why'd the power go out!", I heard from next door. Hmmm, I thought, "Why'd the stereo just go off in the lab?" Oops, I guess I really shouldn't have daisy chained four power strips from one outlet. The office—now getting quite full with equipment and, often times, engineers—is at a constant 75-80 degrees, and is looking forward to a nice wading pool with flamingos and palm trees.

Black Box testing on a system or an application is always quite amusing. You get to try the most stupid, ridiculous things, wallow through incredibly tedious processes, and perform some quite natural actions. Then, of course, you get to answer the question from the engineer, "Now why would you ever do that?," almost always with the simple practiced reply, "Because I could."

To effectively test it would appear that you simply need to poke into regions of the brain of the engineers who created the stuff you worked on. After a period of probing you begin to discover when they got tired or when the caffeine wore off, and the effects that had on their creations. But, after this stage you have to discover or invent new ways to break their creations. Often times, by asking leading questions, one can find where they did not "bullet-proof" their code or skimped on the robustness of a feature. On the other hand, by simply getting to know who the engineer is you can discover how to not just break their work, but also possibly enhance and help create a robust and working piece of software or hardware. Okay, maybe it's a bit idealistic, but sometimes it actually works.

When writing tools, I often think about what a doctor once told me after I injured my back, "When I do this it hurts," "Well, then don't do that!" Writing test tools has a balance between being an amusing task and one that is extremely tedious. While one has the opportunity to play around with the API of some system and create tools or applications with wild abandon, a test tools writer also has to break down and trudge through the multitude of classes and methods and address such issues as performance and compliance. The results of this are applications that simply and efficiently go out and fragment your disk, or ones that become a robust but totally copyright-infringing reproduction of a well known game.

Tools are also created that test the sanity of some engineers and test the assumptions and patience of the use of things like void*. It is always amusing to look over some API and to find a method or function that allows a pointer to be passed in. Hmmm, I think, "What happens when NULL is passed as that parameter?" Of course, the reply from the engineer goes something like, "Well, don't do that! Do you really think I should be checking for that? No one would ever pass that in...", and the rant goes on.

So, here I sit in a lab with 20 computers, a multitude of monitors, keyboards, boxes of cables, stacks of hard drives, dead equipment and the air conditioning system wondering why it didn't just become that neat little fan for an RV. We play with the stuff as it comes out, come up with new scenarios in hopes that some user will never have to deal with what we come up with, and arrive upon amusing uses for technology. Working here never gets boring; new tasks and ideas appear every day. Somehow I guess, the tasks and problems that we overcome define a role that I play here. I just wish I knew what that was.

Please State the Nature of the Emergency

By Michael Alderete

When I had been working at Be for about a week, William Adams came to my cube and asked me to say "Please state the nature of the emergency." I did it, and he laughed his inimitable laugh and walked away. It wasn't until a few days went by, and I saw that week's episode of Star Trek:Voyager, that I got the joke.

It would seem William thinks I resemble Robert Picardo, the Holographic Doctor on Voyager.

I kind of like that. When people come to the Holographic Doctor he asks them, in a very formal way, what the problem is. Since I read and respond to a lot of the electronic mail that comes in to the Be offices, including a fair number of requests for technical help, I frequently find myself saying the e-mail equivalent of "please state the nature of the emergency."

What makes a really good request for technical assistance is a formal declaration of what is going wrong. When we get a request for help here at Be, we love it when you tell us four things:

When we get this kind of information, one of two things generally happens. Frequently, we instantly know what's wrong, and can answer immediately. People seem to like this.

Failing that, we're at least in the position to try to replicate the problem, and figure out what the solution might be, instead of having to ask for more information. Either way, BeOS users get help a lot faster than they might otherwise.

Of course, in the heat of an emergency, most people don't want to write a lot of stuff in a help request, or sometimes skip items on the above check list. Or sometimes the problem is fairly trivial, and it seems like a bother to write all the details out into an e-mail message.

Ed Romson, our Director of Support, wrote in Newsletter #72 about one of our solutions to this. We've created a Help Request web form, which we are testing internally right now, that should make the process easier. It will make it simple to remember to enter all of the information our technical support group needs to solve the problem, and it will make it easier to actually enter that information, by simply choosing items from pop-up menus and checking radio buttons.

The Help Request form will make its debut around the same time as the Preview Release, or a little before. When the form appears, you'll find it in the Support section of the Be web site:

Of course, some problems are so catastrophic that using a web form is not possible. We will, as Ed wrote, continue to handle support requests via e-mail and, soon, our support telephone number.

All of our available support resources are described on our web site:, which is updated constantly as we add resources. If you have ideas for information or other resources to add, that will help you to use the BeOS better, I'm eager to hear them. Please write me at Formality not required. ;-)

News From The Front

By William Adams

A funny thing happened on the way to releasing the mkimghdr code from last week. I tested with 8-bit GIF images and reawoke to the fact that you can't make any app_server calls unless you have a connection to the app_server, and that only happens if you have instantiated a BApplication object, and preferably created a window object as well.

In particular, you can't call index_for_color(), or now BScreen::IndexForColor(), unless you have met these criteria. Well, it's actually out now, just in time to be revisited by discussion of why you actually shouldn't do things this way in the first place. This just goes to show you, you're never too good a programmer to slap your forehead and say "Doh!"

Also last week, I mentioned the Wacom tablet code. Well after a similarly delayed release, I did manage to put out the fiddling code. Why fiddling? Because, you can open up the tablet and get all the information you want, but it's not exactly "integrated" into the system. As has long been known in the US, separate is not exactly equal. The current system may allow you to talk to a graphics tablet, but it does not really view it as a mouse! What can you do? You want to integrate your tablet in such a way that the tablet can both be used as your primary system mouse as well as get at the tilt, pressure and other information specific to a tablet.

The answer lies in a couple of places. First of all, there should be a /dev/tablet device that you can talk to. This driver, if it were ideal, would allow you to do a few simple things:

Generally the tablet position information should look something like:

struct tablet_position
    bool    proximity;
    bool    stylus;
    bool    buttonflag;
    int32   x;
    int32   y;
    uint32  buttons;
    bool    pressuresign;
    int32   pressuredata;
    bool    xtiltsign;
    int32   xtiltdata;
    bool    ytiltsign;
    int32   ytiltdata;

If you want to get the current position, you should be able to do something like this:

ioctl(fd, TABLET_GETPOS, &position);

That would be nice, but how does that make it look like a mouse? Well, it doesn't directly, unless the kb_mouse driver knew to open up this device and get positional information from it instead of from the serial mouse. Well, with a little fiddling about, you can create a new kb_mouse driver that can recognize a serial mouse, a PS/2 mouse, or a tablet:

In your application, you will still have to query the tablet driver yourself to find out about the tablet specific information, but at least you'll have your tablet acting like a mouse. It shouldn't be too long before some industrious soul creates a paint program that takes advantage of the tablet specific features, specifically pressure, and the switch between the nib and the eraser. Should be fun!

Clean Up

I'm headed to MacHack along with Benoît Schillings and Mark Gonzales. Hopefully we'll be able to entice some more of the Macintosh faithful to step into the light and generate some tractor-driving killers. Geoff Woodcock is done fiddling with iso9660, and that's going to be great fun. Now he's off to Europe.

And one last thing. In the past we have always distributed our samples and whatnot using gzipped tar files, the familiar .tgz file extension. Well, a new day is upon us. In the next release of the BeOS, the unzip utility that Chris Herborth worked so hard on will be a standard part of the system. What's so great about this? Well, the zip/unzip combo is a little more flexible than the tar/gzip combo in that it preserves the attributes associated with a file, and allows you to create self-extracting archives rather easily. Thus, in the future, our samples will be packed with zip instead of tar/gzip. We won't start yet, since we don't want to deliver samples that require you to go outside the box, but this will be our future direction.

So, it was my second Father's Day. When you're with a 2 year old, there is never a moment of their life in which they think someone else might be the center of the universe. Despite this, they do a fairly good job of making you feel happy to be called daddy. Yasmin's not old enough to buy me ugly ties, so she took me to the Monterey Bay Aquarium. Groovy, man. She was so wonderful and I had a really good time. And the best part was, she was so exhausted when we got home, she was asleep within the hour. As I kissed her good night, and shut the light, I had one last wish for this Father's Day night... One more compile!

Be Developer Funding

By Jean-Louis Gassée

One question keeps coming back with increasing frequency: why don't we invest in promising start-ups developing Be software? After all, without application software we are nothing.

Such a move would make more likely availability of exciting applications and it would leverage our own investment in the BeOS. (Let's quickly note the "increasing frequency" is good news.) On the surface of things, our investing in Be developers looks helpful. Yet, after careful consideration, we found that, on balance, such a move wouldn't be helpful to the commonwealth.

A first objection is easily defeated but leads to a more serious one. Too much money involved. Indeed, we would have no trouble identifying one hundred exciting projects, each one easily justifying one million dollars apiece in mere seed money. We don't have that kind of money and we don't think we should or could raise it. This company was started on the more than ever valid premise that we operate on different metrics. By this we mean we don't need the hundreds of millions of dollars larger companies have to spend to write a new OS, more often than not ending up with an unwieldy product.

Well, then, let's pick carefully a very small numbers of projects, thus keeping our outside investments consistent with our philosophy. This makes a partly hidden assumption: in fact, we'd be saying to ourselves we're smarter, more experienced, and better connected than professional investors, a.k.a. venture capitalists. This, I'm not prepared to assume.

It is one thing to trade criticisms sublimated into epigrams: VCs think entrepreneurs are too stubborn, entrepreneurs think VCs are too greedy, all is well. It is another to miss the essential point that investing is a profession, a craft, or an art—I'm sucking up—very different from our trade. Anointing or improvising ourselves investors could cause great harm. Still, some companies have "internal" venture funds. To the best of my knowledge, they rarely compare favorably with purely profit driven funds.

Admittedly, I'm influenced by having watched one such example from the inside. I observed frequent abuse of the word "strategic" in order to cover for politics and other human factors unrelated to shareholder value. Admittedly again, there are good counter-examples, they often happen with the help of a real venture fund running the show for the company. These are big and smart companies; we'll review the situation when we can call ourselves that.

Another objection is our investing in one company would create tension with other developers. Perhaps paradoxically, I could find a defense for that one. If we make the Be platform more successful, everyone benefits, not just Be shareholders and employees. Mangling metaphors: the tractor app will raise all boats. Still, it would be a difficult balancing act, it would create controversy and, as a result, absorb energy better spent elsewhere. In the end, the overriding reasons are I'd rather not assume we are smarter than the free market and the professionals accustomed to swimming in it.

BeDevTalk Summary

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site:


Subject: How to port software

Is it better to port, or should the scrupulous developer re-write from the ground up? Obviously, a re-write can show off more of a new OS's native talents, but is it worth the extra effort and time? The "port or not" threshold, for many folks, falls between developer tools (port 'em) and end-user apps (which should be all fresh and slippery). Rollin Weeks:

"Fred Fish and others are performing a tremendous service to developers in providing ports of things we already know how to use, even if we have to use them from the shell in the beginning. If we were to adopt a BeOS purist attitude, our development capabilities would be greatly handicapped."

There was some frustration over the lack of Be-native apps—where are the brave?—but a number of folks pointed out that a) There *are* apps in development b) It's difficult to maintain steady forward progress on a platform that's young and constantly changing its API c) Working without UI guidelines is less than comforting d) Working on a platform that doesn't have a huge built-in audience requires a lot of faith. The general feeling was that there is a sufficient number of people with sufficient faith, and porting is a great way to solidify the indoctrination.

Another notion, somewhat orthogonal to the port/don't port question, is that a new OS has to find itself a niche. Jake Hamby offers the following niche possibilities:

  • The embedded arena (...think set-top boxes...).

  • Hard-core gamers (think 3D acceleration and "bang for the buck").

  • Scientific and engineering applications: a market that has yet to be tapped...

  • New Internet technologies.

Subject: Be Newsletter Issue #77, June 11, 1997

Rraster vs. the Datatypes lib. Which plug-in format does Be officially support? Is it foolish to write Rraster codecs, or is this exactly what the savvy Be developer should be doing?

THE BE LINE: Rraster codecs will work with the Datatypes library. William Adams' continued work on the Rraster codecs shouldn't be taken as an assault on the Datatypes beachhead. The bottom line: If you're writing a codec, heed the Datatypes format.

Subject: Prefs: Lowest Common Denominator is *NOT* C...

What's the best language/mechanism for designing a preferences "server"? The major candidates:

  • Straight C: It's easy, portable, and ubiquitous.

  • C++ BMessage subclass: More in keeping with the Be lifestyle.

  • BMessage-like protocol: Similar to the above.

It was admitted that C is much more portable, but is porting preferences code useful or even desirable? Mixed feelings, here.

Subject: Anyone interested in GLUT (OpenGL®)?

Will the GLUT library be on the DR9 CD?

THE BE LINE: No—sorry about that. But keep your eyes on the Web site; we hope to have the library ported and posted sometime soon.

Subject: Pictures in BeWare list

Here we read a number of requests for the BeWare catalogue:

  • Include a screen shot of each app.

  • Provide a topical search function, and by-app keywords database.

  • Organize the entries for easier cross-referencing.

THE BE LINE: Ron Theis, Be's Web site Maitre and BeWare fiddler, is hard at work improving the catalogue's look and taste. He sez:

" are some interesting things you'll be able to do with [the BeWare database] soon--look for my Newsletter article next month..."

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.