Inspecting the include files for Be application development reveals a uniform absence of multiple inheritance. I may be the only proponent of multiple inheritance at Be, but there are surely others in the developer community. This article encourages the use of this key C++ structuring mechanism, while identifying certain dangers which are particular to the Be world.

The sources of dangers which I discuss are threads, dynamic BObjects, and C++ itself. This three-headed Hydra incapacitates unwary programs without warning. I have prepared a code sample, preserved in alcohol, for your inspection.

Be threads, integral to BeOS, provide a powerful programming methodology. Common within operating systems for decades, multiple control-flow is finally emerging for use by application writers. Unfortunately, far greater care is required in this environment, and knowledge of concepts like synchronization is crucial. Furthermore, programs run nondeterministically, hindering the bug search.

Like any C++ object, a BObject encapsulates data. However, some exhibit dynamic behavior beyond the semantics of the language. A BWindow, for example, has effects on the screen, the operating system, and the state of the team. One notable effect is the asynchronous appearance of a new thread. BWindows also make a habit of deleting themselves.

Consider the skillful blending of the C language with a pit of vipers: the result could be likened to C++. Given the resulting performance, portability and industry support, C++ is a reasonable choice by Be. However, this presumes the application writer can develop immunity to the venom. The lack of garbage collection and the matter of object construction and destruction are an enduring pain.

Described superficially, multiple inheritance moves member objects into the list of base classes. In the following example, a BLocker and a BControl comprise a new class. Class X uses membership, but is unable to invoke the BControl (BControl::Invoke is a protected function). Class Y uses multiple inheritance, successfully. The code for Y is better structured, better protected, and looks cleaner.

struct X {
  X( ): c( BRect( ), 0, 0, 0, 0, 0) {
    l.Lock( );
    c.Invoke( );    // illegal!
  }
  BControl c;
  BLocker l;
};

struct Y: BLocker, BControl {
  Y( ): BControl( BRect( ), 0, 0, 0, 0, 0) {
    Lock( );
    Invoke( );
  }
};

Even if X were legal, the interaction of X with BControl and BLocker would be a mess. Pointers to all objects would have to be exchanged, and declarations of friendship thrown around like confetti. In C++, friend destroys the distinction between protected and private. With friend like this, who needs enemy?

The real dividends of multiple inheritance come from data sharing within a subset of a larger object. This is achieved with "virtual base classes". The complexity of BObjects, and their derivatives, makes such structuring highly desirable.

Two classes can cooperate with a virtual class, which contains shared data and linkage to functions for each other's use. The degree of sharing is determined mutually and the name spaces do not otherwise collide, as would happen if a hierarchy were imposed (one class derived from the other). Also, a hierarchy permits sharing in one direction only.

The other way to arrange sharing between "sibling" objects is through an object which is derived from both classes. This approach is inferior because shared data in the object will migrate toward the root, again causing name trouble. Function linkage will be clumsy since pure virtual functions cannot be employed from that direction.

As promised, here is our preserved code specimen, depicting the best in code structure, but also foolhardy regard for the Hydra. The code is necessarily small for this article, but runs nicely. Finding the same bugs in a large-scale program is no cakewalk, as you can imagine.

#include      <Application.h>
#include      <Window.h>
#include      <stdio.h>

class V {
  V( ): z( 1000) { }
  protected:
  virtual void fm( BPoint) {
    printf( "Oops!  V::fm called\n");
  }
  uint  z;
};

class W: BWindow, virtual V {
  W( BRect r): BWindow( r, 0, B_TITLED_WINDOW, 0) {
    printf( "W::W called (thread=%d)\n", find_thread( 0));
    Show( );
    snooze( 10000000);
    u = 42;
    printf( "W::W done (thread=%d)\n", find_thread( 0));
  }
  void FrameMoved( BPoint p) {
    printf( "W::FrameMoved: thread=%d, u=%d, z=%d\n",
    find_thread( 0), u, z);
    fm( p);
  }
  uint u;
};

class H: BHandler, virtual V {
  H( ) { }
  void fm( BPoint p) {
    printf( "H::fm: z=%d, p=", z); p.PrintToStream( );

};

struct S: W, H {
  S( ): W( BRect( 20, 20, 90, 90)) { }
  ~S( ) {
    be_app->Quit( );
  }
};

struct A: BApplication {
  A( ): BApplication( 'xyzt') { }
  private:
  void ReadyToRun( ) {
    new S;
  }
  bool QuitRequested( ) {
    return (FALSE);
  }
};
main( )
{
  A a;
  a.Run( );
  return (0);
}

V represents the shared portion of a BWindow W and a BHandler H. W and H are bonded by the aggregate object S, which plays no role, except for startup and shutdown. Ideally, V::fm is pure; for our demo, it prints a warning.

On startup, the program immediately creates a window which you can move. For the next 10 seconds, moving the window illuminates three bugs.

Firstly, W::FrameMoved is being called, but the W constructor (W::W) has not completed. There are two separate threads running in W, without any provision for interlocks. Even with interlocks, this scenario would make little sense.

Secondly, W is being used before fully constructed. This is often acceptable, but the utmost care is required. The obvious case is the constructor itself. The order of object construction is well-defined in C++ (tediously so). In our example, that care is lacking: variable u is being used before set.

Thirdly, the function V::fm is being called before linkage to H::fm has been established. This seems unintuitive, since V has been constructed (observe the value of z). But construction of H::fm has not started, so C++ mandates no linkage. Do you feel faint? Do your limbs feel numb? That's the C++ venom coursing through your veins.

The `snooze' call freezes the program during an embarrassing phase of its initialization, for easy inspection. In a real Be app, this phase might be manifest on certain occasions only: the dreaded timing-sensitive bug.

When developing a Be app, it is critical to understand the dynamic nature of BObjects like BWindows and BViews. Firstly, they must be created with the new operator. Secondly, they delete themselves. Therefore, an aggregate like S must contain no more than one instance of such an object.

In conclusion, the complexity of large applications in the Be environment can be contained by multiple inheritance. The sceptics should note that single inheritance must confront almost all the issues of multiple inheritance, while enjoying far fewer benefits. Therefore, open your copies of the C++ ARM, and start hacking. And beware the Hydra!

Like most of the developers that have written in this column, we at Opalis loved the Be adventure from the first time we heard of it. Having worked on Windows NT, I immediately felt comfortable with the advanced features of the BeOS and decided that we should help and participate as much as possible, especially since there's a lot of French guys involved here...

Our speciality, networking and business systems, may not sound like the ideal Be target, but I'm sure the BeBox, with its high-level capabilities, can make a contribution in a "regular" company—it's not just a video/audio editing machine. (I'm also sure that the Box has a place in the home. That's why we're studying IHS applications, but that's another story...)

The first program we're developing for the BeOS is an implementation of OpalisRobot, our event-driven scheduler. This is a general tool that includes something like an extended cron. A description (and, soon, the first version) is available at www.opalis.com/opr_beos.html. If your application needs to schedule some tasks or to detect special system events, you won't have to rewrite yet-another- scheduler, you'll be able to use OpalisRobot for BeOS, probably for free.

The second project—a personal one—is IPv6 over Ethernet and ATM. I spend all my free time on it, and if all goes well, we should have this in a year. I'll certainly release some parts before, such as ATM drivers. This is a big challenge for me, and also for the BeBox, since some ATM adapters and switches can go very fast. For example, Sun just released a 622 Mb/s adapter (of course, it does not fit on a PCI slot, unless you use a hammer).

Many thanks to the Be team for this exciting box. Please always stay on the wild side...

This Sunday, I was paying my weekly visit to Fry's Electronics in Palo Alto. For those of you unfamiliar with this emporium, it's a cornucopia of items with but one common attribute: They all appeal to geeks, nerds, and technofreaks. Each of the Fry's stores has a theme; the Palo Alto outlet is decorated to resemble a Western saloon, complete with the heads of several farm animals stuck onto the wall. So, gentle reader, please imagine the setting: bright fluorescent lights, doleful cows surveying the scene from their vantage points on the wall, aisle upon aisle of electronics and, it being early on a Sunday, very few people trudging around.

I round a corner, in search of an elusive cable, and bump into a former colleague with whom I worked at a Major Workstation Company. It's nice to see him; we've not seen each other for about three years. We exchange pleasantries and I hand him my Be business card. He raises his eyebrows and asks me what Be does.

"We've created a brand-new operating system and a multiprocessor computer and are marketing it to digital content application developers," say I.

My friend backs away, his face showing a mixture of surprise, apprehension, and pity. He clearly believes that my tray table is not in the fully locked and upright position and, after a few more pleasantries, we separate, each in search of the little pieces of electronics that will satisfy us today.

It was only later that I pondered on this brief encounter. My Fry's friend was not the first person to imply, or even openly state, that what Be is doing is crazy, or at least eccentric. Several posters to comp.sys.be have asked fellow netizens for their arguments in favor of Be, because their friends have told them that we're crazy.

We can argue that a good proof of sanity is demonstrated success. Definitions of success vary, but Be's includes respect for our technology, broad acceptance of the BeOS and low-cost MP computers running the BeOS, satisfied and profitable developers and happy customers doing cool things. We could write this into a florid mission statement, but.....nah!

We've reached a stage of development at which the probabilities of success are leaning in our favor. If we consider the reasons why start-ups fail, some of the most common are lack of funds, uninteresting technology, no clearly-identified target market, overwhelming competition, or a poor team. Right now, through a welcome round of adequate financing (using the "just in time" principle), technology that excites people, a market space that's large enough to be interesting yet small enough to be well-defined, no direct competitor (yet), and the best team of engineers, marketers, and support people that I've had the privilege to work with—things look quite positive.

We can also argue that however much a single company may appear to dominate, there's always at least 20% of the market that's inaccessible to the dominant player. That 20% comprises customers that are looking for something a little different, a little special, or a little more useful for their particularly unusual task. Our target market is that 20%: Unique people with unusual needs.

We could strongly debate using reductio ad absurdum: Does our protagonist believe that the current UNIX/Windows/MacOS trio of dominant operating systems will prevail for ever? Probably not. How about for 50 years? Seems a little too long. 20 years? Still too much. 10 years? Well... So, when WILL an alternative emerge? Could it be now? Could it be the BeOS?

There are other arguments, many of them founded upon the "look at the product and tell me if you see something special and useful" approach.

We could argue forever. Or we could get on with building the products.

Even so, people still think we're crazy.

And that makes it all the more fun.

A few years ago, jaded observers said our industry had entered maturity, we were getting our AARP card in the mail. Without saying it in so many words, they meant that everything new had been invented already, life was going down an incrementally boring path, taking gross margins with it. But this was before (among other things) the phenomenal increase in processor power and, of course, the rise of the Internet from the Unix geek underground, thanks to Tim Berners-Lee's HTML.

As a result, instead of operating systems and processor wars, we now have the war of the two browsers. At stake is nothing less than the control of the huge streams of money about to be carried by Intranets and the Worldwide Web. For businesses, Intranets represent a new level of cost and flexibility in delivering client-server applications.

In many respects, the browser is a New Age incarnation of the Common User Access (CUA), the one client/one user interface to corporate IS resources that was promoted "Web aeons" ago by IBM. Netscape's genius—I should say Jim Clark's genius—has been to see this and go for it as only he, Silicon Valley money, and egos fueled by a strong dose of anti- Microsoft sentiment can. Said sentiment was not lost on its object, but Microsoft is used to it. They know how to harness the hostility and envy of others to their own business goals. More importantly, Microsoft understands that this is about control. Netscape and their allies want to take control of a huge portion of the computing business, one that is indeed Microsoft's next target after winning control of office productivity: enterprise computing.

The operating system is a commodity, said Netscape, the new platform is the browser, a cross-operating system platform at that. A new genre of computing is emerging on that platform, and Netscape is the drummer, not Microsoft.

The response was remarkable and reminds us of why Microsoft is Microsoft. From the Pearl Harbor anniversary speech last Fall, to the recent delivery of version 3.0 of Explorer, the strategy was courageous and insightful—and the execution flawless. This might be viewed as unfortunate by the many who claim Microsoft's dominance is excessive already, but it is a fact, nonetheless.

The latest version of Microsoft's browser looks pretty good to me. I've downloaded both Navigator and Explorer 3.0 versions on my home Windows 95 system and I no longer feel Navigator to be markedly superior to Explorer. In many respects, I like Explorer's user interface a little better and I noted that it had obligingly imported my Navigator bookmarks for me. On the other hand, Explorer isn't available on my Mac or on other platforms yet. This is still a plus for Navigator.

Netscape's reaction is a mix of PR and legal maneuvering, with accusations of illegal conduct strenuously denied by Microsoft in a well-detailed response on their Web site. We'll see. In the meantime, the war of the two browsers continues and it might take a very logical turn in the next few months. Microsoft, on the one hand, wants to disable Netscape's platform story. The solution? Integrate the browser into the platform, instead of making it an application. Make it pervasive—make it disappear. Explorer 4.0 might do just that, with a minuscule RAM footprint (at least compared to the 4 to 5 megabytes currently required); the rest of the code consists of DLLs inside the system.

More importantly, Explorer functions are instantiated as an API, allowing programmers to integrate these functions into their code. The story sounds good. Based on the progress thus far, the implementation ought to be convincing. Netscape had the right idea, and here is our implementation integrated in Windows 97. Netscape, on the other hand, has decided to get into the operating system business with a subsidiary called Navio. Reportedly, Navio will write an OS for televisions, telephones and other communicating appliances. This OS will run a much smaller version of Navigator. So now, Netscape is more or less trying to do what Microsoft failed to execute with Modular Windows and Windows at Work, two interesting stories for connoisseurs. We'll have to see what Microsoft's reply to that one will be. A version of Pegasus, their upcoming PDA OS, for appliances?

In the meantime, we happen to agree with Microsoft: the browser ought to be integrated in the system and presented to application programmers as an API, a class library. After all, several years ago, we didn't call our "user shell" a Finder or a File Manager, we called it a browser.

This is the process we're starting with DR8, available Real Soon Now.