[ Be Logo ] [ Home ][ Site Map ][ Search ][ Contact ][ Developers Banner ]
About Be, Inc.Be ProductsThe World of BeDeveloper ServicesJobs @ Be[Bottom]

Be Developer Services

The Be Book

Free Resources


Partner Program


Partner Area


  The BMessage
Issue 9    September 6, 2000


August 29, 2000
Instant Movies: Exploring The Zeum -- Byte.com

Be Press Releases

August 31, 2000
Envision, Incorporated Develops an Internet Appliance Interface Solution For Be's BeIA

August 30, 2000
Be Incorporated Appoints P.C. Berndt as Chief Financial Officer

return to top


The Need for Speed: BeIA Vs. the Competition
by Brennan Spies, Sr. Market Analyst

The joy of surfing the Internet is much like the joy of driving a car -- great fun if you're cruising around at a nice speed and enjoying the sights, but not much fun at all if you're stuck in traffic and your car can only go 10 mph. With this in mind, I would like to compare the experience of using a BeIA-based Internet appliance versus some of the other shipping Internet appliances currently on the market from a purely speed-based perspective. This is not intended to be a "pure" OS/Browser comparison, since obviously the hardware and Internet service providers are different in each case, but rather a comparison of these devices from an end-user perspective to see which delivers the fastest browsing experience -- i.e., a "real world" comparison.

For this task I've selected a Compaq "Clipper" device running BeIA and tested it against the Merinta iBrow, the New Internet Computer, and the ePods One using Ziff Davis' iBench set of browser benchmarking utilities (available here). Some of the specifications for these devices are listed below:







Code-name "Clipper"


Wagner (Opera)

AMD K6-2, 266 MHz



Linux with Java VM

Espial’s Escape (Java-based)

Nat Semi Geode, 200 MHz


ePods One

Win CE 2.12

Internet Explorer

MIPS R4000, 129 MHz

NIC Company



Netscape 4.7

Cyrix Media GX, 266 MHz

iBench tests the performance of an Internet client by downloading multiple pages (re-loading for cached pages) completely, scrolling down a few pixels, then going to the next page, and so on in a looping fashion. Cached pages are a good indication of how fast a client is regardless of connection or server speed.

I've graphed the results below for both the original downloaded pages and for subsequent page downloads (cached pages). "Complex" pages here refer to Web pages that contain numerous elements, such as cascading style sheets (CSS). "Text-based" pages are as they sound, mostly text with some other simple elements added.

Complex Chart

Text Chart

The BeIA-based "Clipper" beats the competition on first-iteration downloads and looks even better with cached pages. Despite variations in the hardware used, the BeIA advantage comes in no small part from quickness and agility of the operating system itself as well as the tight integration between the OS and the browser provided by Opera Software.

return to top


Connected Appliances: A Field Report
by Jean-Louis Gassée, CEO and Chairman

The term "connected appliances" covers too much ground to have any precise meaning. And shortly it will be a pleonastic repetition, as all appliances become IP-enabled. Meanwhile, curious to see the current state of connected appliance art, I bought a Casio PocketPC and a Blackberry pager, and activated the WAP features on my GTE cell phone.

First, the PocketPC. Full disclosure: since Palm's spin-off from 3Com, I no longer hold a vested interest in Palm. With that out of the way I can say that the PocketPC (E115 from Casio) initially looks good; it has a nice color screen and decent battery life (a few hours of continuous use). However, it's way too complicated to set up and synchronize -- too much like a PC shoehorned into a PDA.

Part of the problem lies in the name, PocketPC. In theory, you can play a music file on it while reading and answering mail. In practice, the music hiccups when the CPU is too busy and the OS too tasked to give good service to the music application. The OS (good old CE re-baptized) is not as stable as expected -- I had to reset the machine several times. I'll spare readers the convoluted story of transferring data from my Palm VII to the PocketPC, but I have this advice: ignore Microsoft's PocketPC Web site and buy IntelliSync -- it works. Unfortunately, you have no choice about using Outlook (no relationship to Outlook Express), another MS roach motel, the nimble mail client "integrated" with Explorer. Also, the PocketPC has no wireless connection, it's more expensive and more difficult to use than a Palm VII, and has less ISV support. My advice is to wait and see what the next generation will do.

WAP phones have been much touted and, lately, somewhat maligned. Perhaps it's a question of expectations. For me, the set-up was reasonably easy and the phone does what I expect -- handles a limited amount of e-mail and Web browsing. It's simple, small, and, in my experience, fairly reliable. Getting stock quotes, sending and receiving POP3 e-mail, or searching for books on Amazon.com might seem too geeky for some. I have no dispute with that perspective -- WAP phones are about as advanced as DOS or the Apple ][. They're functional but too primitive for many. Others may want to look at today's products and services and extrapolate. I find today's WAP convenient and very promising. I take my hat off to Alain Rossman for ignoring the sages who told him Unwired Planet (the name of the company before it became phone.com) had no future -- a browser in a phone, you *must* be kidding. Yes, there's a Ken Olsen born every minute.

Still on connections, I got a Ricochet modem for my notebook. It's a very nice, always on wireless connection. It's still slow where I live, but already available at 128Kbps in Seattle and San Diego. I can't wait for the fast service and the PC card version. At twice the speed of ISDN on a small notebook it will open the door to on-demand multimedia on the go.

Last but not least, the Blackberry. This comes in the Exchange version for users of MS Exchange server and the Internet edition for users of ordinary e-mail. See Blackberry.net for details, prices, and distributors. I bought mine from OneMain, and it was a very pleasant experience. I just set up a duplicate of my e-mail stream to a onemain.com address and was in business without wires immediately. The PC desktop software synchs to Outlook for your address book and calendar. The screen is a little smaller than the Palm's but the battery lasted me more than 10 days. The keyboard is small, but friends say it encourages me to be concise. Most functions are accessible with one hand via a scroll-and--click wheel and a small escape button.

The Blackberry is small, thin, and light -- the best wireless PDA I've seen so far. However, it has no Web browser and no wireless synchronization with my assistant's desktop yet. If and when these functions are available and work well, Blackberry could give Palm, Handspring, and Sony (their Clié Pam clone is coming this month -- what's with these cute acute accents?) a run for their money. Blackberry surprised me, because I'd had a bad experience with an earlier generation of two-way paging, but this one works nicely. Perhaps I should do Transcendental Meditation waiting in line for United Airlines, but one-handed wireless e-mail, bourgeois as it is, is a good way to relieve frustrations.

return to top

Engineering Insights

So You Have a Bunch of Resources -- Now What Do You Do?
by Dianne Hackborn<hackbod@be.com>, SW Engineer / Framework

A few months ago I wrote about QuickRes, our new tool for viewing and editing program resources of all types. If you haven't used it yet, the current version (updated since that last Newsletter article) can be found at:

x86: ftp://ftp.be.com/pub/bebits/development/tool_kits/QuickRes-x86.zip
PPC: ftp://ftp.be.com/pub/bebits/development/tool_kits/QuickRes-ppc.zip

The question I've seen asked most often about resources is how to use them in an application, and in particular how to use a bitmap stored in a resource to create a BBitmap that can be drawn into a view. Conveniently, the Translation Kit includes two functions that make this easy to accomplish:

        BBitmap* myBitmap = BTranslationUtils::GetBitmap('type', "name");
        BBitmap* myBitmap = BTranslationUtils::GetBitmap('type', id);
While they are very convenient, there are some issues and limitations related to these functions that you should be aware of:
  • They use the Translation Kit to create the bitmap. Currently, this means that all translator add-ons will be loaded into your application the first time you call GetBitmap(). For a small program this can impose a noticeable startup penalty.
  • Every call to GetBitmap() generates a new bitmap. Not only does this include the overhead for creating the BBitmap object itself, but also for running the raw resource data through a translator.
  • You can only use these to retrieve your application's resources. Add-ons cannot (easily) retrieve bitmaps from their own resources.
Another Way

BResourceSet is a class I wrote to address the limitations of GetBitmap(). This class is a wrapper around one or more BResources objects, providing a similar API along with additional methods for directly retrieving BBitmap, BCursor, and BMessage objects from the resource data.

You can find the source code here: ftp://ftp.be.com/pub/samples/storage_kit/BResourceSet.zip. Also included is a sample application, LoadResources, that demonstrates using the class within an add-on to display an icon.

Using BResourceSet is very simple, requiring three steps:

1. Create a single BResourceSet instance that will provide access to all your image's resources.

2. Call the AddResources() methods one or more times to point this instance at the resource data it will load.

3. Use FindBitmap(), FindCursor(), and FindMessage() to retrieve data from your resources.

The BResourceSet class keeps a cache of all resource data it has found. For example, the first time you request a bitmap, it will load the bitmap data from its resources, create and store the BBitmap object, and return a pointer to you. Every time thereafter it will immediately find the existing BBitmap object and return the same one to you, without further effort. All objects are returned as const pointers -- BResourceSet will free the data for you when it is deleted, so you shouldn't delete the objects yourself.


There are three pieces to the BResourceSet API: telling it where to look for resources, loading resources, and generating objects from resources. The first two are public; the last is protected, to be used by subclasses to extend the data formats that can be handled.

You tell BResourceSet where to find its resource by calling the AddResources() methods. This method has two flavors: the first is given an actual BResources object, which BResourceSet then takes ownership of and manages. The second provides an address of some code in your program, and creates a new BResources object for the image at that location. This second form is particularly useful for add-ons, as it can be complicated to track back to where your add-on lives on disk (and thus create a BResources object on the file).

Two additional functions are available, AddDirectory() and AddEnvDirectory(). These tell the BResourceSet to also look in the given directories when resource data is requested by name.

The core method for finding resource data is FindResource(). This works identically to the BResources implementation, returning the raw resource data found. In addition, you can use the FindBitmap(), FindCursor(), and FindMessage() to return objects of these types created from that raw resource data. The BResourceSet class manages all this data, so you should never free it yourself, nor use it after deleting the BResourceSet instance that it came from.

Finally, subclasses can implement the functions GenerateBitmap(), GenerateCursor(), and GenerateMessage() to create an object of the respective type from raw resource data. The default implementation of these is typically all you need.

In the case of bitmaps, BResourceSet has built-in code for instantiating bitmaps from archived messages and PNG data streams. This means that you normally won't need to link against the Translation Kit, though you will need to link with the static libraries libpng.a and libz.a for the PNG decoding code. Linking with these libraries will bloat your code a fair amount; if this is a concern you could modify BResourceSet only to natively handle archived bitmaps. If you'd like to be able to read bitmaps of any type, you can override GenerateBitmap() to go through the Translation Kit.

(One warning about using PNG images with QuickRes: the PNG Translator in R5 has a number of frustrating quirks when used with QuickRes, particularly in bitmaps with an alpha channel. The next release of BeOS will fix these problems.)

An Example

To show BResourceSet in action, I've included a modified version of the old "LoadAddon" example. To build it, compile both of the projects (the application first, then the add-on in the Effects directory) or in the Terminal use the command "make -f makefile.all".

The interesting part here is in the add-on, where we use BResourceSet to load a bitmap image for its button. To get the BResourceSet up and running, we have:

        static int32 gResourcesCreated = 0;
        static BResourceSet gResources;

        BResourceSet& Resources()
                // Return the BResourceSet object for this image,
                // if needed.
                if ((gResourcesCreated&2) != 0) {
                        // Quick return if already initialized.
                        return gResources;
                } else if (atomic_or(&gResourcesCreated;, 1) == 0) {
                        // Not yet initialized -- do so.
                        // Mark that we are done.
                        atomic_or(&gResourcesCreated;, 2);
                } else {
                        // Wait for resources to be initialized.
                        while ((gResourcesCreated&2) == 0) snooze(50000);
                return gResources;
This function simply returns the BResourceSet instance for the add-on image, initializing it if that has not been done yet. Notice how it passes in an address of your application's image -- the gResourcesCreated variable, which is in the image's data section. The use of atomic_or() makes the function thread-safe (the BResourceSet object itself is already thread-safe), and the class is instantiated as a global so that it will be destroyed automatically when the add-on is unloaded.

Retrieving our bitmap from the add-on's resources is now just a matter of

   const BBitmap* bm = Resources().FindBitmap(B_PNG_FORMAT, "BeOS Logo");
This can be used for whatever nefarious purpose we wish. In this case, it's placed into a little BBitmapButton convenience class that displays it.

I hope this class gets you on your way to using resources throughout your BeOS applications. Dig in to the class and enhance it if you want to -- it's very easy to add your own datatypes to the API -- or find other uses for it. I'm told that it makes simple user interface skinning very easy to implement...

return to top

Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission.

The BMessage
Copyright (c) 2001 by Be, Inc.
All rights reserved.

Be, Inc.
800 El Camino Real, Suite 400
Menlo Park, CA 94025
Tel: (650) 462-4100
Fax: (650) 462-4129
Web: http://www.be.com/

Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved.

The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.


About | Product | World of Be | Support | Developers | Jobs | Press | Investors
Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!