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.

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:

• what you were doing, and where you were doing it

• what actually happened

• what you think *should* have happened

• detailed information about your BeOS system, including:

  • computer make and model

  • BeOS system version (and Mac OS system, if you're on a Mac)

  • amount of RAM and hard drive size(s)

  • graphics/video interface and monitor type

  • *everything* plugged into internal expansion slots

  • anything else that's interesting about your computer

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: http://www.be.com/support/index.html.

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: http://www.be.com/support/index.html, 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 alderete@be.com. Formality not required. ;-)

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:

• Allow you to setup various parameters like resolution, sensitivity and the like.

• Allow you to read the current settings

• Allow you to get the current position information

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:

ftp://ftp.be.com/pub/dr9/samples/wacom2.tgz

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!

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 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: http://www.be.com/aboutbe/mailinglists.html.