It should just work

Body

I 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. One of the many reasons that I don't discourage them is that, if you have ears to hear, you can learn a lot from users. Oh — and I want to keep my friends.

Device driver basics

Body

Device 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.

Let's make use of Thread Local Storage!

Body

TUTORIAL 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. In fact, I think it calls _h_errno() defined somewhere else, but that's the idea.

Unit Testing

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.
  • All requirements of the software component are tested as part of the unit tests.

Unit testing is not the only type of testing but is definitely a very important part of any testing strategy. Following unit testing, software should go through "integration testing" to show that the components work as expected when put together.

Binary Compatibility in 3 Easy Steps!

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.

CD-ROMs, Unit Testing, and You

Body

I will go out on a little bit of a limb and say that the single most important and beneficial step that you can take to improve your code is to test first. Yes, I know. I hate testing, too.

I picked up a few books on Extreme Programming several months ago. There are far more useful tidbits of knowledge in there than I can explain in a short article, but one of the most simple and useful is to take what you *hate* and do it *more*. The premise to this unusual practice is that the more you perform this task, the more you choose to automate it, because you loathe to spend so much time on it. This dove-tails nicely with the old axiom that programmers are among the world's laziest people.

Division of Labor: Kits, Libraries, Servers, and Teams

Body

Note: this article was written by Daniel Reinhold.

I remember several years back (about spring '96) when I first discovered the joys of the internet and was amazed at the sheer number of goodies to be plucked. This was well before BeOS Intel, so I spent alot of time downloading Windows shareware programs. After a few months, however, the excitement died down considerably when I discovered an unfortunate truth: most of those shareware programs were complete crap. If they didn't crash within a few minutes, their interface was so awkward that I just couldn't stand to use them.

Ufetch: a Basic Web Client

The web has certainly become one of the most ubiquitous and important publishing spaces around. What defines the web, technically, is html and http. Html is the publishing format and http is the transport protocol.

Let's consider http. This protocol is so simple. Some would say simplistic — it certainly has it share of detractors. While it may not be the most sophisticated protocol around, it gets the job done.

Using Scripting in Haiku

Body

With this article I hope to explain the basics of scripting using BeOS and how it can enhance the Haiku project. To try out several examples mentioned in this article, you'll have to download a program called hey, which enables you to script BeOS applications from a Terminal.

The program hey was developed by Atilla Mezei, an early BeOS developer, who unfortunately seems to have left the BeOS community. He created this tool to have a good testing tool when implementing scripting in BeOS applications.

Design goals for the Game Kit

Body

The Framework

If one is to believe the books and magazine articles, websites, and game developers one talks to these days, there seems to be a general consensus that the bare-metal, code-it-from-scratch mentality just doesn't cut it any longer when developing games. Software engineering practices long appreciated elsewhere in the software development world are finally making an appearance in the last bastion of the garage-hacking, caffeine-swilling coder.

This is for a lot of reasons. For instance, game publishing schedules ("If it doesn't ship in time for Christmas, we're gonna lose our shirts!"), lack of in-house expertise ("Sure I can write that, just let me brush up on my number theory first."), egg-on-the-face from having shipped buggy products (let's not name names), improved tools and the general enlightenment of the coding community, amongst many other factors, are all changing the way games are made.