Be Newsletter

Volume IV, Issue 2; January 12, 2000

Table of Contents

• BE SMALL COMMERCIAL & CORPORATE DEVELOPER DISCOUNT
• BE DEVELOPER CLASSIFIEDS
• BE ENGINEERING INSIGHTS: Just How Much BeOS Do You Really Need?, By Trey Boudreau

1. GeekTek Systems 10% Off

GeekTek is offering a 10% discount for Be Small Commercial and Corporate Developers on all Intensibe, Velocibe, BeAthalon and BeON systems. Offer ends Jan. 15, 2000, so take advantage of it today. Limit 2 computers per developer.

To receive the discount simply include your Be Small Commercial or Corporate Developer ID in the 'notes' area of the GeekTek.com order form.

<http://www.geektek.com>

For information on upgrading to or joining the Small Commerical or Corporate Programs so you can take advantage of this discount go to <www.be.com/developers> or email devprograms@be.com.

2. BeBits Advertising 30% off

BeBits is offering a Banner Ad discount to Be Small Commercial and Corporate Developers until Jan. 31, 2000.

Regular $25.00 CPM (cost per thousand)
Discount $17.50 CPM (30% off)
1 month buy - $700 min with 40,000 impressions each month
2 month buy - $1400 min with 40,000 impressions each month
3 month buy - $2100 min with 40,000 impressions each month
etc...

- 40,000 impressions min. per month for this offer
- First come first serve. Only 5 developers can take
advantage of this offer!
- 1 month minimum
- 5 month maximum
- Cost must be paid up front for whole run
- Offer good until Jan 31, 2000

If you are interested, contact bebits@bebits.com and mention your name, developer program level, and developer ID in your email.

3. Rainbow Productions Systems 10% Off

Rainbow Productions is offering a 10% discount for Be Small Commercial and Corporate Developers on all of their systems until Jan. 31, 2000. If you miss the deadline, don't worry... they'll have different business packages available throughout the year.

Those who wish to take advantage of this offer should mention your Small Commercial or Corporate Developer ID at the time of purchase.

<http://www.rainbowe.com/>

Do you want the latest game demos available for BeOS? Wildcard Design will burn you a CD of their latest game demos and ship it to you immediately, anywhere in the world. The total cost (including shipping and handling) is under $10, so order your copy today! (You can locate the CD sampler at http://www.wcdesign.com/preorder/)

As developers, you're probably aware that BeOS is a layered system. The kernel is at the bottom with its drivers and modules, followed by a few libraries (root, net, textencoding), various servers (app, input, registrar, net), a few more libraries (be, netdev, tracker) and finally, applications. The whole collection makes a wonderfully synergistic system. But just how much of that stack do you really need?

It Depends[TM]

What do you want to do? Occasionally, a demo coder thread erupts on BeDevTalk. Invariably, someone laments about the overhead of this or that feature of the OS. Without commenting on the relative merits of these discussions, I can tell you how to get as close to the silicon as you can without writing your own drivers. But to do that, we have to decide what we don't need.

R.I.P. app_server

If you want to get close to the hardware, you've got to go around the app_server. Or better yet, not run it at all. Once you take this step, every other server in the OS is useless, so they can go too. Because networking runs as a server (at least until BONE shows up), networking is right out. No servers means no libbe.so and friends. Just about the only thing left is libroot.so, but that's quite a bit. You still have just about all the POSIX we support, plus access to BeOS-specific features, such as loading add-ons and creating semaphores. This means any class of driver for which you know the ioctl() API is still usable. We'll get back to this in a bit.

Booting BeOS

By systematic trial and error, you'd find that you need very few files to boot BeOS. I'll save you some time and tell you what you need for the loader to boot to a particular partition. You'll definitely need the kernel (and zbeos on x86 hardware), and whatever drivers/busses/modules support your particular hardware. You'll need the accelerant for your graphics card(s). And you'll need two other files: /boot/beos/bin/sh and /boot/beos/system/boot/Bootscript. Bootscript can be empty, but it must exist. sh is the program the OS executes to get things started. BASH is nice, as shells go, but not needed for this operation, so I decided to replace it with my application. For getting started, you can just replace sh with your own app, but for grins I removed (almost) everything that wasn't required for my particular hardware. 'du -k /test/beos' reports a measly 2493K.

The Demo

NOTE: I Am Not A Demo Coder. Besides, this was not really an exercise of my demo coding skills. I'm just the point man, and I've discovered these two tips/traps:

• To aid debugging, you'd like to keep a log file (and/or generate serial debug output). Calling freopen("/boot/var/log/demo.out", "w", stdout) is useful in this respect. You can do what you like with the other standard file handles. In my program I get stdin from /dev/null and freopen("/boot/var/log/demo.err", "w", stderr) in case something I load as an add-on uses it. You can also call disable_debugger(1) and arrange for your app to get all the signals itself, but I don't do that in the demo.

• Set the ADDON_PATH and LIBRARY_PATH environment variables. If you don't, load_add_on() will fail -- even if you specify a full path to the add-on.

The meager demo application can be found at: <ftp://ftp.be.com/pub/samples/graphics/SlimDemo.zip>

If you've ever looked into the test harness shipped in the R4 Graphic Driver Kit, chunks of the sample code would be eerily familiar. Programming at this level is fairly unexciting, and this code is no exception. The main() function initializes the standard file descriptors and environment variables mentioned above, and then spawns and waits on a thread to handle the display chores.

The spawned thread hunts down and opens a graphics device, and then attempts to load the corresponding accelerant (R4 graphics drivers are two-part beasts, as is common under BeOS). After the accelerant is loaded, the code sets the first reported display mode and then begins the cheesy (and short) "animation." I didn't bother to set up and use hardware acceleration, but it's easy to do, and the harness program in the driver kit will show you the way. When the animation finishes, the accelerant is uninitialized and unloaded, and the device is closed. The thread terminates, and shortly thereafter so does the application, leaving the kernel silently in charge of the machine.

B_DONT_DO_THAT

A friendly DTS staff member pointed out that while you can run the sample code while the full BeOS is running, you won't like the results. The current driver model doesn't do anything in the way of preventing you from opening and initializing the graphics device if it's already running. If you have specific combinations of graphics cards in your machine (and a BIOS that isn't broken, but that's another story), you can open and control the other graphics card(s). You might also consider not replacing /boot/beos/bin/sh on your primary boot partition, but rather making yourself a tiny test partition to play with. Caveat Programmer.

Now What?

That's pretty much up to you. Access to other devices is mostly a matter of issuing the right ioctl() calls. If you can't find them documented in the BeBook, in headers, or in some newsletter article, e-mail me. One of you d00dz write a l33t dem0, and show me just how lame my example really is.