Be Newsletter

Issue 81, July 9, 1997

Table of Contents

BE EVENTS: Be Developers Conference in Boston, Massachusetts
MACWORLD Expo in Boston, Massachusetts

  • Monday and Tuesday, August 4-5, 1997
    Be Developers Conference
    Hynes Convention Center
    Boston, Massachusetts

    The Be Developer Conference is the ideal forum to get up to speed on development for the Be Operating System, to find out the latest on Be technologies, and to meet and discuss technology and products with other Be developers and marketeers.

    The conference is open to all software developers; this includes people who are Registered Be Developers and those who aren't yet. An understanding of C++ is highly recommended; the conference will get quite technical at times.

    For more information, please see: http://www.be.com/developers/aug_dev_conf/index.html

    To register, please complete the registration form at: http://www.be.com/developers/aug_dev_conf/registration.html

  • August 6-8, 1997
    MACWORLD Expo/Boston
    World Trade Center
    Boston, Massachusetts
    Be Booth # 5119

BE ENGINEERING INSIGHTS: Onward and Upward with DR9

By Erich Ringewald

Well, it's been eleven long months in the making, but the Preview Release has finally been set free from the developmental cocoon. What started out as a simple release whose only major goal was to replace the portions of our system responsible for data storage turned into the most major release we've ever done. And only five months late.

I know it's only software, and software is always late, but at Be we've always been pretty timely with our software releases. And that's been something to be proud of when you consider the amount of Apple OS team engineering blood, admittedly diluted with infusions of SGI and NeXT plasma, coursing through our veins.

But the uncertainty of a brand new file system, complete with all the modern features, and the even-better integration of our famous database technology left us five months late on what was to be about a five month development cycle. Being off by 100% is impressive, but if I have to do it I'd rather it be on a five month project than a four year one.

But enough talk about Apple.

What's next, after the Preview Release? This is the traditional time to fix up some of those nasty little bugs which were elusive enough to escape detection prior to CD duplication. Why they show up as the FedEx truck is driving away I don't know, but there it is.

But it's DR10 that is really the focus of our attention these days. What should we implement, what should we skip? What will be the most important things we can do to improve the availability, stability, and usability of the applications our developers are writing? More kits? More classes? Fewer kits? More supported platforms? A PowerBook portable, or an Intel desktop port? Both? Neither?

Believe me, the real list here at Be is quite daunting. The pressure for the next release is now on, and we confront that list daily, brows furrowed in deep contemplation. But with continued guidance from our keen developers' insights, I'm sure that DR10 will be right on target. Let's hope it's also right on time.

It's the Customer, Stupid!

By Bradley Taylor

Or, in other words, it's NOT the technology.

To prove my point, all I need to do is point to DOS, circa 1982, which many people, myself included, sneered at as being technically uninteresting compared to the alternatives at the time such as Unix. I remember the general wisdom then was that the superior Unix would eventually replace DOS. Even Microsoft seemed to believe this, and for a time, developed its Unix successor to DOS called Xenix (later abandoned).

Well, here we are today and Unix (with the exception of Linux) is gasping for breath as it is beaten down by the likes of Windows NT, DOS's grandchild. Yes, Virginia, there is still a DOS prompt in Windows NT and it still has all the same primitive commands it did in 1982. Oops, I caught myself sneering again!

So, something was terribly wrong with the analysis that many engineers made of DOS in 1982. What was it? Some will say that the engineers didn't consider the importance of the computer having the letters "IBM" on it. I think there is some truth to that, but it doesn't explain the whole story. Because soon thereafter, IBM lost its monopoly, yet consumers continued to buy DOS, and continue to buy Windows today.

My opinion (and I fully expect to be flamed for saying this) is that consumers care little for technical wizardry, and care deeply about things like price and simplicity. And compared to DOS, Unix was (and still is) an expensive and complicated beast.

The one exception, Linux, thrives only because it is free. The Macintosh, though more expensive, was indeed simpler than a PC, and had a few years of bounty because of it. But had the Mac been the same price as a PC, it would be faring much better today. Apparently, the only technical wizardry consumers cared for at the time was the ability to launch a single application, and they really didn't feel like shelling out a lot of money for any other features, however appealing those features may be to engineers.

Today, consumers are a bit more savvy, and want more out of an operating system than just a glorified program loader. Multitasking, GUIs and Internet capabilities are all expected now. But these features are not just checkbox items; people are really going to use them! So, they need to be there without sacrificing simplicity. Windows, Mac OS and, I have to admit, BeOS are all too complicated in this area. However, I think of the three, BeOS comes closest to meeting the goal, because unlike the others, it was designed to do all of them from the very start.

One of the examples of this is our file typing scheme in the BeOS, which is based on MIME types, the Internet standard. We don't have to convert downloaded files into some outdated proprietary file typing format as Mac OS and Windows do. Because of this, Internet applications such as web serving, web browsing and e-mail are simpler for the user to operate under the BeOS. With just a little more work on our part, like making network setup easier (PPP and LAN), we can make the BeOS the simplest OS by far.

That brings me to price. PowerPC machines are still more expensive than equivalently configured PCs, but clone makers like Power Computing have been doing a great job of narrowing the difference. CHRP machines should erode the gap even further. And a BeOS port to Intel would help to erase the difference entirely. This is NOT an official product announcement, just something to keep in mind, remembering that the BeOS is a very portable operating system. But things are looking promising for PowerPC prices coming down too.

Left out of this discussion has been applications. BeOS could use a few, I'll admit. But remember that DOS didn't have any applications when it started out either, but because of its price and simplicity (compared to the alternatives at the time, such as CP/M and Unix), it attracted many. The point is simply that perhaps if an operating system does what the consumer wants, and offers it with simplicity and a low price, the applications will follow. There are things Be or others can do to grease the wheels, like provide a Mac or Windows emulator. But it may not be necessary. After all, DOS couldn't run CP/M programs, nor could the Mac run DOS programs.

My main goal in this article is simply to motivate you to write applications for BeOS by seeing the market potential for it, which could be huge. I'm not claiming that the BeOS will overtake Windows anytime soon, but it is quite possible that it will carve out a nice niche for itself as a simple and inexpensive application platform. An application running on the BeOS, such as a web server, may be simpler and lower cost, in total, than the same application running on another platform. This is a great benefit to the consumer.

A secondary goal of this article is to deflect some criticism we get from engineers because we are missing certain features that they feel are important. If we put in every feature in that engineers want, we would end up with an operating system like Solaris: complicated and expensive.

There is a lot of value in keeping things simple. I'm not saying we don't welcome criticism; we certainly do. What I am saying is that we, developers and Be alike, will all benefit by keeping the BeOS simple and inexpensive, and criticism must be weighed against these two all-important goals.

We are about to release the "BeOS Preview Release." This is the first release which promises binary compatibility. That means the API and ABI we will be shipping will remain in the BeOS for many releases to come, allowing applications written for the BeOS Preview Release to run in future releases. We will add more API in the future, but the current API will not change. I think our API is very nice, but there will always be engineers who may sneer at our current API (or almost any API, for that matter). Sneer they may at their own risk. Remember, DOS's much sneered-at API (API, what API?) was not a serious impediment to its success.

For the sake of provoking thought, I have simplified things in this article a bit. Yes, things are actually more complicated than I describe. But we should never forget the customer's desires, however basic they may seem to us. I am reminded of a poster my boss has in his office. On the poster, you see a somewhat tall and fit man, with his arm around a stouter, cigar-smoking man. The tall man states something like this, "This is a customer. He has money to spend. I like him."

News from the Front

By William Adams

And finally... 

#include <Application.h>
#include <Path.h>
#include <Entry.h>

static void
HomeDirectory(BPath &path)
{
  app_info info;
  be_app->GetAppInfo(&info);
    BEntry appentry;
  appentry.SetTo(&info.ref);
    appentry.GetPath(&path);
  path.GetParent(&path);
}

BEntry is a wonderful thing. It gives you a C++ representation of an entry_ref. BPath is also a wonderful thing. A BPath will easily represent your BEntry and allow you to perform some very useful operations. In this particular case, we can use the BPath object to get the parent of the application file. In this case the parent is the directory in which the application is actually living, meaning the HomeDirectory. Passing in a BPath object is better than a char * with a length simply because memory allocation is taken care of for you with less potential for mistake. Among the other interesting things you can do with a BPath are Flatten and Append. Flattening allows you to store a path in a archive. Append() allows you to add onto a path. This is often the case when you're looking for files that are located relative to your launch directory. 

BPath path;
HomeDirectory(path);
path.Append("goodies");

Now you can use the path to create a BDirectory object to find files, or whatnot.

Another question that seems to be coming up a lot is, "How can I set type and creator for my files?" Well, in the new MIME world, you don't use type/creator like in DR8. Instead you will set a MIME type on a file. 

BFile file;
file.SetTo(aPath.Path(), O_RDWR);

BNodeInfo node(&file);
node.SetType("text/plain");

The BNodeInfo object is your connection to getting and setting various pieces of meta data on a node. BFiles are nodes, and so are BDirectories. Among the interesting things you can get/set on a BNode are the MIME type, its icon, and the preferred application. This is particularly handy if your application is one that generates files and you want your application to be the one that launches those freshly created files. So, BNodeInfo is the place to go for all your meta data needs.

There you have it. The new file system is not only 64-bit clean, snappy, and robust, but it's darned useful to boot and pretty darned easy to harness those added features. The attributes are there, and largely hidden. This NodeInfo class makes some of the more commonly used attributes more readily available to your application.

A couple of weeks ago my BeBox had what I thought was a sure melt down. I did figure out that the disk drive was touching the power regulator on the motherboard. This is about the hottest piece of metal you can touch on your motherboard. The disk drive actually came out OK. The outer plastic casing was fried, but not to the point of causing any real damage. I turned it on, and I've been happily using it ever since. Although now it make some strange rattling sounds, so I think it's time to retire it anyway.

The 4th of July has come and gone. On that day, I stood at attention in front of the American flag and smartly saluted in recognition of the freedoms that I enjoy...to program the BeOS in the face of tyranny of the desktop and against all odds of the oppressors. I didn't actually stand in front of the flag, but I did think about it.

The Rebirth of the Set-Top Box

By Jean-Louis Gassée

About 1992, every hardware company was either doing a set-top box, or claiming to be designing one. Apparently, these efforts didn't go anywhere. With hindsight, the reason is obvious: Too much computing power for too little money. The tasks expected from a new generation "digital" box required more computing power than a mid-range PC could offer at the time: Decompressing video, creating some kind of user-interface for navigating the service, security services and, in extreme cases, a loop back to the server for "interactive" applications. Even with some absorption of the cost by one or more participants in the food chain, the financial burden was too much.

I used the word "apparently" above. In one of the reassuring mysteries of our industry, one of these episodes that remind us of the difference between PowerPoint and reality, that set-top box false start gave us Java, nee Oak, a programming language originally designed for safely distributing small executables over cable and satellite networks.

Now, with the impending but still undefined arrival of digital TV, the set-top box is coming back. Even with three or four cycles of Moore's Law, broadcasters and cable operators are still complaining about the cost of the device. One friend of mine argues this is the reason why Microsoft is making investments in cable (COMSAT) and is rumored to be eyeing, forgive the pun, CBS. In other words, if links in the food chain are too tentative, Microsoft will buy them and make sure the whole chain is completed, ensuring the availability of an infrastructure "sorely" missing today. Such an infrastructure is needed to develop really juicy commerce and entertainment applications.

I don't know, yet, whether my friend is fantasizing or merely prophesizing, but it's an interesting speculation. Bill Gates' impatience with the clumsy, slow development of a better infrastructure is no speculation; it is part of the public record. If Microsoft used its considerable resources, financial and otherwise, to such an end, I believe the benefits to all of us would outweigh the danger of Microsoft dominating yet another industry. Please don't call me a Microsoft apologist, I'd just like to see new markets we've been hoping for finally arrive.

Now, it's not that easy. Microsoft's fiat, powerful as it is, isn't a guarantee of success. Many successful companies, from IBM to Sony, from Matsushita to AT&T, from Xerox to Digital Equipment, have seen their famed expertise vanish as they ventured into unfamiliar territories. Microsoft has shown a remarkable ability to change its mind and refocus itself, ask Netscape and CompuServe. But their ventures into the content space with MSN and MSNBC are, at this time, less than convincing. Interesting times ahead, as always.

BeDevTalk Summary

BeDevTalk is an unmoderated discussion group that's a forum for the exchange of technical information, suggestions, questions, mythology, and suspicions. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the group.

To subscribe to BeDevTalk, visit the mailing list page on our Web site: http://www.be.com/aboutbe/mailinglists.html.

  • ----NEW---------------------------
    Subject: [Hey Be!] B_SAFE_WRITE please?

    What's the best way to do a "safe save" (in which you're guaranteed to have a copy of a given file at all times, even if the machine crashes while you're writing the file)? Suggestions were offered, as were objections to the particulars, such as where you should safe-save a file, when you should sync, and so on.

    Some folks would like to safe-save as part of the file system itself. It would be appreciated if the file system (or BFile) were to ensure that certain files always existed -- perhaps by writing new data to a temp file and then moving the file to the "real" location. Others think that deciding when, where, and how to save can *only* be decided by an application. The file system could guess, but at the cost of either performance or integrity.

    Speaking of synching -- the Storage Kit doesn't provide a Sync() function, nor can you convert a Kit object (BEntry or BNode) into a file descriptor that you can pass to fsync(). This lack was lamented.

  • ----NEW---------------------------
    Subject: Modality

    Should panels (open file, save file, print, etc.) ever be modal?

    It was argued that in a multi-threaded OS, modality isn't necessary, and can be obnoxious.

  • ----NEW---------------------------
    Subject: C++ question and handling errors

    Is it possible to delete "this" inside a constructor? Most folks agree: Don't delete "this"; instead, either set a status variable (that must then be checked by the caller), or throw an exception.

    More elegantly, if your object needs to be initialized to be used, and if the init can fail, put the init code in some other function. In other words, you should never write a constructor that can fail.

  • ----NEW---------------------------
    Subject: Persistent driver data

    Should a device driver be allowed to launch an application (to ask the user for settings, etc.). The BeOS says no. Some folks think this is too restrictive -- they feel that a driver should be allowed to initialize itself; relying on a server is clunky and possibly unsafe (since there's no guarantee that the server will load before the driver.)

  • ----NEW---------------------------
    Subject: Dumb sound question

    Is it possible to (easily) play a sound from a buffer rather than from a file? Not as easily as play_sound(), but creating an audio subscriber and implementing its stream function is fairly easy, as a few folks pointed out. Still, it would be appreciated if the Media Kit were to accept pointers to sound data (and a pointer to a header), and simply do the right thing.

    Also, what's the best way to mix your data into the sound output stream? Simple addition could cause overflow. But how often will peaks collide? Some folks think that if you mix disparate signals (from different apps, for example) the natural disparity will average to in-range values. So you may not need to "divide by the number of subscribers". However, you *do* have to clip overflow (to the max/min value) -- overflow otherwise wraps around, causing painful and embarrassing digital distortion.


Copyright ©1997 Be, Inc. Be is a registered trademark, and BeOS, BeBox, BeWare, GeekPort, the Be logo and the BeOS logo are trademarks of Be, Inc. All other trademarks mentioned are the property of their respective owners. Comments about this site? Please write us at webmaster@be.com.