At the top most level, there are only directories (and the ubiquitous Jamfile):

• /boot - this is the directory that contains boot information and tools to make a bootable kernel
  
• /core - this is the crown jewels - the "main" code of the kernel
  
• /drivers - a home of their own
  
• /global - for any code that spans the above
  
• /glue - this is the code that must be linked with each executable
  
• /ldscripts - this ain't like dusting crops, boy - one wrong move and your kernel is retargetable...
  
• /libc - all those little functions that developers take for granted
  
• /libm - all those little functions that pencil pushing math majors understand
  
• /prefs - for the preferences apps for the kernel
  

Since everyone is so interested in core, let's talk for a brief moment about each file/directory therein...

• /core/addons - this is where the (surprise) addons go - our kernel is modular, too. Examples include file systems and bus managers
  
• /core/arch - home of the architecture specific stuff. This is the place for the portability police to start their investigation
  
• /core/fs - contains the code for the pseudo file systems - vfs, bootfs, etc
  
• /core/vm - the virtual memory module
  
  
• cbuf.c - this is a whole file dedicated to a buffering system. Used in the ports system.
  
• console.c - implements kernel versions of printf.
  
• cpu.c - contains the atomic* and test_and_set system call implementations
  
• debug.c - contains the kernel debugger
  
• elf.c - functions to load and interpret ELF files (executables)
  
• faults.c - handling for processor faults (like divide by 0, etc)
  
• gdb.c - code to allow the kernel to be remote debugged by gdb
  
• heap.c - malloc and free for the kernel
  
• int.c - interrupt handler code
  
• khash.C - yes, that's right, some almost C++ code. A generic hash table implementation
  
• lock.c - recursive locking and mutex implementation
  
• main.c - doesn't everyone need one of these? Initialized the system. The only allowable place for while(1). :-)
  
• misc.c - some checksum functionality
  
• module.c - in order to have a modular kernel, someone has to load the modules...
  
• port.c - implements ports, so messaging can work
  
• queue.c - very simple queue - goto algorithms 101
  
• sem.c - semaphore implementation
  
• smp.c - for those lucky dogs with more than one processor, we need Symmetrical MultiProcessing
  
• syscalls.c - because user land wouldn't be the same without it
  
• thread.c - processes and threads are implemented here. Also the scheduler.
  
• timer.c - All timer stuff, including task switching, goes through here
  

Whew.

Ok, so now that we have some (vague) idea about what is already there in the kernel code, what is there left to do? A whole lot. Here is the "to do" list, so far, in no particular order:

• Properly handle environment variables
• Improve the scheduler
• Improve the kernel memory allocator
• Work on VFS - make 100% backward compatible and make work with OBFS
• VM - everything
• bus managers - improve PCI and ISA, implement USB
• finish the building of the kernel - everything compiles, but it doesn't make a useful image
• tty layer, for terminal
• signal handling
• IDE / ATAPI
• include Networking
• more POSIX functionality (maybe from BSD)
• Implement the kernel kits functions in user land
• Work out video driver accelerant functionality
• test like crazy

One such friend visiting me this weekend was lamenting about trying to send a fax from Windows. She is a real estate agent (and an honest one, too). She often has a need to "fax to this number", not knowing who the number belongs to or ever having the need to send anything to them again. A "one-off", if you will. She tells me that her software requires her to put numbers in her address book *before* she can fax to them. The software doesn't allow one-offs.

This reminded me of my most frequent objection to what I will call the "Complete Solution" syndrome. This malicious malady strikes developers who are driven by marketing people and by listening to the surface objections of end users. Complete Syndrome is the disease which causes most of the code bloat and useless work that developers have to do. It is the antithesis of good engineering and good UI design.

Complete Solution can be defined as making a one size fits all application that has to do everything possible for a particular operation or data type. A good example of this is WinZip. I like Winzip because it does everything that one could ever want to do with a zip file. If you look at it, though, you will notice that it has an "Explorer like interface". Well, honestly, if I want to use Explorer, why don't I just do so? WinZip adds contextual menu items for "Add to archive" and so on. WinZip's interface gets in the way more often than it really helps me. Most of the time I either want to add files to a zip file or take them out. That is all. Small and simple.

The core problem with Complete Solution is hubris. The application developer has to think of every single thing that an end user could ever want to do within this application, and implement it. Microsoft continued this trend, back in the day, when they introduced the "Windows 95 Compliance Program" - one of the keys to comply was that an applciation had to allow the "document" being worked on to be emailed from the file menu. To this end, they created an API (MAPI) to allow developers to add this "feature" fairly easily. The problem is that the problem is not complete. Maybe I want to FTP this file instead. Often that is the case with web pages, so web page development application implemented FTP and put it in the File menu. But what if I want to FTP a Word document to a website? Or maybe I want to zip my document? Shouldn't I be able to do that from within the application?

Complete Solution isn't and never can be, despite its name. The problem is that as the number of operations grows, the number of combinations of them grows exponentially. Like menu choices in Word. Maybe I want to encrypt, zip then email my document. Maybe I want to convert it to XML, run it through an XML quality validator, then FTP it to my web site. If email is a valid choice for the File menu, why are any of these less valid? Truth is, they are not.

When code gets really hairy, conventional wisdom says to refactor it. Too many cooks have spoiled the soup and it is time to rework the kitchen to divide the labor more sensibly. We have been having a wonderful conversation on Glass Elevator about how to do this. That maybe applications as monolithic entities are a dying breed. That instead of a "tractor app", we should have "tractor applets".

One of the neat demos that I remember from back in the Be days was a paint program, where the demo giver would select a piece of a picture and drag it onto the desktop. The selection would be saved as its own bitmap. Can you imagine working on a picture without loading an application? Right click on a file and get a list of actions that you can perform on it. Maybe lasso-select, in the bitmap's case. A viewer window pops up, allowing you to lasso the piece of the picture that you want to select. That selection is saved on the desktop, a folder, or wherever you drag it. You right click on the selection file and choose blur. A little window pops up containing a slider (amount to blur) and a direction chooser; a preview button defaults to unchecked. The newly blurred image can be dragged on top of the old one, or a new file made. But we decide, instead, to drag that blurred piece onto the original. The blurred image is put back where the original was cut from and voila - a work of (avant garde) art, without ever opening a "real" application.

I come from the former group, having developed Java professionally on Windows and Linux for several years now. But I can also fit into the latter group since my skill in C and C++ (the core programming languages on BeOS) is sketchy at best. So for those of you in the situation of wondering where to start in your dream to program on BeOS, this article is for you.

User Before Programmer

I have one fairly obvious statement I must start with: you can't be a BeOS programmer if you aren't a BeOS user. It seems obvious of course, but I was stuck in this rut so I'm sure other people are as well. If you don't currently have a machine running BeOS R5, take the time to install it somewhere. I'm sure almost anyone can download the 50 MB Personal Edition and install it on their Windows machines, and for the more adventurous we have the "Be Developer's Edition" put together by some of our friends in Germany. So again, if you haven't done it yet, get off your rump and install BeOS!

Once you have BeOS running, read through the BeOS Tip Server and other sites and maybe get a copy of Scot Hacker's BeOS Bible (he is the one who did/does the Tip Server.) Doing this will help you find and use some of the more advanced features of the BeOS, which you can later put to use in your programming. For example, once you have mastered using the Find dialog to do some advanced queries, you will be that much more prepared to put the BQuery class to good use.

Speaking in Tongues

While you are learning the ins and outs of BeOS from a user's perspective, you should also be learning some programming languages. If you are already a skilled developer in C and C++ (or even Java) on other systems, you are in pretty good shape. If not, here is some advice: buy some books.

Learning C and C++ is not something you can do through trial and error, and having some real paper to refer to in those late-night coding sessions can be a life-saver. Also, get at least one C book and one C++ book because it is important that you learn their similarities AND differences. Sometimes you may need to decide which language is appropriate for the task at hand (C for command-line programs and kernel stuff, C++ for GUI or other Be API stuff, etc.)

If you are a complete programming newbie, starting programming with C and C++ can be like diving into the deep end of the pool with a cement block tied to your leg. In that case, it may be wise to start your programming life with one of the so-called scripting languages. My personal favorite is Ruby. Another good one is Python. It is also very helpful if the language you choose has bindings for the Be API, which means you can actually call BeOS functions and use BeOS classes and methods from that language. I know Python has such bindings in the form of Bethon (check BeBits.) I don't think Ruby does yet, but as I'm such a Ruby fan I may create them myself one of these days.

But in the long run, I think it is important to learn C and C++ for BeOS programming, since any major app will need to be written in them. Knowledge of them is also useful in learning the Be API.

Jamming with the Best of Them

It would also be a good idea to make an effort to learn Jam. Jam is the designated build tool for OpenBeOS and build tools are critical tools when developing in C and C++. You can get the BeOS version of Jam I'm using here. I'm working on some more newsletter articles about Jam, so that should help everyone get going on it. In the meantime, here is a template that you can use for the Jamfile you use to compile small programs:

APP = <your app name...one space at the end> ;
SOURCES = <your list of sources, separated by spaces...one space at the end> ;
Main $(APP) : $(SOURCES) ;
LINKLIBS on $(APP) = -lbe ;

The API Challenge

The main challenge in learning how to program on any system is learning that system's API. An API is an Application Programming Interface, and it describes the functions available to programmers to interact with the system and perform various tasks. On systems like BeOS with a largely object-oriented API, you have classes and methods instead of just functions. So your challenge in becoming a proficient BeOS programmer is learning about all the classes in the BeOS API and how to best put them to use in your programs.

On the BeOS, the API is broken down into discrete units that Be calls kits. Each kit covers a specific and cohesive part of the API, for example:

• Application Kit - Contains the classes used in creating and running applications, as well as all the classes used in the BeOS messenging system.
• Storage Kit - Contains the classes and functions used in interacting with the file system.
• Interface Kit - Contains the classes used in putting GUI interfaces on the screen.
• Kernel Kit - Contains the functions used to interact with the lowest programmable levels of the system.
• Support Kit - A catchall kit for all the classes that don't fit into any of the other kits.

Given the above list of kits to learn, you may be wondering "where do I start?" Here is how I recommend you learn the 5 core kits:

1. Get a copy of the BeBook. If you have BeOS R5 installed you already have the HTML version in /boot/beos/documentation/Be Book/. For those who prefer paper there is a printed version from 1997 that O'Reilly published. I have this and have found it quite useful, though it is a bit out of date now. But I think finding a new copy of this is probably impossible at this point.
   
   
2. Once you have the BeBook, start your learning with the Application Kit. This is the kit that lays the foundation for applications and messaging on BeOS. It is important that you fully understand this kit. For this I recommend writing some small applications.
   
   Surprisingly enough, after learning this kit you can actually create quite a few neat little applications. You can create an application to get a list of all the other running applications like shown by the roster command-line program. You can write two separate applications that communicate with each other via BMessages. You can launch and then script other applications, such as NetPositive. So far I've done the first and third in this list, and they were a lot of fun and quite easy.
   
   
3. After you understand the Application Kit, move to the Support Kit. This one is fairly small and should be easy to learn. Mostly you will make use of the classes here when dealing with the other kits. For example BList is used in most API calls that involve lists of things (such as the list of running applications.) In fact, because of this, it may be wise to look over this kit before trying to code the learning applications that I recommended above.
   
   
4. Next is the Storage Kit. After learning this you will be able to read and write files, perform queries, look at file attributes and resources, and more. There are many sample applications that you could make after learning this kit, but I will leave coming up with those as an exercise for the reader.
   
   
5. At this point you can make a choice of what to do next. If you are eager to start making some GUI applications, go to the Interface Kit next. On the other hand, if you want to take a look at some of the lower level functions in BeOS, go to the Kernel Kit. But in the long run looking over both would be good.
   
   Actually one point regarding the Interface Kit: this is a big kit and can seem overwhelming at first. Therefore I recommmend just reading the introduction and then scanning through the rest of it just get an idea of what kind of classes are available. Then as you build applications and have a need for a particular GUI element, you can just find that and then read the details of how to use that class.
   
   Also sample code can be quite helpful in learning how to use the Interface Kit. Be provided a lot of sample applications (for all the kits) that you should be able to find on the various Be FTP server mirrors that are around. Here is one example: ftp://ftp.gbnet.net/pub/be/samples/. Other mirrors can be found on this Be Tip Server page.