One of the many upcoming changes in the BeOS is in the world of input devices and events. The Input Server, slated to debut in R4, is a server that deals with all things "input." Specifically, it serves three functions: manages input devices such as keyboards and mice; hosts a stream of events that those devices generate; and dispatches those events that make it through the stream.

This is my first Newsletter article, so let me introduce myself. I'm Trey Boudreau, and I write graphics drivers at Be. Or not exactly "at" Be, since I'm one of a few Be employees not located in either Menlo Park or Paris.

That's it for the introduction—now some content...

As anybody who's been around the BeOS awhile knows, graphics drivers are app_server add-ons and not kernel drivers. So why is the graphics guy writing about kernel drivers? Because in R4 all graphics drivers have a kernel driver component, as well as a user space add-on (called an accelerant).

I could talk about writing R4 graphics drivers, but since you don't have R4 yet that wouldn't be too useful. Instead, how about some handy tips for writing kernel drivers, since I've been doing a lot of that lately. I'll assume you've read the Be Book Device Drivers chapter - DeviceDrivers.html - even if you haven't written a device driver yet.

typedef bool (*interrupt_handler)(void *data);

long install_io_interrupt_handler(
  long   interrupt_number,
  interrupt_handler handler,
  void   *data,
  ulong  flags);

long remove_io_interrupt_handler(
  long   interrupt_number,
  interrupt_handler handler);

long remove_io_interrupt_handler(
  long   interrupt_number,
  interrupt_handler handler,
  void   *data);

write_pci_config(bus,dev,fun,0x41,1,val)

uint32 val = something;
uint32 tmp = read_pci_config(bus,dev,fun,0x40,4);
tmp &= 0xffff00ff;
tmp |= val << 8;
write_pci_config(bus,dev,fun,0x40,4,tmp);

This week, we're going to relax a little and put together a nice, simple class for saving program settings to disk. You can download the source code for this week's project from the Be FTP site:

ftp://ftp/pub/samples/intro/prefs_article.zip

The BMessage provides a handy container for data. Although its primary use is for sending data between two pieces of software, its tagged data item format is ideal for use as a cross-platform data storage mechanism. Thus we introduce the TPreferences class, which is derived from BMessage:

class TPreferences : public BMessage {
  public:
    TPreferences(char *filename);
    ~TPreferences();

    status_t    InitCheck(void);
    status_t    SetBool(const char *name, bool b);
    status_t    SetInt8(const char *name, int8 i);
    status_t    SetInt16(const char *name, int16 i);
    status_t    SetInt32(const char *name, int32 i);
    status_t    SetInt64(const char *name, int64 i);
    status_t    SetFloat(const char *name, float f);
    status_t    SetDouble(const char *name, double d);
    status_t    SetString(const char *name,
                          const char *string);
    status_t    SetPoint(const char *name, BPoint p);
    status_t    SetRect(const char *name, BRect r);
    status_t    SetMessage(const char *name,
                           constBMessage *message);
    status_t    SetFlat(const char *name,
                        constBFlattenable *obj);

  private:
    BPath      path;
    status_t    status;
};

The most obvious additions here, beyond the normal BMessage functionality, are all the SetX() functions. These let an application explicitly set the value of a tagged item in the TPreferences object, without having to determine whether to call AddX() or ReplaceX(). This is very useful when treating a BMessage as a data container.

We'll be taking advantage of the fact that a BMessage is derived from BFlattenable. Objects derived from BFlattenable can be "flattened" into a dehydrated format and saved to disk, then later reconstituted ("unflattened") into a duplicate of the original. Flattened objects are endianess-independent, so we get cross-system compatibility between PowerPC and Intel absolutely 100% free of charge. As programmers, we like things that are actually free (and there aren't many).

Let's have a look at the constructor:

TPreferences::TPreferences(char *filename) : BMessage('pref') {
  BFile file;

  status = find_directory(B_COMMON_SETTINGS_DIRECTORY, &path);
  if (status != B_OK) {
    return;
  }
  path.Append(filename);
  status = file.SetTo(path.Path(), B_READ_ONLY);
  if (status == B_OK) {
    status = Unflatten(&file);
  }
}

The constructor's primary responsibility here is to open the preference file and read in the original settings. First, find_directory() is called to obtain a BPath referencing the common settings directory (i.e., /boot/home/config/settings). If this fails, the TParameter field status is set to the error code and the constructor returns. The application can use the InitCheck() function to determine whether or not the preferences were read successfully.

If all is well, the preference file name is appended to the path, and the BFile is set to read that file. If this succeeds, the file's contents are unflattened into the TPreferences object.

The destructor's job is to save the preferences to disk:

TPreferences::~TPreferences() {
  BFile file;

  if (file.SetTo(path.Path(),
    B_WRITE_ONLY | B_CREATE_FILE) == B_OK) {
      Flatten(&file);
  }
}

This creates a BFile object, sets the path to the preference file's pathname (which has been saved in the path field in the TPreferences object), and then flattens the TPreferences data into the file.

The various SetX() functions all look about the same, so we'll arbitrarily look at SetBool() as a representative of its kin:

status_t TPreferences::SetBool(const char *name, bool b) {
  if (HasBool(name)) {
    return ReplaceBool(name, 0, b);
  }

  return AddBool(name, b);
}

SetBool() accepts an item name and a boolean value to save with that name. The function begins by calling HasBool() to see if a boolean by the indicated name already exists. If it does, ReplaceBool() is used to replace the existing value. Otherwise, AddBool() is called to add a new boolean with the given name. B_OK is returned if all is well; otherwise, an error is returned.

Note that the TPreferences class doesn't support item arrays; you can only save one item with a given name. In general, this shouldn't be a problem.

That's the basics of implementing the TPreferences class. Now, a simple example that demonstrates its use. This little program keeps two values in its preference file: the real-time clock value at which the program was last run, and the number of times it's been run. When you run the program, it shows you the current values, then updates them.

The whole program (see sample.cpp) is contained in main(). Let's look at it one bit at a time:

TPreferences prefs("PrefsSample_prefs");   // Preferences
if (prefs.InitCheck() != B_OK) {
  prefs.SetInt64("last_used", real_time_clock());
  prefs.SetInt32("use_count", 0);
}

This code instantiates our TPreferences object. The preference file's name is PrefsSample_prefs (so its full path is /boot/home/config/settings/PrefsSample_prefs). Once it's instantiated, we call InitCheck() to see if all is well. If it's not, we initialize the two values: last_used is initialized to the current real- time clock value, and use_count is set to zero. Then we call PrintToStream() to print out the contents of the TPreferences object:

prefs.PrintToStream();

Finally, we update the preferences:

int32 count;
if (prefs.FindInt32("use_count", &count) != B_OK) {
  count = 0;
}
prefs.SetInt64("last_used", real_time_clock());
prefs.SetInt32("use_count", ++count);

We call FindInt32() to get the current value of the use_count preference. If an error occurs, we set it to zero as a safe alternative. Then we call SetInt64() to set last_used to the real_time_clock() value, and SetInt32() to set use_count to one greater than the previous value.

That's all there is to it. Since the TPreferences destructor automatically saves the settings, we don't have to do anything else. Go ahead and compile the project, then run it a few times, and you'll see that, indeed, the values go up every time you run it.

That's a wrap for this time. We'll move on to our next project in about six weeks.

Looking back to 1981, when the first IBM PC came out, it's hard not to wonder how far its DNA will allow it to grow. Today's dual-processor 450 MHz Pentium II system is a direct descendant of its 8086-based Apple ][ competitor, down to the cassette player interface.

The good news is the PC market grew out of a succession of compatible developments, both hardware and software. The bad news is today's PC carries with it a certain amount of baggage. At each step along what now looks like a glorious road, compromises were made. New technology had to be grafted onto the existing frame; it had to keep running the old software and keep supporting the previous generation of hardware devices.

Look at the back of a PC today, or open the box, and you'll see a few examples. USB ports must co-exist with serial and parallel connectors, PCI and older ISA buses fight for space on the motherboard, and these are but the most visible examples. Other instances, perhaps more painful ones, are buried in the chipset and the BIOS.

Today's high-end, yet highly affordable dual processor system offers yesterday's supercomputer power. How much is wasted because of the old compatibility layers? How fast would this dual-processor system be if it were built from the ground up with today's technology—and only today's technology? And how much less would it cost than the current standard?

So far, the market has answered: the benefits of the incremental approach outweigh its disadvantages. The PS/2 and ACE attempts to create a *better* PC architecture have failed against the evolutionary approach. But, just as the stock market does not go up forever, just as no tree reaches the sky, the progressive approach is bound to reach its limit someday.

And why should we care? Shouldn't we stick to our unfinished knitting? Certainly, but we can't help lifting our gaze from it and dreaming of even faster and cheaper hardware, even if we're not really in a position to influence hardware standards.

Following last week's OPOS argument OPH and OPOS though, imagine a situation where Microsoft managed to effectively dictate a new PC standard running Windows NT 5.0 at the next WinHEC (Windows Hardware Engineering Conference) and have it embraced by enough vendors to give it critical mass. Wouldn't everyone, including our little company, benefit from such a liberating leap?

A truly perplexing perspective.