At the Macworld Expo in Boston last August, Be demonstrated a version of the BeOS™ running on Macintosh hardware. In light of all the mischief this caused, a brief romp through the technical issues should be entertaining. At least to some.

How did we get the BeOS to run on a Mac? Tackling the intricacies of starting an alternate operating system using the Mac ROM's Open Firmware was too much to stomach on the hard deadline schedule that we had for Macworld. So, we took the easy route: Rather than boot from scratch, we let the Mac OS come up, and then we launched the BeOS as an application. The application is called OS Doubler, a name sure to send some lawyers scurrying for their legal pads and cell phones. Lest they get too upset, remember that this was just a demo.

OS Doubler loads a piece of code that's remarkably similar to the boot ROM in the BeBox. This code is called BeOS_Enabler—a name that is, we realized later, a bit confusing since it has nothing to do with Mac "enablers." More lawyers—yikes!

Once BeOS_Enabler is loaded, the application grabs complete control of the machine and jumps to the start of the enabler. From there, things proceed much as they do on the BeBox: Look for disks with a Be file system, find a kernel, load it, start the app_server, and so on. The Mac memory image slowly disappears, eroded by the constant infusion of vibrant new BeOS code.

The Mac version of the BeOS differs very little from the BeBox version. The kernel is different, and a few drivers were added and some removed to address the different peripheral hardware controllers. The rest of the software is the same.

What Macintosh platforms does/will the BeOS run on? The demo ran on a very limited subset: The 7200-based platform with a 604. In fact, it didn't support the 604e when we arrived in Boston. Power Computing lent us one of their new boxes, we got the kernel sources in the booth after hours, added 604e support back in the hotel room, and demonstrated a 225 MHz system the next day!

Here's a list of the architectures that we support now and those that we plan to support in the coming months:

Now (the demo):

Power Computing PowerCenter (7200, 604)
Power Computing PowerTower (7200, 604)
Power Computing PowerTower E (7200, 604e)

November developer release (DR8 software with better Mac support):

Power Computing PowerWave (9500, 604)
Power Computing PowerTower Pro (9500, 604e)
Apple 9500 (604)
Apple 7600 (604)
Apple 8500 (604)
UMax S900 (9500, 604)

Q1 97 (DR9 with complete Mac support):

Power Computing PowerBase (5400, 603)
Apple 5400

The 9500 support involves writing a few graphics card drivers as there is no onboard graphics controller in that machine. We need to write a SCSI Interface Module (SIM) for the 9500's MESH SCSI controller. We also want to quickly add support for the onboard Ethernet controller—for Macworld, we used one of the PCI cards we ship in the BeBox.

Supporting the multiprocessing cards is high on the list as well. The BeOS is built for SMP from the ground up, so this is a natural fit. Barring any unforeseen technical problems, this should be straightforward. All the words count here...

Living comfortably in the Mac world is very important. Media sharing, network compatibility, and installation all are important issues. We will tackle them all and come out with the BeOS on the Macintosh in Q1 next year.

I recently joined Be, Inc. as a Technical Evangelist. My mission (as I've decided to define it) is to spread merriment, write code, and help developers realize how fun, easy, and beneficial it is to develop applications for the BeOS. To this end I will be producing a number of applications and tools that help developers get the most out of our system. At the same time, I want to find out what you're thinking and get your comments right back to the Be engineers as quickly as possible.

I've been one of you before: I was a third-party developer, critic, sometime-advisor, and guinea pig for NeXT and NT. I've also worked with things that never really saw the light of day, such as Taligent.

I'm a decent, highly opinionated programmer who thinks he has something to say about everything. And that's why I joined Be. I like the BeOS so much that I couldn't pass up the opportunity to take my opinions right to the source where they will have the most impact.

I really enjoy the bleeding edge. I feel most comfortable pushing the envelope, while at the same time presenting with dramatic understatement the power of a new technique, algorithm, or paradigm.

The BeOS offers a fertile ground upon which many applications will find purchase. As I see it, my job is to help developers ply their trades on this fertile ground and produce applications that they and their users will find great pleasure in and laugh giddy with excitement down the halls because it was so easy to do. But the system isn't perfect and is ever-evolving. So that's the other part of my job, to bring your comments into our house so our engineers can benefit from our developers' wisdom to make a better system.

Every week I'll present "News from the Front" in the "Be Newsletter." There's a lot of information in the Be community—some of it ends up on the comp.sys.be news group, some ends up on the BeDevTalk mailing list, and still more shows up on the ftp.be.com ftp site. I'll summarize some of the more interesting things and try to highlight new apps that no one can do without.

In addition to the highlights, we'll put out "From The Bench." These are application snippets that either I have written, or I have wrenched out of the hands of some poor unsuspecting engineer while they were screaming "it's not clean enough yet!!"

To start things off, my first sample deals with the care and feeding of the game controller ports on the BeBox. This sample code shows how these interfaces can be used in a multithreaded environment to maximum effectiveness. Some of the concepts demonstrated are:

• Polling a device using a thread
• Automatic calibration and self-centering a joystick
• Message dispatching

The tutorial packet can be found at: ftp://ftp.be.com/pub/Samples/Joystick.tgz

I have also taken on responsibility for the sample code that currently exists at the site. I hope to keep it up-to-date with the current release, and will archive old stuff for posterity.

Well, I weaseled my way into this issue of the newsletter, and even wangled myself a permanent spot. So, I hope y'all are ready to have some fun, because I'm enthusiastic about programming this OS, and I intend to spread my infectious enthusiasm as widely as possible.

The goal of my endeavors with the Be system is to develop low-cost molecular modeling software for students and researchers who need power and a sophisticated graphic interface, but who don't have the financial resources for an SGI. My interest is in providing a software tool that has the performance to allow users to visualize their ideas without being chained to the canned algorithms supplied with many commercial applications.

Currently, I am completing a PhD in molecular biophysics. Most of my work is developing computational studies that predict the structural stability of proteins under changing solution conditions. But a personal interest in computers has taken me further towards software than science. My NeXTstation is still running as good as the day I bought it six years ago, and when I first heard of Be, it seemed a kindred spirit. In addition, the multiprocessor technology is appealing since it promises better price/performance for the kind of graphics-intensive work I am interested in.

Working with Be is a chance to find like-minded people with a vision who are willing to take risks. The port of OpenGL® sounds like another opportunity to expand my horizons, but I hope to incorporate its strengths into my software. So far, the hardest thing for me has been figuring out how to organize a commercial-grade application (all thrust, no vector). The projects I have designed myself are relatively large but nothing I would think of as having commercial characteristics (for example, robust error checking, standard documentation, and upgradability).

As a relative newcomer to the US, much of my knowledge of the culture of this great country has been derived from what I read and saw while still a resident of England. During my formative years, I learned all that I needed to know about the US by watching Kojak, Hawaii-Five-O, Scooby-Doo, The Monkees, and Lost in Space, and by reading books about American history. One learning experience stayed most strongly with me and, ultimately, affected my decision to move to California: A British documentary about the eccentricities of Californians. Nobody loves and embraces an eccentric quite like the British, and nobody is able to examine the eccentrics of other nations with quite the same combination of smug superiority and restrained amusement.

The documentary in question portrayed a number of activities popular in California during the 1980s: Self-trepanning (cutting a hole in one's skull, mostly to see what would happen), crystal therapy, psychic counseling, and (my favorite) channeling. It was channeling that most caught my attention: Earnest individuals who claimed that, during what Edgar Allen Poe called "moments of exquisite tranquillity," their minds were controlled by spirits. For those brief moments, they became representatives of the spirits, speaking in their voices and generally behaving like them. My decision to move to California was partly solidified by seeing one such person seated in a room filled with bemused Californians who had paid $295 for the privilege, channeling a deceased dolphin. As the possessed channeler squeaked, clicked, whistled, and hissed, I concluded that any state that would put up with this would definitely tolerate my relatively mild peculiarities. And any state where people would pay $295 to watch this would probably afford me a decent living.

The people with holes in their skulls, those with fingers callused from rubbing too many crystals, those who no longer feel the spirit of the dolphin and the ones who've put away their crystal balls survive (mostly) into the 1990s as HR managers and 900-number psychic friends. But the concept of channeling remains interesting to me and, with a little luck, to you.

Be is a small company, with growing, but modest, sales. Most of our customers are developers, and most of them interact directly with us. However, as our application base grows, so will the number of people using a BeBox or the BeOS to do something other than develop programs. Some of those people will want to buy directly from our web site, while others will prefer to deal with someone more local, more relevant to their application, or simply someone more familiar. It's important to everyone at Be to stay close to our customers, because it makes good business sense and because, well, we like customers! So our strategy is to create channels that can represent both Be's spirit, and Be's products.

During the next few weeks, I'll be exploring our channel strategy. As always, I'm very interested in your comments and feedback. In our channel strategy, we're aiming for simplicity, just as with the rest of what we do. So you won't see a whole lot of discussion of staircase discounts, minimum commitments, coop funds, bill backs, and other channel arcana.

The earliest, and perhaps the simplest, channel for Be products is Value Added Resellers (VARs). Already, some of our developers, with products nearing completion, wish to sell a packaged solution to their customers. That package includes some combination of BeBoxes, the BeOS, custom hardware, and custom software. This is the simplest and "purest" channel in that the customer is really buying the solution, and not just a BeBox or just the BeOS. The customer may not even know or care that Be technology is present; do you really care if your car's trip computer is managed by a Motorola or Intel CPU? The VAR is responsible for first-line customer support, with Be providing warranty and software support to the VAR as required. In return for providing volume sales, a single ordering point, and first- line support, the VAR is able to buy Be hardware and software at a discount. Conflict between VARs is minimal, as each has its own unique value to add and the customer is choosing on the basis of solution quality, not hardware pricing. Our VAR program is ready to roll, so if you're a Be developer wanting to package a solution for your customers, rather than simply selling software and letting customers assemble the solution themselves, please drop me a line.

In future articles, we'll explore other channels, none of which, sadly, are as simple as the VAR channel, but which offer the dual promises of choice and flexibility.

One of our early shareholders passed away. Seymour Cray. Two weeks ago, on a highway North of Colorado Springs, a driver made a risky passing move. Seymour's Jeep was broadsided and rolled over. Seymour suffered massive head, neck, and chest injuries and died last Saturday in the early morning hours. He was 71.

I met Seymour for the first time in December 1985 in Eau Claire, Wisconsin. As Apple was purchasing a Cray X-MP for its R&D organization, we came to visit the Cray Research production line and meet the great man. Later, in 1989, Seymour invited me to serve on the board of directors of his new company, Cray Computer Corporation, located in Colorado Springs. There, I witnessed him challenge the laws of physics -- and capital formation—until the company folded in 1995.

When I left Apple and started Be, Seymour kindly expressed interest in helping us. So one day in September 1991, Steve Sakoman and I flew to Colorado Springs and gave a presentation of our project to Seymour and Neil Davenport, the company's CEO. Seymour stood still during the process and asked very few questions—I was terrified and wondered if I had said something unspeakably stupid. We rode to dinner in Seymour's Jeep, he never locked it and left the keys in the ashtray, an amazing habit for someone born and raised in Paris. On the way to the restaurant, Seymour jokingly complained to Neil that he was losing money on his gold investments. I suggested a stake in Be might be a way to compensate for that. He smiled: "Why not?" Finally, at the dinner table, I had to ask if he meant what he'd said in the Jeep. Yes. How much? One million. Seymour never wasted words.

A month later we had dinner at my house in Palo Alto and a misfolded carpet caused a plateful of osso bucco to take flight and hit the dining room wall. As we nonetheless got Seymour's check the following day, the dish became known in the Gasse family as the million dollar osso bucco.

Seymour's career is too well documented for me to add much to the public record. His name became synonymous with supercomputers, and we're sure to see many articles, books and web sites celebrating his achievements. One of us, Dominic Giampaolo, suggests the following two URLs: http://www.usa.net/gazette and http://innovate.si.edu/history/cray/craytoc.htm.

The media made much of Seymour's alleged or real eccentricities. "Time" magazine yesterday made derogatory comments about a habit Seymour had for a part of his life: Building a boat during winter, sailing it during summer, and burning it when autumn came. I had asked him about this. He just wanted to move on to the next design, unencumbered by the past. Something he did all his life when he started Control Data, then left and started Cray Research, going to a repro shop to print stock certificates and selling shares from the Control Data parking lot.

My last meeting with him was in June of this year. He was quite philosophical about the demise of his last venture and ready to start a new one. At the time, he was considering a deal for Intel's ailing supercomputer business, for the customer list he said. In any event, he had ideas for the large memory systems required by supercomputers and "having been hit over the head enough by microprocessors" intended to use them in his next design. I'm sad to see Seymour die prematurely, in the midst of planning yet another start-up, SRC, but he led a good life and I'm grateful for his generous help and for the memories of a hero of our industry.

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.