Issue 2-38, September 24, 1997

Be Engineering Insights: Getting Your Applications Ready For Preview Release 2 and Other Topics

By Pavel Cisler

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:


Versions were made available through the BAppFileInfo API, and the FileTypes application lets you set versions for an application. However that was pretty much it; even our own applications did not have any versions set in the last two releases.

This is changing. In PR2 everything, including apps, preferences, system components, etc. has a version. You can now find out, for instance, what version of the Tracker you are running:

BPath path;

if (find_directory(B_BEOS_SYSTEM_DIRECTORY, &path)
    == B_NO_ERROR) {
  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",

Under the original Preview Release, version will return no version info. Under PR2, version will return "PR2".

The long version string is now displayed in the Get Info panel in the Tracker—make sure your app has its version set. You can do that using FileTypes—you can either set it on your final application or you can set it in the .rsrc file that is appended to your binary during the make.

In addition, when you receive PR2, there is a new version of the setversion tool that you can use if you are doing makefile builds and want to be able to set the version from a makefile. The new setversion tool needs to be run after any copyres, addres, mergeres (insert your favorite resource- copying tool here), because it sets the version in the resource and if run before copyres, it might get overwritten.

You can have one or two version structures in your application. The main version structure is accessed using the B_APP_VERSION_KIND selector, the secondary using the B_SYSTEM_VERSION_KIND. You do not necessarily need the system version kind; in fact, currently FileTypes doesn't even let you edit it (the new setversion does).

Its purpose is to hold version information about a whole revision of a number of components, where the B_APP_VERSION_KIND contains version information about the one specific component. You can have, for example, SoundCrafter release 2.1 that contains a new add-on Distortion 1.0. The application version of Distortion would be 1.0, while the system version would be 2.1, because it's a part of SoundCrafter 2.1. Yes, we copied the Mac's vers resources.

Tracker Add-Ons

There are quite a few Tracker add-ons out there, my favorite being TermHire. In PR2, Tracker add-ons can have keyboard shortcuts. The way you assign a keyboard shortcut is by appending the letter to the add-on name, for instance "FileTypes-F".

The modifier key combination for add-ons was changed to Command+Option (on Mac keyboards), since using only the Command key was a little limiting, since add-ons would have to share the space with all the other pre-existing Tracker shortcuts.

If you have an add-on, make sure you ship it to users with a meaningful shortcut already predefined. No programming involved here, just edit the name appropriately. This of course is convenient for users because they can edit shortcuts any way they want.

If you have an installer for your add-on or ship it with installation instructions, here is another PR2 tweak—the /home/config/add-ons/Tracker folder is now active. You should place, or have the user place, your Tracker add-on there.

The /system/add-ons/Tracker is reserved for Be add-ons. When the Tracker looks for add-ons, it does a uniqueness check to deal with the case where a user has an add-on with the same name in both the /system/add-ons/Tracker and in /home/config/add-ons/Tracker. In the case of a conflict, only the system (i.e., from Be) one gets loaded.

Finally, don't forget Tracker add-ons can have an icon, and that icon will show up in the Tracker's add-on menu.

Supporting Color Drag & Drop

On an unrelated topic, here is a tip about how to support a neat way of setting colors in your app. I really like roDesign's roColour color picker. The drag & drop message format is pretty flexible, and it took just a few lines of code to make the Desktop handle color changes by supporting part of the message format.

In the new release you will find a new about box feeding the egos of all the folks here at Be that worked on the release, mentioning the names of their favorite pets, etc. The text view that displays all these rantings can be recolored via a drag & drop from roColour, and here is the code that supports it:

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->TextLength(), 0, 0, color);


As you can see, it's pretty straightforward. If you are writing a color picker or any other user interface element that can initiate a drag of a color, make sure you put RGB color data in the above format into your drag message. If your application contains user interface elements that can be recolored, adding this drop handler is one of the easiest ways to do it.

By now you probably figured out that I'm desperately trying to figure out what to write about in this article. I think the following can get me over the length minimum, so I can go back to hacking on the Tracker.

Interacting between a Terminal window and the Tracker

I already mentioned my favorite add-on, Term-Hire. It lets you open a new Tracker window and have it cd to the same directory as the Tracker window from which you activated the add-on. As described above, now you can use a keyboard shortcut to do it, which makes it even more useful.

The PR2 Tracker has a feature which is the opposite of what Term-Hire does—it lets you open a Tracker window from the Terminal. If you type /system/Tracker /boot/home in Terminal, a window with your home directory will open up, etc.

If you like this feature, you might want to add an alias to your .profile file:

alias t='/system/Tracker'

which will let you use the much shorter "t" for the "/system/Tracker" part of the command. Note that passing a document name or an application name to the Tracker this way is identical to double-clicking on the file, so you can also launch apps, with or without documents, all from the command line.

News From The Front

By William Adams

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

More (Or Less) on Modularity

By Jean-Louis Gassée

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,, 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 Summary

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:


Subject: Alpha port

AKA: BeOS for Alpha ?
AKA: C++ and the FBC issue

Would a BeOS port to DEC's Alpha chip be possible and prudent? In a grass roots campaign, a number of developers showed interest in contributing to a communal port, while others think it would be a wasted effort. As Jos van Roosmalen pointed out:

BeOS is a many consumers will have a Dec Alpha? ... The server market is going down—exotic processors are not required anymore...

So should the BeOS avoid "non-consumer"? No, says Stuart Mackinnon...

...should BeOS limit itself to just consumer-level machines? BeOS is supposed to be the Media OS. ... Media content workers need as much power as they can get. Many of the post-production houses that use [high-end multimedia software] don't bother with Intel machines -- they're too slow. They use Alphas... I do realise this is a very specific case I have outlined here, but this is part of the market that I would have thought a Media OS would be partly aimed at.

Back in the technology corral, developers discussed the technical requirements for an Alpha port (64-bit addresses in particular). Would this be an opportunity for Be to break binary compatibility? What compiler would one use? And is the Alpha really as fast as everyone says? Steve B. says...

I have been looking into getting an Alpha and the numbers I've seen show for integer operations the Alpha isn't much faster than PPro II of similar speed. Where the Alpha runs away is in floating point operations. Trouble is most code is integer based.

Christopher Tate was unbowed:

First off, there *are* no PPros of similar speed; the fastest they run is about 300 MHz. Second, the assertion that 'most code is integer based' is rapidly becoming less true.

Other first-hand testimonials vouch for Alpha's white-hot speed.

Back to the business of porting: If binary compatibility must be broken to migrate to 64-bit, should the FBC solution be revisited? And whose "fault" is the FBC problem anyway: The OS? The compiler? The language? The FBC dilemma spawned a healthy, if Alpha-unrelated, sub-thread.

So, is an Alpha port a good idea or not? Dave Haynie had this to say:

Perhaps the most interesting thing about the notion of BeOS on Alpha is just the fact that NT seems to be rapidly becoming the choice OS for video work over Windows in the mainstream, and Alpha machines are clearly the high-end in NT systems. If Be's going for the content market, they could do worse than show up on hardware compatible with what's really kicking, and still emerging, in that market.

Subject: Determining screen resolution

The initial question and answer about retrieving screen size and resolution led to a discussion of the proper use of stack-based and temporary objects. For example, the Be Book states (in the BScreen docs, for example) that temporaries are scoped to the enclosing brackets.

Not so, says Brian Stern: Temporaries are scoped to their call. Using a temporary BScreen to get the screen's frame that initializes a BRect introduces a subtle race condition (between the get and the init).

Moreover, some of the Be classes don't implement copy constructors properly. Jon Watte:

The correct fix is for all programmers to either write assignment and copy operators/constructors, OR to declare them as private without implementing them so you can't accidentally use them.

Subject: Interface considerations

An on-going discussion of how and where to store resources. Is it better to store app resources in the executable itself, or as separate files? Many developer like the former approach because it's more compact and makes transporting an app much easier. However, as Osma Ahvenlampi pointed out...

A separate file is always easier to upgrade... I don't understand this "clutter" argument at all. In most environments where resources need to be shared somehow, the tendency is to move from one file to directories with many small files. Maintaining them is much easier that way.

So, asks Thorsten Seitz, how about having executable ("runnable") folders a la NextStep? The best of both worlds: You double-click the folder, and the enclosed app is launched; you drag the folder and the app and all its resources are copied.

The "correct" response to drag & drop data was also discussed. An app should be able to interpret dropped data according to its own needs, but how does the app tell the user what its behaviour will be? Jon Watte puts the shoe on the other foot—and app *shouldn't* behave arbitrarily, no matter how appropriate for its own needs:

This is EXACTLY what the user interface guidelines are supposed to tell us. A developer can dream up an arbitrary number of possible actions in response to a user gesture. However, if all apps did the same things in response to the same user gestures, it would make the overall system much more usable, NO MATTER which particular interpretation is standardized upon.

Subject: GUI suggestions

The single button it a retarded subspecies that should be ignored, or a tradition that should be respected? Many developers strike a middle ground. Ian Russell Ollmann:

...let us assume that we will not allow the one-buttoners to hold up the platform and direct our concern towards how we can still allow these hardware cripples to participate in advances in the desktop metaphor. The one button solution will not be as elegant as the two button case probably, but it would be nice to find one just the same.

Mr. Ollman suggests the following mouse->action correspondence:

Contextual pop-up menus could correspond to the right mouse button. Direct manipulation (pressing a button, dragging a file, highlighting text, etc.) might always take the left button. Secondary actions done to the same object (rotate in space rather than move, select text from the current cursor position to the point of click rather than just move the cursor, make a link rather than copy in the tracker, etc.) might use either both mouse buttons for the two button case or the middle button for the three button case.

Subject: Musings (ramblings?) of a tired NA

A certain Kuraiken has been using NT as a server, and is not displeased with the interface, the ease of transition from other systems, and its reliability. What does this have to do with the BeOS? Our Kuraiken sees similar qualities, yet heightened, in Be:

Okay, now we have the BeOS. Brand spanking new—so new that it's not even version 1 yet. Unbelievably simple to use, simple to program for and powerful while still managing to stay lightweight. So, what is it, exactly, about the BeOS that's 'preventing' it from being a powerful server OS? Is there some technical issue that I'm not aware of? It's got good SMP support, native TCP/IP, solid journaling file system, able to handle monster hard-disks...apart from the lack of server components (I would love to be proven wrong) I don't really understand why it's not being given a chance to...serve.

Many of our listeners offered their opinions: The BeOS *is* an ideal server OS...the Media OS tag is simply a red herring. The BeOS *will be* a server OS, but it's using the Media tag to get started. The BeOS *isn't* a server OS because it's not multi-user. Jon Watte wrote in to dispel the must-be-multiuser myth:

The server has to support whatever authentication and user characteristics that the protocol being served requires. However, the server OS itself does not need to have native multi-user capabilities. You can write an FTP server with its own user/password list file, and it'd look like a multi- user FTP server to anyone on the network.

Subject: Networking Latency

AKA: Network flakiness...

Is networking under the BeOS (particularly connecting) slower than on, say, a Mac? Brandon Itkowitz finds this to be so, and wonders what the problem is. Other folks have found connecting to be quite zippy and suggest that the slowdown is probably due to name server lookup troubles. Larry Daniel pointed out that the network server may not reconnect as efficiently as possible if a first attempt fails.

If you're interested in such matters, you may want to visit the "BeOS Networking Concerns" Web page at

Subject: Intel development system question

Planning ahead: What's the best Intel platform to buy in anticipation of the BeOS Intel release? Not many answers to this direct question, but a lot of Intel stabbing and (begrudged) defense.

Intel's FPU is slow and memory intensive; granted it isn't as fast as PPC, but it *isn't* memory intensive. MMX is "marketing silicon"; the pipelining in MMX is great for (as an example) image processing. But you can't use MMX and FPU at the same time (no defense here). Dave Haynie offered an amusing, backhanded explanation of MMX's existence. He began...

What you have to do is realize where MMX comes from, and how Intel works. The bottom line at Intel is, really, that the CPU always needs more work to do. If they can't keep finding new problems to put the CPU on, they can't keep this crazy growth schedule, or some joker will get a genuinely useful co-processor chip in enough PCs to create some kind of a standard. So the goal, as always, is to do more...

...and rolled along thusly until the fires died down and we all went to back to our tents.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.