Be Newsletter

Table of Contents

• BE ENGINEERING INSIGHTS: Browser No More, By Steve Horowitz
• BE ENGINEERING INSIGHTS: "JE PAR LISALE LE CODE," By Baron Arnold
• News From the Front, By William Adams
• Developers, By Jean-Louis Gassée
• BeDevTalk Summary

---

BE ENGINEERING INSIGHTS: Browser No More

By Steve Horowitz

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

• 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.

---

BE ENGINEERING INSIGHTS: "JE PAR LISALE LE CODE"

By Baron Arnold

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.

BEST DEVELOPER BUG OF THE WEEK

Submitted by Joseph E. Trent at Utexas

Simple, elegant, save your work before you try this:

1. Start the Workspaces application.
2. Hold down the Tab key.
3. Click on the dock.

Cool, huh?

BeQA encourages developer correspondence -- but please, when you report a bug, be clear and succinct. Help keep bug reproduction easy by reporting clear and simple steps. (Bug reports as run-on sentences float around my desk for days!)

So enough for now. Look for more in the weeks to come.

Write 'em up!

---

News from the Front

By William Adams

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/3d_kit/obsolete/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/drivers/obsolete/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.

IN OTHER NEWS

Since we stole Hiroshi away from his native Japan, we've been telling him he can go home again only after he incorporates his styled text engine into the BeOS and releases the code for his screen saver as a sample application. After many rounds of 'Just Do It!' he's on the way and much pleasantness should come from this.

For those of you who've dealt with our technical support in the past, having more able-bodied, intelligent people to work for you should come as a welcomed state of affairs. We're in the process of putting together our fresh new tracking system, which holds out the promise of making our responses to developers more timely and useful. We'll of course make a bigger deal about this when it's on-line and useful. We believe you'll be pleased and benefit tremendously from our efforts to make programming for the BeOS easier.

Also, in order to reflect the sea change that's occurring, I've decided that we could use a better name. Now you can refer to those people that help developers as "Be Developer Services."

Our charter is roughly to:

• answer technical questions

• help with the design/architecture of BeOS app ports and new apps

• create tutorials

• create (or cajole) sample code

• manage _limited_ early release programs

And that's what we're going to concentrate on this year. Happy developers are productive developers, and productive developers make useful applications.

So there you have it. New faces, new code, new systems. Our company may be small, but that doesn't mean we're amateurs. We'll continue to work closely with our developers and we hope to have a developer services organization that's as enviable in the industry as our OS is.

---

Developers

By Jean-Louis Gassée

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 Summary

BeDevTalk is an unmoderated discussion group that's a forum for the exchange of technical information, suggestions, questions, mythology, and suspicions. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the group.

To subscribe to BeDevTalk, visit the mailing list page on our Web site: http://www.be.com/aboutbe/mailinglists.html.

• -----WEEK 4---------------------------
  Subject: Avoid skipping list elements!!!

  In a thread that's been around for awhile, but really sprang to life in the last week, it was pointed out that the kernel's get_nth_X_info(), BQuery's RecordIdAt(), and other nonstatic, info-gathering, and list-compiling functions could be considered unsafe because they don't lock the data that's being collected and could miss existing elements, or include since-deleted data. This could be corrected (in some cases) by providing atomic lock-collect-unlock functions.

  It was countered that many of the functions that were contested aren't intended to be "reliable" -- the get_info functions, for example, are meant as debugging aids, not predicates. The validity of the proposed locking scheme was questioned.

• -----WEEK 2---------------------------
  Subject: C++ question
  AKA: Automatic template creation

  Continuing discussion of the possibility and advisability of inlining virtual functions. Also, a discussion of templates; more specifically, some listeners yearned for automatic template instantiation (as provided by some version of SunSoft).

• -----NEW---------------------------
  Subject: Threading issues
  Subject: Redirect me to a good C++ group....

  In these otherwise unrelated threads, listeners asked for good MP and C++ references. A number of recommendations, among which the newsgroup, comp.programming.threads, is a good (and inexpensive) place to start for MP issues, and http://mini.net/cetus/software.html for C++.

• -----NEW---------------------------
  Subject: Thoughts on Fragile Base Class problem.
  AKA: Fragile Base Classes Redux

  Is the fragile base class solution (reserved functions and variables, with library versioning) a hack?

  A number of developers wrote in to urge Be to come up with a more universal and satisfying scheme. Others think that the payoff from an "ideal" solution is, in practice, not worth the trouble -- the "hack" may turn out to be smarter than it looks.

  Some interesting angles appeared: Versioning to correspond apps to libraries is fine, but what happens when the (currently private) interface to a server changes? Will the FBC problem be compounded if server API is published? Does an acceptable FBC solution (implementation pain aside) even exist?

• -----NEW---------------------------
  Subject: How to dynamically resize views

  How do you dynamically resize windows while the mouse is down? Do you have to run a separate thread to watch the mouse (to avoid locking the drawing thread)?

  Some folks opined that a mouse-watching thread is a legitimate use of resources; others objected. Source code illustrating various approaches was offered.

• -----NEW---------------------------
  Subject: Blow it away!

  A listener wondered why the shut down "Blow it away!" button doesn't seem to work reliably. This lead to instructive recommendations from developers on how best to not fall into the debugger, what to do when you do drop in, and which debugger windows to be wary of.

  THE BE LINE: In addition to the other recommendations (make your app multilaunch while testing, don't exit the kernel debug thread, and so on), you might try keeping a Terminal around for Browser-frozen emergencies: Kill the Browser and start a new one in the background.

• -----NEW---------------------------
  Subject: Booting a Mac vs. a Box

  Some discussion (and some misunderstandings) of the purpose of the BeOS partition on the BeOS for Power Mac CD.

• -----NEW---------------------------
  Subject: virtual processors on mono-processor machines

  Riddle of the week (contributed by Marc Nelissen):

  "...consider a data structure [on a single-processor machine] that is protected by a spinlock, and is accessed from both a realtime and a non-realtime thread. If the non- realtime thread is holding the lock, and gets preempted by the realtime thread, you're toast. The realtime thread will never get preempted by the non-realtime thread..."

  Mr. Nelissen went on to propose a virtual N-processor machine: The scheduler would simulate multiple processors by dealing time slices evenly to each of N virtual CPUs. This would greatly assist testing, and would be a lot cheaper than buying a second machine.

  It was objected that simulating N CPUs may be misleading, since it ignores other facts of MP life (notably multiple caches). Also, it was argued that (to quote Jon Watte)...

  "Excluding real-time threads, there are no problems that will happen on N CPUs that won't also happen on one pre- empted CPU."

• -----NEW---------------------------
  Subject: Uptime, Multi-user support
  AKA: Hot-Swap Hardware

  How long should a system be able to stay up -- weeks? years? There are two issues here: Stability and "hot swapping."

  Clearly you don't want the system to hard crash, but you also don't want to have to reboot to get the system to recognize new resources (fonts, drivers, drives, and so on). As Chris Herborth put it:

  "I'll happily reboot for a kernel upgrade but that's about it."

  However, it may not be that easy, particularly when it comes to plugging in hardware while the machine is still on. (Dave Haynie contributed a concise introduction to hot-swap physics and chemistry.)

  Also, how should Be do multi-userness? A form of the UNIX "runlevel" setting was proposed: runlevel 1 would mean single user; 3 would require user/group/root permissions and passwords, and so on.

  Another listener proposed a proximity test: If you're driving, you have unlimited (or less limited) access; if you're telecommuting, you have to show your passport.

• -----NEW---------------------------
  Subject: long long support

  When will long longs be supported? Are they safe?

  THE BE LINE: DR9. Long longs require two 32-bit registers, so they can't be accessed atomically.