Issue 1-54, December 18, 1996

Editorial Note

The Be Newsletter will take a well-deserved holiday on the next two Wednesdays: December 25 and January 1. Look for a new edition of the newsletter in the new year: January 8, 1997!

Be Engineering Insights: FCC Wonderland

By Guillaume Desmarets

Each profession has a set of criteria by which you can sort good work from, well... other work. Take software: Most programmers are able to write a piece of code that will compile (I can do this). Others can track down the tiniest bug and fix it (I'm borderline, here). And the gods can get it right the first time while keeping their code clean, small, and fast (forget it).

Hardware also has its benchmarks. Designing something that can be manufactured, that won't set your house on fire, and that's cheap is the hardware Parnassus. Unlike software, however, some of the hardware criteria are not just advisable—they're legally enforced: If you plan to sell your product to end users, you first have to get a gold star from the FCC.

FCC regulations establish physical limits within which your hardware is supposed to run. Just think about it: What if such rules were applied to software? What if you programmers had a government agency checking the quality and compactness of your code? Imagine sitting before a Federal Software Agency review board to explain why you're polling so much. Or who want you to translate your comments into an actual human language. Or who want you to... (Well, maybe I should stop this little fantasy right here. Just remember: Seg fault and you go to jail.)

Of course, out-of-date comments and lazy error-checking aren't going to reprogram your VCR or scramble your neighbor's cell-phone call.

One of the most important FCC regulations limits the amount of electromagnetic noise your computer can produce. All active electronic equipment produces such noise: Signals propagate through your board, which acts as an antenna. Some frequency bands—the lowest ones—are pretty easy to control because they need a big antenna to radiate any significant amount of energy. But high frequencies are pernicious; they sneak through any available electrical path, spill out any gap in a chassis, and spread all over the place. And unfortunately for the hardware engineer, computer components aren't getting any slower; as CPU clocks and bus rates get faster, the task of eliminating excess noise gets tougher.

There are different ways to bring a product within FCC guidelines once you have a prototype to play with, but nothing replaces good intuition in the design stage. After you've drawn a (hopefully) noise-free schematic, you can simulate your hardware in software. Unfortunately, good simulation tools are expensive and require a lot of time to learn and use.

At some point, you have to put your pencil down and send your schematic to a fabrication shop (or build it yourself). This, obviously, can be the most expensive step, and not one you want to have to re-do. When you get your toy back, it's time for the real test: You have to "scan" your product for noise.

The process of scanning is quite simple. You reproduce a potential working environment by plugging devices into each of the I/O ports of the system you're testing. The BeBox™ has 24 connectors, plus the graphic card, plus the CD headphones... The system has to run software that can exercise the computer as well as the various external devices (which, to get a realistic measurement, should be commercially available products). Then you put the computer on a stand that spins in front of an antenna that measures the noise. And your humble construction starts to spin...

Have you ever had this dream where you're a kid again, and you've arrived at school only to realize that you've forgotten to put your clothes on?

When the scan is over and you get the results, in which every imperfection in your work is magnified, you have the choice of fighting with the machine to lower the noise (inserting ferrites, playing with the mess of cables coming out of the box, adding gaskets to the chassis), going back to the (virtual) drawing board to rework your design—or you can hit the bars in an attempt to find your pants.

The 133 MHz BeBox complies with the FCC and European class B requirements; therefore, it can be sold to end users.

Be Developer Talk: Good Be Citizens

By Carlin Wiegner, Michael Klingbeil

Apple's original announcement that they were shopping around for an OS was the start to an open discussion about Apple's ability to actually deliver a modern OS. The Copland project has ended with little doubt that it was a failure. As the January Macworld Expo approaches, so too does Apple's announcement about its future plans for the MacOS. Considerable discussion about Apple choices and which OS would be best have taken place in the trade press, inside software vendors, and in the general population.

At StarCode, we just want the issue to be settled one way or another. If the Apple deal goes through, great! We can step up our development efforts and support a larger team.

Of a great deal more importance to us is to be able to use the BeOS full-time for all the things that we have come to expect PCs to do. We don't think we're alone in our desire to have a fast, stable, modern OS to work and play on. So, in our desire to be good Be citizens, what to do?

Well, the first step is to pick our five favorite apps that we'd like to see on the BeOS. These could be Photoshop, Eudora, or even Doom. Second, we must e-mail at least one person at the respective companies, whether it's the webmaster, or the person who answers, or the CEO—it doesn't matter. Third, make sure five friends do this as well with their favorite apps.

This has probably been the most noble cause ever to mail bomb a company. If we can get just a thousand Be aficionados to send e-mails by Christmas, we're guaranteed of changing some companies minds around the time of Macworld in San Francisco.

PackageBuilder and Beyond

Our PackageBuilder product will soon be in its third preliminary release. Aside from the usual bug fixes, this version finally sees the addition of binary patching capabilities. Following this release, we'll begin planning for the release of version 1.0, which should be available at about the same time as DR9 of the BeOS. For file-system intensive programs like our installer, the changeover to DR9 will likely involve considerable work. Our hope is that early planning can make this as smooth a transition as possible, both for us and for developers using our product.

In addition, with the release of 1.0 we finally hope to have a preliminary software uninstaller. The uninstaller will capitalize on the new and improved database, thus providing a quick and foolproof way to track installed software.

As usual we welcome feedback and product suggestions from fellow users and developers. The more feedback we see, the better we can make PackageBuilder 2.0. Additionally, if you have a specific installation need for your software, we'd love to come up with a speedy and effective solution for you. Let us know.

StarCode Software and Macworld San Francisco

StarCode Software will be demoing at Be's booth at Macworld San Francisco. We'll be showing the software, including binary patching (which we demoed at the December developer kitchen), and announcing our pricing. Come by and see us.

News From The Front

By William Adams

Whooo weee! Time sure does fly when you're having fun! This past year has been quite an exciting and tumultuous one. Be, Inc. as a company has gone from obscurity to limelight in a few short months. But all the hoopla surrounding the BeOS hasn't just been in the applications that we've shown at demos. Our developers have done quite a fine job of coming up with real applications for real-world use.

There are a number of notables, and we've highlighted a few in this newsletter. The bottom line is, you simply must take a look at the Be ftp site and the BeWare pages to get a good feel for what people have worked on and will continue to work on in the near future.

For once though, I'm not going to be long winded and give a big long story about what's gone by. Suffice it to say that a lot of time has passed, and many good things have been done. As a holiday gift, we have the source to the Clock application.

This is the last newsletter for the year, but it's not the last time you'll get sources. There are still a couple more things that will squeak out before Macworld, so keep an eye on the ftp site. Hopefully we'll be using this down time to catch up with actual tutorials.

The last Developer's kitchen was well attended, and a few developers were helped along to finish their efforts. We finished the year with a strong PowerMac port, and a promising future at Macworld. Speaking of which, there will be a Be Developer's Conference after the Macworld event on January 11th at the Hyatt Embarcadero in San Francisco. The general details are that the event will be held from 10 am to 6 pm or until we are kicked out. Look for more detailed information on our Web site soon.

For The Last Time

Since this is the last newsletter of the year, for one last time I want to say BOOOM BOOOM BOOOM! That's the last thumping of the drum to get developers to polish up their applications if they want them to be shown at Macworld on January 7. I'm speaking primarily to the crowd of developers who will not actually be in attendance, but who want their applications to be shown in some way. Get them uploaded to the ftp site as soon as you can, so that we can become familiar enough with them to show them with pride.

I bought my first BeBox about a year ago. I spent that first holiday vacation porting as many apps from all over the place as I could. Three releases of the OS later, I came to realize that I liked what I was playing with enough to actually join the company that was giving it to me. I don't regret my decision for a moment, and I'm having the time of my life in this venture. I hope we're spreading the same amount of excitement to the rest of our development community.


By Jean-Louis Gassée

I wonder if the era of the "free" Internet is coming to an end. For a couple of decades, the Internet grew in the relative obscurity of a community of UNIX users in university research laboratories. In the spirit of academic freedom, most everything was accessible, shared, and virtually free. For proficient users, the feeling of power and reach was exhilarating. More than five years ago, companies such as NetCom in San Jose started selling dial-up Internet access for what passed then for ridiculously low fixed fees. Mosaic appeared and the Net started to become accessible to normal, or at least less geeky people. We know what happened: Tens of millions of people (I leave the exact number to the professional sages) are now connected, and companies such as America Online and Compuserve have been forced to drastically alter their business models—to say nothing of their accounting methodologies.

But now we start hearing a different tune. Users complain about pesky servers, interrupted connections, slow or frozen downloads, cranky DNS servers, and the worldwide wait.

In many respects, we found an infrastructure and we clear- cut it. At least, that's the way the phone companies will describe it. Local calls are free or almost free. They're subsidized by long distance conversations. For these the local company gets an access fee, a cut of the long distance toll paid by the user to AT&T, MCI, and their competitors. Voice calls are measured in minutes, not hours. Now comes the friendly neighborhood ISP. The call to the access point is a local one, and once you hop on the Net, there's no more long distance toll rebated to the local phone companies. The Internet calls measure in hours, not minutes, and eat capacity at the local phone company. The development of the Net forces these companies to bring profit-free new capacity on line. Whatever we otherwise think of the phone companies, if they install another line at your home because you spend hours on the Web, they'll not get the same return for their investment. They feel ISPs and Net users have clear-cut the infrastructure without providing funds for replanting.

Turning to the potential for highly interactive, high- bandwidth multimedia on the Net, we must underline the word potential. Nowhere is the infrastructure capable of sustaining the peak bandwidth these data types require. What about the cable network and cable modems? This is another case of a tired infrastructure stretched well beyond its carrying capacity. It's so easy to add new users, new taps on a cable, at least in the theory of a broadcast model. We know what consumers think of the signal quality and service "enjoyed" on cable. When asked what he thought of the competition that cable operators might create for the local phone companies, one executive asked in return: "Would you trust these guys to carry your 911 call?" And in addition to the problematic quality of today's cable infrastructure, clear-cut as it is already, the Internet with all its problems still lies beyond the head end of the cable system.

Back to the Net, then. If the potential is to become reality, someone will have to pay for replanting, for creating more carrying capacity, or the navigators will discover that the trees have run out. Who will pay to create new capacity? Users, advertisers, content providers, the taxpayer? Are we going to have several classes of service for IP packets, as we have for letters and parcels? I hope the answer to the latter question is yes, so taxpayers don't have to pay for services they may or may not use. It might be feasible. After all, this is the country where the Postal Service seems to balance its budget. Let's hope the IP Service does the same for basic net services and that we'll see a range of faster IP courier services emerge as well.

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: Better thread control

AKA: Thoughts

More discussion of threads, semaphores, and (somehow) sockets. The primary topic was the efficiency of semaphores (which, in this debate, means multithreadedness) in the light of the context-switch overhead: At what point does multithreading lose its appeal because of the overhead incurred by hitting the controlling semaphores? No clear answers, here, but some numbers were thrown around.

Subject: Preferences and version numbers

Where should version information go, and how should it be accessed? Is a binary version (of the version) necessary so installation tools can operate properly? Also, what do you have to do to satisfy copyright requirements? According to one of our listeners, copyright info must be presented to the user when the app is launched, and a human-readable (and so hexdump-displayable) version must be embedded in the binary. But is this so? Another listener claimed that the "must be presented to the user" rule refers to license agreements, not copyrights.


Subject: Accessing Preferences

More talk about where preferences info should be stored in a multi-user system. Various existing methods were described and considered (but mostly dismissed). The database as a compendium of preference values keyed to individual users is the popular choice, although there are still some "preference directory" holdouts.

Subject: BWindowScreen

AKA: Multiple Monitors

This thread became a discussion of multiple displays. The app server doesn't support multiple heads yet, but once it does, how should they be used? Should each monitor be a separate workspace? There was some speculation that splitting a single workspace over multiple displays would be inefficient. Others argued that you could (theoretically) split a single window between monitors with no significant overhead, so one-monitor/one-workspace isn't a necessary restriction.

THE BE LINE: Note that you *can* plug in multiple gfx cards and monitors to develop a video driver, but the app server will only talk to the first card that it finds. For more info on video driver development, see William Adams' column in last week's Newsletter (#53).


Subject: Mail system design.

An initial query, "why is there a mail_daemon?" elicited a number of quick (and well-tuned) responses: So you can easily plug in your own mail application. As Jake Hamby put it:

With mail_daemon, I just make the BMailMessage and then it takes on whatever user prefs have been set: connection frequency, POP/SMTP options, whatever. And as Jon Ragnarsson commented, it was frighteningly simple.

This led some readers to ask for even more "pluggable" servers, for http, sockets, ftp, etc.

Subject: access exception in __ptr_glue

This one's worth repeating (and committing to memory):


Any ideas as to what a "data access exception" in "__ptr_glue" means?


[quoting Jon Watte's reply] “__ptr_glue is the place all calls through function pointers and calls through virtual methods go. You've either called a bad function pointer, or a virtual function of a bad object.

Subject: Messaging speed and efficiency.

AKA: Async I/O via BMessages

What's the best way to handle hundreds of messages a second? Can the BMessage system keep up? Also, what does the kernel use for sending messages? Ports (according to one listener) don't seem fast enough to explain the responsiveness of the machine.

THE BE LINE: (from Dominic Giampaolo) “I believe we can send around 7,000 or so 64 byte messages per second on a 66 MHz BeBox and even more on the 133s. Try to make your messages a power of 2 in size: It's actually faster to send 64 bytes than to send 62.” (Dominic off)

The kernel indeed uses ports, which are faster than the current suspicion.

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