Body: Late at night, beating my brains for yet another newsletter article, my eyes were drawn to a notebook nearby my desk. This notebook contains my ideas that I brainstorm for future versions of OBOS. One of the complaints that people have is that R1 as we have defined it has no "future". It doesn't do anything beyond recreate what Be did and that we should aim higher for our first release.
So, I'm sure you're all dying to know about the new grand unified CppUnit testing framework we have. What? You haven't heard of it? Color me unsurprised. :-)
Part I Running Tests
For those of you who are purely interested in helping us out by running the tests on your own computer, this section is for you.
First off, you'll need to slurp a copy of our repository onto your computer. Next, you'll need to build the entire tree (technically you don't need the *whole* tree, but it's easier on me if you just build it all; that way I don't have to list off all the targets you'd need to specify :-). For those who are unsure of how to do this, get a copy of our development tools off the Download page, do an anonymous checkout of our repository (check out Getting and Building the Haiku Source Code for details), run ./configure from the current/ directory, run jam from the current/ directory, and go watch The Godfather (possibly all three of them) while everything builds.
BodyOptimization is one of those topics that everyone thinks that they understand a little about, but is often surrounded by platitudes, mystery and rumour. I want to talk a little about when to optimize, why one should optimize and some of the more successful techniques of doing so.
Keep it simple The first rule of optimization is, "Don't". As Extreme Programming says, "Do the simplest thing that will work". If you are working in an OO language, this is often fairly easy because of information hiding.
Note: this article was written by Daniel Reinhold.
One of the features of modern operating systems is the ability to separate application code from the critical code that implements the core of the system. Regular applications run in user mode (often referred to as userland) which means that they cannot directly manipulate the vital system data structures. This makes everything much more stable -- buggy apps may crash and burn themselves, but they can't bring down the rest of the system.
The flipside to this protection is that userland code is walled off from the kernel code. This means, for example, that your application cannot directly call a kernel function. But the kernel implements many useful services that most apps would like to take advantage of. Indeed, that is one of the main purposes of the kernel -- to abstract all those icky underlying hardware details and provide a clean, consistent interface for applications. So how does all this useful interface ever get called and used?
Intro Recently, David Reid reported that the OpenBeOS kernel source tree had been amended to fit its new environment after forking from NewOS. The jam scripts had been written, tweaked, and tested, and the new kernel was now capable of being built. He even included a picture of his computer booting from the freshly created floppy.
While I was happy to report this, I hadn't actually tried to do a build myself.
BodyI had a lot of company this weekend it was really our first time entertaining in the new house (other than an occasional friend dropping by). I like to think that my friends are a fairly intelligent group. Birds of a feather and all. My friends often come to me for help with their computer "issues", despite the fact that I haven't run Windows as my OS of choice since 1996.
BodyDevice drivers are difficult to write. Understanding the hardware can be the hardest part. Often the documentation is hard to read and understand because it is written from a hardware designer's perspective (that is, if you can get the documentation -- many manufacturers are very reluctant to give it out). Drivers work directly with the kernel - a bad pointer can crash the whole OS. And, finally, you can't use warm and comfortable debugging tools, since you are working in the kernel.
BodyTUTORIAL NEEDS REVISION - as stated in comments - "Note one should use initialize_after() and terminate_before() instead of _init() and _fini(), as the shared object crt code actually defines them already in BeOS, to do some dirty tricks, and call the initialize/terminate functions when present." - NEEDS REVISION
Last week, I came across an interesting problem which I had not dealt with before. Some people on IRC were discussing the testing of the new netkit, and had problems with the unimplemented libnet call _h_errnop(), which supposedly returns the address of the errno variable for network funcs.
Unit testing is the process of showing that a part of a software system works as far as the requirements created for that part of the system. Unit testing is best if it has the following characteristics:
The software component is tested in isolation with as little interaction with other software components as possible. The software component is tested using automated tools so that unit tests can be run with every build of the software if required.
In the early days of the Haiku project, a debate raged concerning one of the projects primary goals: maintaining binary compatibility with BeOS R5. The idea was that the only way an effort to rewrite BeOS would be successful was if folks could continue running the apps they already had.
Certainly, a lot of software available for BeOS is open source or actively maintained -- these apps could just be recompiled if necessary. Others -- PostMaster, Gobe's Productive suite and a few other crucial apps -- weren't likely to get rebuilt, either because the original author had stopped maintenance without being kind enough to release the source, or because it just wouldn't be commercially feasible.