As you probably already know, the file system and database are being ripped out, rewritten, and replaced by a whizzy new architecture. Understandably, the file system has quite an impact on the implementation of the Browser. Almost any change to the file system trickles up (or is it down?) to the Browser, requiring some amount of tweaking. So, as the Browser's keeper and faced with the file system sea change, I made an executive decision: Let's change the Browser's name...

Meet the "Tracker."

Unfortunately, simply changing the name wasn't enough of an upgrade to make the Browser—excuse me, the Tracker—work with the new file system. So, like the plastic surgeon my parents always wanted me to be, I've taken out my little bone hammer and cartilage saw, and am busy whacking and hacking. And, since I'm covered in blood anyway, I'm also going to add some new features to the Brow... (oops) Tracker that have been on our wish list for quite some time, including:

• "Live" icon dragging (as opposed to dragging an outline)

• Outline mode for list views

• Resizing and reordering of list columns within Tracker windows

And, for those of you who just can't get enough clutter:

• Icons can now live on the desktop.

Another change we're introducing in DR9, one that was influenced heavily by feedback we've been getting from our developers, is the way we handle file types. The old 4-byte type and creator scheme is being replaced with an identification system based on MIME types. As I'm sure most of you know, MIME (Multipurpose Internet Mail Extensions; RFC 1521) has become a de facto standard for sending e-mail on the Internet. The basic MIME concept is a major/minor designation for identifying the contents of a file. There are already a number of MIME type definitions; we'll leverage off of the existing definitions and allow developers to define their own MIME types for use in the BeOS.

To support MIME typing, the new Tracker will let you designate a "default handler": an application that's responsible for opening files of a particular type. For each distinct MIME type you can designate a particular default handler. For example, when you get a new paint application, you designate it as the default handler for your existing image files. Next time you double-click an image file, the new application opens the file.

The default handler scheme is convenient—but some files don't want to be stereotyped (so to speak). To fine-tune the file-opening mechanism, you can designate a "preferred handler" for an individual file, overriding the type-wide default handler. In other words, when you double-click a file, the Tracker looks to see if that file has a preferred handler: If it does, it uses this handler to open the file; if not, it uses the default handler. The preferred handler is part of the definition of the file (it's one of the file's "attributes," as the concept was described by Dominic Giampaolo in Be Newsletter 51); if you move the file, the preferred handler designation goes with it.

And as if this weren't flexible enough, the Tracker will also provide a menu item you can use to open a file with yet another application (beyond the defaults), on a one-time basis.

The "file handler" functionality will be extended to folders and queries as well. By setting the preferred handler for a folder or query, you can create and display your own folder and query windows. For example, let's say you create a mail application that knows how to list the contents of your mailbox. By setting the mailbox's preferred handler (keep in mind that the mailbox is simply a query), your application will automatically be launched whenever the mailbox is opened.

One of the features of DR9 is that the OS will recognize (certain) nonnative file systems. Of course, we don't expect foreign file systems to adhere to our MIME file-typing scheme, but we don't want to exclude them from the file handler mechanism. So in DR9 the OS will map file extensions to specific MIME types. Again, you'll be able to use the Tracker to set the correspondence between extensions and types.

With the default and preferred handlers, the one-time handler override, and the extension-to-MIME mapping, you should find that the new Tracker is much more flexible in the way that it opens files, folders, and queries than was the old Browser. (Please keep in mind that these new features are still under development and could change as DR9 comes together.)

I hope this has given you a taste of some of the things we have in store for the DR9 Tracker.

I arrived at Be in the whirlwind final days of DR8, our first release for the Power Mac. DR9 was but a dream and Macworld was still months away. Then there was the announcement of the deal with very cool Power Computing, and the worry and excitement surrounding the maybe-deal with Apple. Nonetheless, it seemed that as fast as I logged bugs, bugs got fixed. Big bugs, small bugs, I had never seen such action in seven years of testing in this valley.

Testing is a fairly simple process of re-creating system crashes, application failures, and redraw problems—in other words, you break stuff. The key word in this process is "re-create." You log, in a database, the set of 3 to 5 steps that caused the application or the operating system to fail. The trick to testing is in remembering how it broke, and to break it again. To move around and find the holes, pointing them out for the crew to fill. The art of testing is driving into places the engineers never thought to go, to stress their structure, to do what was never expected, do what the end user might never do.

Outside my cube is a little sign that says, "Testing is an art," below that, "Je par lisale la code," which roughly translated means, "I can't write the code." I am, in essence, simply a computer user with an uncanny knack for breaking stuff.

Be's Web site has a page where developers can log bugs they find. In addition to regular testing, it's my job to sort through this database and extract all the problems I can reproduce. This is a big job that leaves my cube cluttered with bug printouts, stacked in a half dozen piles labeled "Need Hardware," "Repro," "Not a Bug," "Duplicate," "Feature Request," and so on. Many of these bugs are code issues, tricky reports that are, on average, split half-and-half between real bugs and bad code. Before Macworld all of these code bugs were reviewed by the Be engineers. As we draw closer to our first real release, we've added two new faces to QA. William Bull and John Standerfer, Be's newest interns and junior-Be-engineers. In addition to working out their own tests for the BeOS, William and John will disassemble developers' bugs, separating problems with the system from problems with the developers' code. They're bright and enthusiastic artists.

My daughter was sick last week, and she didn't throw up... Speaking of which...

Well, George Hoffman is gone, but his spirit will live on, and I'll try not to disappoint him with a lack of segues and other irrelevancies.

There is one thing that continues to create amusement for me and that is the source of my happy demeanor as I go about my daily duties. Every day I step off the elevator into the lobby of our offices, I have a smile on my face and a spring in my step—ask our receptionist. The thing that keeps me happy is the fact that I'm not currently writing mission- critical custom apps, or trying to come up with new inventions every year. I have the pleasant and enviable task of demonstrating to the world how cool the fruits of other people's labors are.

If you attended Macworld at all and saw any of our demos, you saw a few new applications in our demo suite that weren't there before. One of them was a 3D demo: We dropped a live video stream onto the pages of a book and turned the pages in real time. This spectacle of video giddiness was accomplished because of many factors.

The primary instigator was Pierre Raynaud-Richard, Mr. Graphics Dude Extraordinaire. Before he took off across the pond for Christmas, he put together what is essentially a preview of DR9's 3D Kit texture-mapping capabilities that runs in DR8. We can't release the source for this application because it includes the source for the 3D Kit, but we will be releasing the binary so that everyone can try it on their own machine. You can find it at:

ftp://ftp.be.com/pub/Samples/3dmov.tgz

Mind you, this demo works best in certain circumstances and on machines that have an L2 cache with some size to it. It works best on the Power Computing PowerTower 180 due to its fast memory bus and on-board video chip.

To go along with this demo, there's a driver for a particular video digitizer board as well. You can find this at:

ftp://ftp.be.com/pub/Samples/Bt848.tgz

This supports the WinCast/TV dbx Model 401 from Hauppauge. This is a video digitizer board that will do NTSC and PAL and even includes a TV tuner. The driver will do direct-to- memory (DMA) transfers. If you want to get really nasty you can display directly to the screen. Otherwise, you can display into a chunk of memory and have your way with it. Oh yes, I must mention that this board only costs $145! I'd say that's quite a deal for such a handy little piece of equipment.

Like the QuickCam driver before it, this driver inspires creative action —at least I think so. Go get it, play with it, have fun, and create those killer multimedia apps.

A little more than two weeks have elapsed since our San Francisco developer's conference. We've had time to collect feedback and distance ourselves a little from the heady atmosphere of the Macworld week. The clearest message of all is we need to have separate sessions next time. Some attendees are familiar with the BeOS and are more interested in updates on our plans or specific topics such as the media kits. Others come to get acquainted with our platform and evaluate the opportunity we represent. They need technical and business information. And overall, we need to polish some of our presentations. At a developer's conference, we're concerned with avoiding the marketing label. (See the recent Doonesbury strip, where Mike is concerned Kim's friends will tease her for being engaged to him. "After all you're in marketing," she replies.) It looks like we went a little too far on the side of the unshaven, natural look.

One of the Frequently Asked Questions these days is: When will [insert leading multimedia developer] port [insert leading product] on the BeOS? We know what happened on the Mac with leading Apple II software players. Not much. The same thing happened to Bill Gates with Windows. Before it became the juggernaut we know today, Microsoft had to evangelize DOS developers, beg them to port their leading DOS applications to the unproven Windows. The leaders of the day declined. "IBM is the standard setter," they said.

At the time, Lotus was the leading spreadsheet player, Lotus 123 had been the tractor application for DOS in corporate America, and WordPerfect owned the word processing market, with a sterling reputation for free customer support. They were very busy with their prosperous franchises and had trouble finding the resources to allocate to what was then a new and unproven OS, especially against the backdrop of IBM's reputation.

I know I'm treading strange ground when evoking these situations. But the basics remain. The incumbents are busy caring for their franchises. If I were the CEO of one of the leading Mac multimedia companies today, I would have a hard time selling Wall Street on investing in the BeOS. The risk is too high, especially when the financial community is down on the Mac and is providing zero investment support to the developer community. Right now, Wall Street is telling these CEOs: "Move to Windows NT." If they like their jobs, they have to listen. To us, it means we focus on the new blood, on developers who don't have a franchise to protect, who, like us, have no baggage and have the freedom to take risks on the BeOS. Their applications are more likely to be optimized for the new platform, and they're more likely to bring fresh new thinking to the genre, if not to establish new ones altogether. On our side, we have to deliver the product and the support they require and populate PowerPC hardware with the BeOS. Not a simple easy task, but at least we know what we have to do to be successful together.

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.