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.

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.

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.

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.

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.

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.