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.
NetPositive and 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:
http://www.company.com/myscript.cgi?First=Ron&Last=Theis
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.
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 applications...like 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...
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
http://www.be.com/developers/sample_code/index.html
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:
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.
Gets some headphones and plug them in, too. You don't *have* to listen through headphones, but it helps.
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.
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 onaStream
.EnableDevice
(B_SPEAKER_OUT
,true
); // Turn the internal speaker offaStream
.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:
http://www.adamation.com/
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:
ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/synthesis/rsynth
and another great source of speech stuff:
http://www.speech.cs.cmu.edu/comp.speech
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.
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.
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 is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.
To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.
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):
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.”
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.”
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)..."
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.
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.
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.”