One of the questions we get a lot here at Be is, "Why PEF?" And to be perfectly honest, it's a good question. After all, there's a time for innovation and a time for slavish compliance to existing standards, and it's important to know the difference. It's true for Be, and I think it's even true for Apple.

PEF is Apple's proprietary executable file format for the PowerPC Macintoshes. Think about that: A proprietary executable file format. It's even hard for me to type. Just plain weird. Don't make sense. An executable file format is just no place to be different. But this is Apple we're talking about.

So what's so great about PEF? Well, that's not clear to me either. To be fair, it is a nice, modern executable file format with support for demand paging of code, shared libraries and dynamic loading and linking. Just like ELF and XCOFF. It differs from these in really only one regard: There's a nice feature that allows for the compression of non-zero pre-initialized data. In ELF and XCOFF, if you have zero initialized data (known as .BSS to us old timers), its location and length is marked and you don't carry a bunch of zeros around in your executable. Sometimes, however, you have repetitive (read "compressible") pre-initialized data. For example, if the following appeared as global data in your application, the linker could take advantage of PEF's handy compression feature and reduce the size of your executable:

int very_important_table[300000] = { 12345 };

Now, saving around 1,200,000 bytes for this fascinating construct is pretty cool, but is it worth total incompatibility with all the other programming tools in the world? And is it patentable?

I bring this up because Apple believes there's something very special about this stuff. Whether it's patentable, patented, or just an important trade secret is unclear, even after conversations with Apple's lawyers. We at Be wrote our PEF loader in the kernel by using publicly available documents, but nonetheless it appears we need to pay Apple a license fee for the right to open and interpret PEF files. Oh well.

We can puzzle over Apple's wisdom in this or any other regard, but life is short. We can move on to another vexing question, "Why does Be bother with PEF?" The reason we're using PEF is because of Metrowerks. We love their tools—they're the best available for the Power PC—and we wanted our early developers to be able to use CodeWarrior on the Mac as a cross-development platform while the young BeBox was becoming more stable. The only executable format supported by CodeWarrior is PEF, so we complied.

In recent months, we've been asked by a number of developers if we could support a more standard format, such as ELF. Our response has been positive, but vague. Positive because we'd prefer the more standard route, but vague because sharing one object library (libbe.so, currently a PEF behemoth) between both PEF and ELF applications is tricky. Convincing Metrowerks to support ELF at all has also been a little more difficult than we thought it would be. Nonetheless, we strive to an even more standard future.

In 1991 I got fired—even though I was putting in 12-plus hour days -- because I wasn't willing to show up for work at 10:00 am each morning (1:00 pm works much better for me). So I figured the time was right to return to the contract programming business I'd started three years earlier: Green Dragon Creations.

At Green Dragon we write games for companies coast to coast. One of our first big contracts was "Spectre Supreme"; our next two products (for the Macintosh) are "MechWarrior 2" and "Under a Killing Moon."

Writing games is the best job in the world. It lets me combine two of the things I love most: Programming and playing games. Writing games is a sort of game in and of itself—balancing object-oriented programming with efficient code.

We'll work on any platform except DOS/Windoze/Win95. We'll work on Macintosh, Sega Saturn, Sony Playstation, and we're looking forward to developing for the Be platform! Every platform needs games, right?

I look for a few key things when choosing a platform. On the high end (for example, on the BeBox or Macintosh), I look for good tools and a good OS/Toolbox to use as a foundation for what I want to write. On the low end (for example, on the Sega Saturn), I look for a cool set of chips and just enough sample code to write my own OS for the system. I love to get down to the bare metal and build an efficient object-oriented system from the ground up.

I especially like the Be OS™. I look at the basic docs and how the OS is put together and it looks like a clean, efficient system. I want to build games on top of it. It's the first system since the Macintosh where the mouse actually works correctly.

To start out with, we'd like to port our own code (a 3D sprite engine) to the Be platform. We'd also like to convince our clients to let us port some of the games we've ported to the Macintosh over to the BeBox. Stay tuned!

Last week I referred to Bill Walsh. As a result, I got a good ration of ribbing: “How can a Frenchman raised on soccer even begin to appreciate the subtle nuances of American Football?” As a matter of fact, I endured an overdose of soccer in Roman Catholic boarding school, and I'm watching the calendar for Labor Day when I can compare Jimmy Johnson's hairdo to Mike Ditka's.

But I won't invoke past or present coaches in vain anymore. So, we'll skip Vince Lombardi and focus this week on our definition of winning. How do we know—when will we know that we've won? Is it the day of the sacrosanct IPO? Is it when we win our first lawsuit against Bill Lerach, when we ship the first 100,000 machines, or reach 100 million dollars in revenues? Or is it when we see Be Geeks on a magazine cover, read accolades in "Upside," and watch Erich Ringewald, tanned and tattooed, in a sunset fade on his sailboat?

There's a difficulty and fragility in any definition of winning. Remember "Business Week's" 1984 cover, "And the Winner is IBM"? The joke gets cosmically better when we realize IBM never made a buck in the PC business. At the time, Apple was perceived to be the loser, after years of winning with the Apple II, and before years of winning with the Macintosh. Ashton-Tate won for a while, so did Software Publishing, but —unlike Apple with the Mac—they failed to make a transition and never recovered.

Then there's Microsoft. They never seem to have lost. Sure, they were the unintentional fool in the database court for a while, but the laughter stopped when they acquired FoxPro (for a fraction of the price Borland paid for Ashton-Tate), and blew life into their second database product, Access.

The moral seems to be about winning seasons rather than scores in particular games. And yet, some teams with winning seasons get their names spelled with four L's. So let's pick a definition of winning and see if it fits.

First, there is the win for developers: For Be to win, our developers must win. We have a unique opportunity to help fresh starts in the application business, just as we are a fresh start in the platform business. I'll make the risque statement that it's more important for us to find the next Adobe than to convince Adobe that Be is their next platform (this said with great respect for Adobe technical prowess and aesthetic elegance). Yes, it would be great to run a Be-specific version of Photoshop—and it would be even greater to find the next John Warnock or the next Kai Krause. We would add more to the industry and we'd probably get more as well.

Perception will add to the win: Being seen as a platform on which new stars are born will attract more talent. As we win with and for developers, we'll win with customers. We give them features and price/performance unavailable elsewhere, they help us reach financial independence, thus the very perception of success begets success.

Our shareholders (including Be employees) are next in line. If the company is financially sound, there will be people wanting to buy shares. Winning, in this sense, is making our professional investors liquid, and helping Be employees along the road to freedom of mortgage.

We also want to win by impressing our severest critics: Ourselves. If you'll allow the momentary immodesty, we're driven by qualitative and aesthetic gauges. We do what we do because we hold to a high standard when we measure the quality of personal computing, applications, and the building of good businesses. To win in this arena means creating a product that feels right, through the combination of the ingenuity of its design, the integrity of its proportions, the quality of its execution, and the hone sty of its distribution.

This may sound a bit too trite for your taste; but I can offer the names of companies that won in some—but not all—of the constituencies listed above. They didn't last. That consideration drives us also. The Amiga was/is a great computer, but Commodore didn't last.

Yes, we are naive enough to think we can win, and we're experienced enough to know that the future will surprise us no less than the past 5-1/2 years have.

BeDevTalk is an e-mail discussion group where Be developers and other interested parties voice their opinions, commendations, and frustrations about the state of the BeBox and the Be OS. In this column, we summarize the most attended and contentious of the recent BeDevTalk threads and supply, where applicable, the "official" Be opinion or clarification.

Threads are listed by the subject lines as they appear (literally, typos and all) in the mail. (To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/about_be/mailinglists.html.)