Issue 2-34, August 27, 1997

Be Engineering Insights: NetPositive and URLs

By Ron Theis

So, being a Webmaster, I'm asked several questions all the time about the web, Be, and NetPositive. I thought I'd answer some of them here.


I'd like to learn HTML, but there are so many books to choose from. Can you recommend a book on HTML?


Frankly, I've found that anything by Laura Lemay is excellent. She wrote one of the first really great HTML books a long time ago, and she continues to update and refine several different titles she has. I believe I've used "Teach Yourself HTML in 14 Days" in various revisions over the years, and it's one of the books which never stays on my bookshelf at Be for long—it's constantly being read by me and borrowed by others.


Where do I go to find information about X? What's your favorite search engine?


My favorite search engine is Ask Jeeves, at, hands down. Jeeves takes natural language questions, like "What is the BeOS?", and provides suggestions for other questions you might actually be asking. It's extremely intelligent about figuring out what you're looking for, and it provides results from several other search engines (like Excite and Alta Vista). If you're looking for something on the web, Jeeves can usually find it for you.

NetPositive and URLs


How can I send NetPositive a URL?


NetPositive can actually be run from the command line, meaning it could be given a command in a shell script, like

$ NetPositive

This line would cause NetPositive start up (or open a new window) and take the user to the Be web site.


But I want to send it a URL from within an application—can I do that too?


Sure, just send a BMessage with some argument information filled in. The following does exactly what the command line instruction above does, for instance:

BMessage msg(B_ARGV_RECEIVED);

msg.AddString("argv", "NetPositive");
msg.AddString("argv", "");
msg.AddInt32("argc", 2);

BMessenger messenger("application/x-vnd.Be-NPOS", -1, NULL);

if (messenger.IsValid()) {
  messenger.SendMessage( &msg );
} else {
  be_roster->Launch ("application/x-vnd.Be-NPOS", &msg );

Note that this is merely a stopgap until a more formal NetPositive scripting architecture is defined. We're just pretending to give NetPositive command line instructions here.


What if I want to do FTP transactions too?


NetPositive can also take FTP URLs. So the following would retrieve the list of files recently added to the FTP site:

$ NetPositive

This could also, of course, be sent via a BMessage from within an application. NetPositive reacts as though the user had entered that URL, though, so a file dialog is presented to the user to save the file. The application therefore doesn't know (without searching) where the file was saved on the user's hard drive. The user also needs to know what to do with the file once it's been downloaded.

Intelligent URLs

There are some interesting things an application could do by sending URLs to NetPositive. Many BeOS applications are providing documentation via HTML these days, and access to these documents from within an application could be easily facilitated. Buttons inside an About box or inside a window could jump right to the application's documentation.

Applications which have web sites could even provide "Read Local Documentation" (sending the local URL, in file://path/file.html format) and "Read Latest Documentation" (sending the absolute URL, in http:// format) choices, jumping the user to NetPositive and the application's instructions. Or a "Register Now" button could jump the user to NetPositive and a remote registration page.

This could be carried even further by creative applications which take advantage of the fact that a URL can contain form information. A "GET" form request is one sent inside of the URL, providing variable and value information to the remote script. This kind of URL looks like:

Variable names are matched with values using equal signs and ampersands. Special characters need to be encoded in hex, too; you'll want to reference an HTML book for the grisly details. I've found that testing each character to see if it's alphanumeric, then sprintf-ing it into hexadecimal works pretty well.

The example URL above would send my first and last name to a remote cgi, which could intelligently process the information. The CGI could fill out a form for me and return a web page which prompts me to register or purchase the product. Or maybe I insert my e-mail address into the application's about box, click the "Sign Up for Product Info" button, and the application sends my e-mail address to a CGI through NetPositive. The results page is returned to me in NetPositive, welcoming me to the mailing list.

Or a "Check Version Info" button could send my program version information to a remote CGI that tells me whether my application is up to date or not. The resulting HTML could then link me to appropriate download areas, or provide information on how to upgrade to or purchase the latest version of the app.

Doing It Yourself

An application doesn't have to use NetPositive, though; it could make the network connection itself. The details for doing so can of course be found in the Network Kit chapter of the Be Book. This can get intimidating for non-networking programmers, throwing them into the middle of an sin_addr/sockaddr festival. If you're looking for basic open/read/write/close client functionality, though, it will pay to make friends with a BTSSocket. Check out the Network tutorial in the Developer section of the Be web site for source code and more information on how this is done.

Some basic knowledge of the actual HTTP protocol would be required to pull this off, but with some cleverness, a lot of information could be returned to the application. Scripts could be run remotely, returning information back to the program itself—NetPositive wouldn't need to display an HTML page. A script wouldn't even need to return HTML if the program on the receiving end knew how to deal with the information correctly. It might not be as efficient as creating your own client-server arrangement for handling communications, but it would allow an application to connect to a remote information source and provide a dynamic response to the user.

In fact, one could envision an application which queried a remote database for the latest versions of the applications on the user's hard drive (a primitive version of some of StarCode's Software Valet functionality). Or one which checked every so often to see if there were any new applications released in the user's preferred categories, such as games, productivity, etc. But in order to do that, we'd need a database of available BeOS BeWare. I'll discuss these possibilities in my next Newsletter article. In the meantime, check to make sure your BeWare records are up to date...

Be Engineering Insights: Extensions Disabled

By Doug Fulton

I am, I happily, ecstatically admit, a Macintosh novice. I cut my teeth on various forms of UNIX in the days when a stable, reliable operating system was regarded as far too sophisticated for mom, pop, and their drunken coed daughter at Wellesley. Recently, unfortunately, the tech writing team at Be moved their (our, my) production machinery from an oxygen-deprived form of UNIX (SCO) to Mac system seven-point-something. Do people actually use this thing?

But the OS isn't Apple's only, or even most important, problem. That would be this: Steve Jobs has become boring. Forget the implications of the $150M Microsoft deal—pundittier wits than I have frazzled that one to the bone. What does it mean? Who cares. The important thing isn't the deal itself, it's SJ's sound bite, blazing purple across the cover of Time magazine: "Thank you, Bill. The world's a better place."

Huh? Steve is admitting there's a world? I liked him better when he was archly solipsistic. I worked for him (at NeXT) for seven years; I never really enjoyed the aftermath of being up close in the same room with him —he has a talent for siphoning your soul out through your eyeballs -- but he was fun at a distance. Not more than a year ago, I saw him on a television show (not that I watch TV, of course) in which he spake the Steve gospel on the iniquitors of Redmond (and I paraphrase, but probably not much, it was a memorable spaking): "The thing I don't like about MS is that they have no taste...and I don't mean that in a small way." Perfect.

Perhaps the last few years spent peddling celluloid sugar water has softened his rabbit punch. Granted, many of his myth-making quotables were stolen ("The journey...") or nonsensical ("A dent in the universe"), but they never let flag the "SJ Longa, Vita Brevis" banner that was so disarmingly charming. Even his recent admission that he did indeed dump all his Apple stock was impressive in its up-yours impudence. I wish, at times, that I had that sort of gall (although, honestly, it may not be a fair test: What would YOU do with 1.5 million shares of AAPL?).

So, please, Steve, say something crudely amusing. Make fun of Bill's haircut, impugn his typing skills, insult the intelligence of his Smart House—anything—the more tasteless and irrational, the better. Let us know that you're the only one that exists. The world? Hey—it's just an extension. And extensions are disabled.

...But that's not why I called you all together here tonight.

During the Audio and Video presentation of the BeDC in Boston on a Tuesday in a dark room, I showed a trivial but amusing application called Whisper. Whisper takes voice input and fiddles with the sound in real time—most notably, it lets you shift the pitch of your voice as you speak. Certain employees at Be have already used Whisper to make prank phone calls, including a message in a demonically basso voice left on Jean-Louis' voice mail demanding that the caller (referring to himself in the third person) be given a raise. Whisper is, obviously, a productivity tool.

Since returning from Boston I've received more than one (two!) request that Whisper be availablized. Anyway, if you start at

and poke around a bit (look in the "Sound" section), you'll find a Whisper executable and BeIDE project. The interface is pretty stark, the icon is vanilla, and there's no on-line help, but all of that icing would only obscure a perfectly twisted little cake.

Here's what you do:

  1. Get a microphone and plug it into the back of your computer. It's possible to run music (from a CD, for example) through the program, but it's not very satisfying: Whisper gains real-time by cheating at fidelity (we all know people like that). Music tends to fall apart under these conditions—except for the works of Sting, which, mysteriously, sound much better.

  2. Gets some headphones and plug them in, too. You don't *have* to listen through headphones, but it helps.

  3. Start the app; If you're running on a 66MHz machine, you should immediately switch to 22050 in the SRate window (otherwise it makes an annoying buzz). Faster machines should have no problem running at the default sampling rate (44.1K).

The app presents five "Fiddle" settings: Shift, Flipper, Whisper, Chirpy, and Splatter. These are self-descriptive sound manipulating filters. And there's a slider in the main window that does something, although the relationship between the slider and the something that it's doing isn't always clear.

The sampling rate settings (44.1, 22.05, 11.025K), in addition to having an effect on the performance of the app, also influence the character of the filters—more isn't necessarily better: Splatter, for example, is more fun at 11025 than at 44010. (But aren't we all?)

Fool your landlord tomorrow—download Whisper today! I only put about 15 copies on the Web Site, so when they're all gone, that's it.

News From The Front

By William Adams

One of the most fun things that you can do with a computer is generate interesting sounds. That's why whenever we give a demo we use big loud sound systems and a thumping beat. Of course, the history of sound and computers has come a long way from playing the star spangled banner on a Teletype, to now doing CD quality digitized stereo. Sound handling really is simple to do in the BeOS. If you are familiar with our streaming architecture, you know you get buckets, you add to the buckets, you pass them on. We get much simpler questions though. How do you turn the volume up or down.

If all you're after is the meta information related to sound, take a look in the AudioStream.h file and you'll see some interesting things.

class BDACStream for instance. Let's say you want to set the master volume of the system to be 50% of max.

BDACStream aStream;
aStream.SetVolume(B_MASTER_OUT, 0.5, 0.5);

It's that simple. It's really neat to do while you have the Sound preferences application up because you will see the sliders change accordingly. If you take a look into MediaDefs.h, you'll find some other interesting things that you can set volumes on.

You can also use the same stream thing to enable and disable various devices.

// Turn the internal speaker on
aStream.EnableDevice(B_SPEAKER_OUT, true);

// Turn the internal speaker off
aStream.EnableDevice(B_SPEAKER_OUT, false);

Audio is one of those things that I've never made a point of becoming any sort of expert at, but I love playing with things. When I first started at Be, there was this wacky thing called Audio Elements. Audio Elements allow you to play with sound by giving your a nice graphical user interface in which you can tie things together into networks and just fiddle to your heart's content. If you really want to play with sound, but you don't want to get down into the nitty gritty, you might check it out at:

I've also found that speech synthesis gives me a thrill, and through my various net wanderings I found that one text to speech synthesizer suits me fine:

and another great source of speech stuff:

It suits me because the price is right, free, and the quality is good enough for simple things. It has a tuned database so that you can actually get quite good on those easily mispronounced words. If anyone wants text to speech, I would highly recommend these sources.

Do vampires have brides?

Apparently so, because Scott Paterson was getting married this past week, so I had the opportunity to go to Atlanta to give a demo to the Macintosh User's Group there. If you've never done demo tours, you'd be in for quite a treat. And if you've read the "How to give a BeOS Demo" guidelines, you should take all that it says to heart.

My trip was going to be a lightning strike, leaving San Francisco at 8:20am on Wednesday, returning by 10:25am on Thursday. So what can possibly drive a guy like me to go off to some city far across on the other side of this country for one night just to give a demo? One comment that one of the attendees made was they were grateful Be sent someone who was lively and interesting, not like some of the demos they get. I live for this. Spreading the infectious enthusiasm that I have for the BeOS.

One of the little video clips that we have in our QuickTime movie arsenal is that old 1984 commercial that shows the hordes of people watching big brother on the big screen, and in runs the sledge hammer wielding woman with the fruit company logo on her shirt. I remember at the time the enthusiasm that was sparked by such IN YOUR FACE defiance and thus spurred the creation of what are now fondly known as the Mac Faithful.

The world of computing is not over and done with. That commercial still rings true today, the logos just need to be changed around a little bit. I'm so danged enthusiastic because I see in the BeOS a challenge to established norms of acceptable performance. At Be, we take seriously the notion that today's machines are not being fully utilized by today's operating systems. In everyone's attempt to build bigger better faster, we've largely thrown away the notion that small is beautiful and efficient.

That's why I can fly across the country for a one night stand, and spew forth a smile and a grin as I launch the fourth movie on a machine that is already maxed out, and feel confident that I'll still be able to move the mouse and read my email. And did I say this app is less than 200K?

Unbridled excitement about running multiple movies is one thing, but running actual applications is another. The questions always arise, when will you be able to run such and such, or so and so? Often times I'll answer that by showing BeatWare Writer, or Adamation's Audio Elements, or another fine product by our third party developers. You can't believe how exciting it is to be able to show real commercial apps that focus our performance advantages like a laser beam. And I can point to our BeWare web pages and say, "See here, there are hundreds of apps that are free, shareware, or commercially available." I'm sure the downcasting, give it up crowd will always retort, Yes but it's not ____, to which I will always answer, thank goodness there is still room for improvement and plenty of users intelligent enough to spot a superior product when they see one.

What a rant. I can't help it though. I was in Atlanta for only a day, but the roar of the crowd, the smell of the grease paint, the glare of the lights, brought out the enthusiasm in my heart for the BeOS. Being a part of something as new and exciting has no parallel, other than raising a human child perhaps. I'm glad we're at a phase in our development that we'll soon be sharing this great OS with a greater number of people, and giving a number of third party developers a chance at becoming the next big thing.

Complement, Supplement or Replace?

By Jean-Louis Gassée

We are often asked if we are crazy and we think this is a good question. Not just because we are polite and humble, but because we feel this is a legitimate question, one that allows us to clarify our position on the central issue of our raison d'être—as we say in English.

So, yes, we're crazy, but not that crazy. It would be really insane, stupid, and expensively suicidal to present ourselves on our developers and customers doorsteps, assuming they have been waiting for us since the beginning of time, or Windows, and declare we're here to displace Microsoft. The BeOS is better, younger, faster, smaller, cheaper, easier to program, we're taking over. OS/2, with many good qualities and IBM's name and money, couldn't compete with Windows. How could we succeed where IBM failed? Precisely, as we'll discuss in a moment, we have very different goals. Contrary to what IBM attempted to do with OS/2, we are not trying to displace Windows.

Still, doing something different, against the official thinking of the moment, requires a certain lack of wisdom, the conventional one. Needless to say, we aspire to the latter kind of unbalance. Then, if we're not competing head-on with Microsoft, what are we doing on the Intel platform?

The respective positions are quite simple. Windows 95 and Windows NT are both general-purpose OSes. Windows 95 is hugely successful on the desktop and Windows NT has become a holy terror in the enterprise market. The BeOS, on the other hand, is a nascent OS specializing in digital media content creation. The general-purpose OSes have their advantages: breadth of applications, familiarity, the support of a great company.

Conversely, as a result of their very general nature, they are at a disadvantage in more specialized media applications. In our case, we lack legacy applications but, free from the baggage, we offer superior performance, ease of programming and (almost) friction-free market access, specializing in the emerging digital media applications where our elders are legacy-bound.

We are a complement to, not a replacement for, existing general-purpose OSes. Depending upon their needs and inclinations, users will pick one or the other, or more likely both. They're already doing it today on Intel systems.

From the very beginning, many operating systems have coexisted on Intel-based PCs: Versions of DOS (MS/DOS, IBM PC/DOS, DR/DOS), Windows (3.1, 95, NT), Unix (BSD, SCO, GNU, Solaris), OpenSTEP, various flavors of Linux. As a result, a genre has emerged, the boot loader. Linux, OS/2 and Windows NT all offer one and there are several independent ones, the most popular probably being System Commander. Not for my mother, obviously, I don't see her partitioning her hard disk and installing Linux or even her son's BeOS, but technically proficient users, our natural audience, have been doing it for years.

I dwell on this for two reasons. One is our Mac heritage. Many of us come from Apple; the BeOS is currently available on Power Macs. Contrary to the Intel world, the boot manager genre has no meaning in the Mac space, no need. Second, I believe there is a stark contrast between the high cost of establishing a new genre and the much lower investment required to play into an existing one. Which gets us back to the earlier question of the kind of craziness tormenting us, the lethally expensive one or the merely high risk, high reward one. On Intel systems, we play in the established context of multiple OS on the same hard disk. In that space, there is the general-purpose OS category and the special-purpose space. We play in the latter, we complement rather than replace.

Now, there is the delicate matter of execution. It will decide what kind of craziness really afflicts us.

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: Need input!

Marco Nelissen's solicited comments on his GUI layout tool, and posed some font-management questions (the understanding, here, is that the tool-built app wants to be able to dynamically update fonts when the user changes the preferences):


If the program can specify any font for a control, then what am I supposed to do when the default font changes? That button that is currently set to use "Geek symbol fontset bold italic size 85", should I reset it to the plain font?"


Should a programmer be allowed to make a mess of his GUI by creating, for example, multiple buttons all with a different fonts?

Mr. Nelissen then offered his own inclination...


I'm inclined to make all classes in the library use one of the three default fonts, always, and making them react to those font-changed messages without regard to their current setting. After all, those three fonts are what the user prefers, and the user knows best, right? The most obvious consequence of this would be that it would be pointless to call SetFont()...

Laz Marhenke suggested that the proper principle to follow is... "...the right answer is 'whatever the program would have done if it had been started up with these choices of plain, bold, and fixed fonts"

...and gave an example that rebutted Mr. Nelissen's always-use-default-fonts opinion: " app will have Greek letters sprinkled here and there... I don't want Omega turning into a little box when the user switches font preferences."

Osma Ahvenlampi suggested an extended fonts preferences mechanism: "Could you perhaps let a program provide a list of the fonts it uses in a BMessage ("big title font" = Times/20, "main text font" = Times/14, and so on) that a separate extended font config panel could edit?"

Mr. Nelissen turned the idea around:
"I just had an evil idea: drag&drop of fonts. Instead of (or in addition to) making the library react to changes in default fonts, FontSelector could let you drag a font onto a control to change its font."

The thread then frayed into a separate debate: Should a developer ever use a library that doesn't include source? Most developers accept code-less system libraries (, but prefer that 3rd party libraries include code. Some folks are adamant: They will not use a (non-system) library that doesn't include code. Along the same ethical standards line, a few developers also stepped forward to aver that they do all their GUI design by hand; given the right hands, layout can be done just as quickly by typing in code.

Some other matters (picking on the state of the OS): There should be a B_FONT_TYPE message type; BFont should be archivable; UTF-8 encoding should revert to a default font (death to the little empty squares).

Subject: format old FS disks

Ed Musgrove called in with this question: “I have ... a handful of HD floppies formatted in the old file system. PR recognizes these [but] I cannot for the life of me format the now unneeded DR8 disks.

As Brian Stern and others correctly pointed out... “Use DriveSetup. Unmount the volumes first, then you can format/initialize them.

Subject: How compatible is Sockets API & behaviour

Is Be's socket implementation close enough to the BSD standard to fool a CS professor? A few listeners wrote in to give general approval to Be sockets, but also pointed out some of the short-coming (sockets aren't file descriptors, they aren't inherited across a fork, etc.).

So what about select()? Can it pass for the real thing? Theoretically, yes (say most); but the implementation (one thread per socket in the mask) is inefficient (say some). The select() question opened a wider debate over socket/thread scaleability (we travelled down this road some months back). Should select() be avoided altogether? Says Jon Watte:

Actually, if you want to write efficient BeOS code, not just port a quick UNIX program, you should spawn a thread to serve each socket you're keeping open.

Howard Berkey agrees, but with a caveat:

1 thread per socket has many advantages if you aren't planning on one server instance handling more than a few hundred connections at a time; it's elegant, robust, easy to code, and in general far simpler. It's only when you get to a huge number of threads that it starts to be a problem... This is less of an issue currently under BeOS [where] system limitations in Power Mac hardware preclude I/O at a level where such scaleability issues become troublesome.

Subject: crypt standard

Is a crypt()-encrypted file portable? Answering the question with a question, some folks wondered "why use crypt() (when there are better encryption schemes)?" Answering with an answer, the consensus seems to be "No—not all crypt()'s are the same."

Unsurprisingly, the initial simple question launched discussions of the legality of encryption, the practical applications in which encryption is most needed, encryption implementations, and cracking the code. Osma Ahvenlampi added this amusing, and probably accurate, note: "...the easiest method of cracking the password is to ask the user (in a state in which (s)he would be most likely to answer)..."

Subject: Disabling live resizing

A question from Ficus Kirkpatrick: How do you ignore all but the last of a series of FrameResized() events? “What I am doing is spinning on GetMouse() until the buttons are released... Unfortunately, I get all [the resized events] once the mouse is let up...

Some solutions were offered, none of them perfect. The best, wait for the mouse up and then ignore all but the last resize in the queue, is close, but a few resizes may still trickle in.

Subject: B_PASTE vs BClipboard

Is Be's drag-and-drop messaging less than perfectly clear? Trey Boudreau (and others) think so:

There are now *no fewer* than THREE Be sanctioned methods for Drag'n'Drop of text between applications: B_SIMPLE_DATA, B_MIME_TYPE, and B_PASTE. BMessages and the Drag'n'Drop API combine to make the most flexible system I've seen in a static language. And right now, Be itself is driving it into complete chaos.

Jon Watte amended the complaint somewhat:

B_PASTE is not a sanctioned container of data. B_MIME_DATA and B_SIMPLE_DATA should be folded into one, I agree...

Mr. Boudreau also suggested that there should be more "what" constants so message parsing can be quicker. Mr. Watte countered that B_SIMPLE_DATA includes multiple format representation; forcing data into finer categories inhibits flexibility. But, says, Mr. Boudreau, what if two separate field of the message are important (the example of dragging text and a color chip at the same time was mentioned)? Brian Stern...

I think there will be very few cases where a single drag target will allow more than one action for a given type of data. In most cases the recipient of the drag looks through the message for data that it knows about, and chooses to handle the data however it wants... I'm not against custom drag messages but I still think it's up to the drag recipient to decide what to do with the drag

The solutions to the text/color drag that were offered involved developer intervention: It was conceded that the OS itself can't figure this one out for you.

Subject: BeOS memory protection

Earl Malmrose was wondering:

Outside of the known bugs, how can an app crash BeOS or other apps?

An immediate reaction (independently from two separate BeDevTalk mainstays):

"Why do you ask?"

This coincidence didn't go unnoticed, at least not by James McCartney:

"At 3:52 PM -0700 8/18/97, Howard Berkey wrote:
 >The unknown bugs? :-)
 > [...]
 >Why do you ask?

 At 4:13 PM -0700 8/18/97, Brian Stern wrote:
 >Unknown bugs?
 > [...]
 >Why do you ask?

Aaaahhh...! They've finally cloned humans! I knew it wouldn't be long after the Dolly thing!"

In response to the suspicion, Mr. Malmrose expressed some skepticism of Be's claim for bullet-proof memory protection (he comes from the Mac, so is understandably wary), and, further, says he simply wants to know what to avoid doing.

Dave Haynie gave a thoughtful reply, which started with...

each process (team) has its own MMU context, which does two things. First thing it does is make every program start at a fixed location (usually 0), which makes it possible to easily share code segments, for example. The second thing this does is define, on a per-process/ team basis, the memory that the process/team can and can't access. Since the protection is provided by the MMU hardware, it's very robust, if not absolute.

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