With the next release of the BeOS almost out of the door, here are some tips on things to do to take advantage of Preview Release 2's (PR2) features.

First of all, there aren't a lot of major changes, since the goal was to be for Preview Release (PR) apps to stay compatible and for PR2 apps to be backwards compatible, and to focus on stability. There are still a fair number of tweaks we made, though, that refine the BeOS considerably. Here is how you can take advantage of some of them:

BPath path;

if (find_directory(B_BEOS_SYSTEM_DIRECTORY, &path)
    == B_NO_ERROR) {
  path.Append("Tracker");
  BFile tracker(path.Path(), O_RDONLY);

  if (tracker.InitCheck() == B_NO_ERROR) {
    BAppFileInfo info(&tracker);

    if (info.InitCheck() == B_NO_ERROR) {
      version_info version;

      if (info.GetVersionInfo(&version, B_APP_VERSION_KIND)
          == B_NO_ERROR)
        printf("the tracker short version is %s\n",
                version.short_info)
    }
  }
}

void
AboutScrollView::MessageReceived(BMessage *message)
{
  if (message->WasDropped()) {
    rgb_color *color;
    long size;

    if (message->FindData("RGBColor", 'RGBC', &color,
        &size) == B_NO_ERROR) {
      int32 modifs = modifiers();

      if (modifs & B_OPTION_KEY)
        textView->SetFontAndColor(0,
          textView->TextLength(), 0, 0, color);
      else
        textView->SetViewColor(*color);

      textView->Invalidate();
      return;
    }
  }
  inherited::MessageReceived(message);
}

alias t='/system/Tracker'

When you were a youngin, did you ever ask your parents to borrow the car? Of course you did. And compared to your bike or skateboard it was a lot faster and much more of an attractor of the opposite sex. You giddily drive down the street with your arm perched on the window looking as cool as can be. Then, reality sets in, you have to return it, and since you dinged it, you're grounded and won't get to drive it again...ever.

Well...have you ever installed a new OS on your machine and found that it was quite a joy to drive, and that all the apps ran that much faster. It's quite the geek magnet. You sit back confidently clicking away on your apps with a smug wry smile on your face, then you wake up and you realize that you fell asleep using the BeOS and you're overjoyed because the reality was every bit as good as the dream. OK, maybe I've been programming this stuff a little bit too long, but every time I lay fingers to keys, I'm excited. And with our upcoming release, I'm even more excited because the system just gets more solid and feature rich all the time.

One thing that I've enjoyed all my life is learning new things. As my wife can tell you, I have books by the dozens, and my head is a sponge, maybe a bit leaky at times, but I like to absorb new things nonetheless.

I was reading Eric Berdahl's latest Betelgeuse library and I noticed a couple of new things. Two C++ keywords that I had never seen before: "mutable" and "explicit".

What the heck are these? So I went out and bought the latest and greatest Bjarne Stroustrup book: "The C++ Programming Language—Third Edition" and I looked them up.

First "mutable". If you tend to do things like this:

class myobj {
public:
  doit() const;
  int myint;
};

myobj::doit() {
  ((myobj *)this)->myint = 3;
}

This is known as casting away const. Why would you do it? Because the doit() method is declared const, which means that there is a contract with the user that says this method will not modify the state of the object. But as the implementer, you simply must change the value of myint. Well, if you do this:

class myobj {
public:
  doit() const;
  mutable int myint;
};

Then you can safely change the myint variable without having to cast away const and without a compiler error. This seems to be safer than the cast away const trick, which is compiler implementation dependent and breaks the const contract completely.

The other thing I learned was the use of the "explicit" constructor

class myobj {
public:
  explicit  myobj(const myobj &);
};

How many times is your object's copy constructor used behind your back? Would you like that to not happen? Well, when you use the explicit keyword, your constructor can only be called explicitly and not behind your back. This is a good thing to keep straight in cases where an implied use of a constructor may be a bad thing:

class string {
public:
  string(int nElements);
  string(char *initial);
};

string aString = 'a';

This will essentially amount to creating a string object with storage for 65 characters. This probably is not what you want, but the single character was converted to a int, and the constructor that takes an int was implicitly used.

Using the explicit keyword on the constructor will prevent this implied usage and force you to implement what you mean instead.

class string {
public:
  explicit string(int nElements);
  string(char initialChar);
  string(char *initialString);
};

All in all, this just goes to show you that an old dog can learn new tricks. C++, and most other languages, gives you plenty of rope to hang yourself with. But there are plenty of things in the language the make practicing safe HEX relatively easy.

Some columns generate more e-mail than others, our honorable correspondents react in ways that are sure to keep us honest or, at least, awake.

The column on modularity, http://www.be.com/aboutbe/benewsletter/Issue89.html#Gassee, did excite a little more reaction than usual, with responses ranging from the very supportive, "Go for it, you're doing the right thing, NCs are the future!", to the scathingly critical, "You're pandering to the NC PC (if one can forgive the pun), NCs are a fraud, who wants them and, in any case, how are you going to compete against Oracle, Sun and IBM and make money?" And now we hear Apple, too, is poised to enter the NC fray.

Let's back up a little bit. Said column on modularity vs. scalability merely draws attention to the fact that our operating system is unusually modular. Most systems only "scale" upwards, they bleed to death when a cut is attempted in order to downscale them; ours scales up nicely when adding processors, and it responds nicely to the system programmer's knife when targeting smaller platforms. We have demonstrated the BeOS running on 4-processor machines; now we fit a slimmed-down version on a 1.44 MB floppy, boot from said floppy and browse the Net with a $350 Pentium clone sans hard disk.

We're trying to make the point that the BeOS is unusually modular and, as result, can be used in a wider range of applications than just as a specialized desktop operating system targeted at creative digital media applications. And, in making that point we indeed invite some controversy regarding our role in the NC space as well as the future of NCs themselves.

Let's start with the latter point. Is the NC a viable life form? If I must answer in one word or less: Yes. If I'm allowed a little more space: It depends—for what, for where, for whom.

I was born in a statist culture that, in the early eighties, naturally engendered the Minitel, a home and business information terminal the monopoly telephone company gave away in return for forfeiting carbon-based phone books. The Minitel microprocessor runs a communications protocol and an interpreter for a page description language. Move to the late nineties, make the communications protocol TCP/IP and the page description language HTML, add the BASIC of our times, Java, and you can roam the Internet or deploy client-server applications on your company's intranet.

Do these capabilities make the NC a life form? Not yet. To become viable it needs to cost less than a Windows PC and, in some ways, do more. The purchase price is still unclear. In theory, NCs, with less components, should cost less, but PC advocates point to the economies of scale and the competitive forces relentlessly driving their prices down.

But the main argument for NCs isn't the purchase price, it is the cost of ownership. Anyone owning or operating a PC knows how much time is "invested" in dealing with configurations, updates and other technical endeavors. NCs promise to do away with these expenses, and reduce the acquisition and maintenance cost of system and application software as well.

We'll see. In the mean time, we have to guess and the divining is made harder by the commingling of technical and geopolitical arguments. In other words, is the NC a good idea because it's a good idea, or because it is anti-Microsoft?

Guessing along, I personally believe the NC will gain traction in two incarnations, as a New Age intelligent terminal, fulfilling the age-old IBM dream of CUA, Common User Access, and as a home information appliance. In the latter respect, WebTV and its growing roster of competitors attest to the desire for PC-less Web browsing. Some will argue these are not NCs, I respect that position. I realize I use "NC" loosely and, in my opinion, so will the marketplace.

Does all this mean we have any role to play in the NC world? We don't know yet. And, in any case, not by ourselves, not in the way we're playing the desktop digital Media OS game. In the desktop market, we don't need to worry about the platform; hardware vendors kindly take care of that. Mostly, we need to worry about applications. In the nascent NC space, "applications" come with the languages the NC interprets, HTML and Java, but the hardware platforms are still coalescing and are likely to be very different from one another.

Put another way, hardware and system software will be tied more closely together than they are in the PC space. If we do anything in that space, it will be as a supplier to information and entertainment (infotainment?) appliance manufacturers. In that space, the good news for Be is the insatiable demand for digital media. For text-based applications, more mature embedded systems are very adequate. Conversely, the more these appliances respond to market demands by deploying enriched multi-media content, the better the modern media capabilities built in the BeOS come into play.

This is highly speculative as we are still in the very early days of these new appliances and of their fight against PCs. In any event, we have no need to take sides as we no longer make hardware.

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.