Be Newsletter

Volume III, Issue 8, February 24, 1999

Table of Contents

• BE ENGINEERING INSIGHTS: Adventures in Graphics Drivers, By Leo Schwab
• BE ENGINEERING INSIGHTS: The Configuration Manager, Part II (Back into the fold), By Victor Tsou
• DEVELOPERS' WORKSHOP: Time isn't Relative, its Variable, By Stephen Beaulieu
• A Crack in the Wall, By Jean-Louis Gassée

This adventure is more true than I might otherwise be willing to admit. All persons and events depicted are entirely fictitious, except where they aren't. Unflattering characterizations of certain organizations are entirely deliberate and intentional.

You are in a cube. In front of you is a 16"
(visible) Sony monitor. In front of that is a
Mitsumi keyboard and an unbranded mouse. Just to
the right is a 266 MHz PC clone. The system is
running a development version of BeOS R4.

There is a graphics card here.
There is a floppy disk here.
There is a note from your boss here.
There is a Hoberman sphere here.

> INVENTORY

You have a well-used satchel. Inside it are

    A set of screwdrivers
    A small telescope
    A 16M laptop RAM module
    A book on decorative knots
    A PCMCIA Ethernet card
    Last year's tax return
    A 166 MHz Pentium laptop computer
    A bottle of echinacea capsules
    Hair sticks

Your wallet contains $3200.

> REPLACE KEYBOARD

You put aside the amazingly cruddy Mitsumi keyboard
and substitute your favorite AT&T keyboard.

> PUT LAPTOP ON DESK

The laptop is now on the desk.

> READ NOTE

"Write a driver for this card. We'd like it in time
for R4 release."

> EXAMINE GRAPHICS CARD

You are evidently the proud owner of a Yoyodyne
Monstra VelocElite-LX 128-3D-AGP graphics card.

> INSERT CARD IN MACHINE

The machine emits a curious and worrying noise.

> TURN OFF MACHINE AND INSERT CARD

The graphics card is now installed in the machine.

> TURN ON MACHINE

BeOS R4(devel) boots. You are looking at a
gray scale desktop.

> EXAMINE FLOPPY DISK

The handwritten label reads, "Programming docs."

> INSERT DISK AND PRINT DOCS

Nothing happens.

> INSERT DISK, MOUNT DISK, AND PRINT DOCS

The drive spins for a moment, and the command prompt
returns.

> READ DOCS

I see no docs here.

> GO TO PRINTER AND GET DOCS

The printer is out of paper.

> PUT PAPER IN PRINTER

There is no paper here.

> STEAL PAPER FROM COPIER UPSTAIRS

After installing the liberated paper in the printer,
you print your docs.

> EXAMINE DOCS

The cover page reads, "Yoyodyne Monstra
VelocElite-LX 128-3D Programmer's Reference. Alpha
Revision 05-31-98. Confidential and Proprietary.
Restricted Secret; Level Violet. Do not expose in
public. This document must be kept secured when not
in use. Disclosure of this document to third
parties is punishable by death."

> READ DOCS

After several hours, you finish reading the docs.
The VelocElite-LX is a depressingly predictable
variation on the VGA register set. There are some
registers that have unhelpfully terse descriptions.
The card also has the ability to execute rendering
command lists out of RAM.

You now know enough to write a rough driver for the
card.

> WRITE ROUGH DRIVER

After several days, you have driver ready to test.

> INSTALL DRIVER AND TEST
You reboot the machine.  The screen is blank.

> RUN 'minicom' ON LAPTOP

The 'minicom' terminal emulator is now running in an
XTerm on the laptop.

> PRESS ALT-SYSRQ ON MACHINE

Nothing happens.

> PLUG SERIAL CABLE INTO LAPTOP

The "kdebug>" prompt from the kernel debugger
appears on the XTerm.

> EXAMINE REGISTERS

After thirty minutes, you determine that two of the
sync registers are set incorrectly.

> FIX BUGS IN DRIVER AND TEST

You can't see anything.

> REBOOT IN SAFE MODE AND FIX BUGS

A new version of the driver is ready to test.

> TEST

You reboot the machine. You see a color BeOS
desktop.

> TEST MODES

You switch to 800*600. It looks fine.
You switch to 1024*768. It looks fine.
You switch to 1152*864. There are pixel sparkles on
the screen.

> PRESS ALT-SYSRQ ON MACHINE

Nothing happens.

> YES, IT DOES!

Oh, sorry, I forgot. You get a "kdebug>" prompt.

> EXAMINE SYNC REGISTERS

After forty minutes, you find nothing wrong with the
registers.

> EXAMINE REGISTER 0x6000

Register 0x6000 (FIFO watermarks) contains 0x0201
(powerup default).

> WRITE 0x0200 TO REGISTER 0x6000

This is one of the poorly documented registers. Are
you sure you want to do this?

> YES

The screen goes blank.

> WRITE 0x0201 TO REGISTER 0x6000

You see a color BeOS desktop.

> WRITE 0x0202 TO REGISTER 0x6000

The screen goes blank.

[ ...Many more iterations deleted... ]

> WRITE 0x1810 TO REGISTER 0x6000

The pixel sparkles cease.

> MODIFY DRIVER TO WRITE 0x1810 to 0x6000 AND TEST

You reboot the machine. You see a color BeOS
desktop, sans pixel sparkles.

> ADD HARDWARE BLITTER SUPPORT TO DRIVER AND TEST

You reboot the machine. You see a perfectly stable
display of utter garbage with icons and text on top
of it.

> FIX RECTANGLE CODE AND TEST

You reboot the machine. You see a color BeOS desktop.

> DRAG WINDOW

The screen turns blank.

> FIX BLITTING CODE AND TEST

You can't see anything. If you proceed, you will
likely be eaten by a Grue.

> REBOOT IN SAFE MODE, FIX BLITTING CODE, AND TEST

You reboot the machine. A color BeOS desktop greets
you.

> DRAG WINDOW

The window moves, but leaves "dirt" behind it.

> READ DOCS ON BLITTER

"The blit width register is set to the number of
bytes copied per row." Your code reflects this
statement.

> ADD FENCEPOST TO BLIT WIDTH AND TEST

You reboot the machine. Windows now drag normally,
except for some weirdness at the left edge of the
screen.

> EXAMINE WEIRDNESS

It looks as if the left four columns of pixels are
being blitted 64 pixels too high.

> READ DOCS ON BLITTER

There is nothing in the docs to explain this behavior.

> GO www.yoyodyne.com

You are in a Web site.

There are many links here.

> GO DEVELOPER SUPPORT

There is no developer support here.

> READ DOCS ON SUPPORT

There is nothing in the docs on how to get support.

> TALK TO BOSS

Your boss gives you the e-mail address of the contact
person at Yoyodyne.

> SEND MAIL DESCRIBING PROBLEM

The e-mail disappears down the Ethernet port, on its
way to yoyodyne.com.

> WAIT

Time passes.

You have new mail.

> READ MAIL

You have 1 new message(s):

From: john.smallberries@yoyodyne.com
"Oh, yeah. That's a known bug. The official
workaround is to copy those four pixel columns in
software."

> WRITE SPECIAL CASE FOR BLITTING CODE AND TEST

You reboot the machine. Windows now glide across
the display like silk.

> TEST 15 BIT MODES

All 15 bit modes work perfectly.

> TEST 16 BIT MODES

All 16 bit modes work perfectly.

> TEST 32 BIT MODES

The screen turns blank, then returns to the previous
mode.

> READ DOCS ON DISPLAY DEPTHS

"The following display depths are supported:

0x00: 4 bits
0x02: 8 bits
0x04: 16 bits (RGB 555)
0x05: 16 bits (RGB 565)
0x06: 24 bits (RGB 888)
0x08: 32 bits (xRGB 8888)"

> PRESS ALT-SYSRQ AND EXAMINE REGISTER

The display depth register is set to 0x05.

> WRITE 0x08 TO REGISTER

The display turns blank.

> WRITE 0x06 TO REGISTER

You see a color BeOS desktop.

> WRITE MAIL DESCRIBING PROBLEM

Nothing happens.

> ENTER 'c' AT DEBUGGER PROMPT AND WRITE MAIL

The e-mail disappears down the Ethernet port, on its
way to yoyodyne.com.

> WAIT

Time passes.

You have new mail.

> READ MAIL

You have 1 new message(s):

From: john.smallberries@yoyodyne.com
"I just spoke to our hardware engineer, and he says
that 32-bit modes don't really work all that well,
and they should be avoided. 24-bit works fine,
however."

> REMOVE 32 BIT SUPPORT FROM DRIVER AND TEST

You reboot the machine. You have now have a
functional accelerated BeOS desktop.

> CHECK DRIVER INTO SOURCE TREE

You check in your new source files into the master
source tree.

You have broken the build.

A dunce cap has appeared in your cube.

> FIX DEPENDENCY FILE AND CHECK IN

The build is restored to its former glory.

The dunce cap has vanished.

You have new mail.

> READ MAIL

You have 1 new message(s):

From: baron@be.com
"We're having trouble with the Yoyodyne driver in
the QA lab. Can you look at it?"

> GO QA LAB

You are in the QA Lab. Many machines on many
shelves are here, running test programs. The Baron
directs you to the misbehaving machine. Its screen
is blank.

> TELNET INTO MACHINE

A 'bash' shell prompt greets you.

> REMOVE FILE '/boot/home/config/settings/app_server_settings'
  AND REBOOT

You reboot the machine. You see a perfectly
functional 640*480 display.

The Baron looks like he has something to say.

> TALK TO BARON

He directs you to another machine. The monitor
looks as if it can't quite sync to the card's
signal.

> TELNET INTO MACHINE

A 'bash' shell prompt greets you.

> REMOVE FILE '/boot/home/config/settings/app_server_settings'
  AND REBOOT

Ha ha! That doesn't work this time! A sense of
crushing defeat envelops you.

> DON'T EDITORIALIZE

Sorry.

> EXAMINE MONITOR

You are looking at a Flabloden 15ZF monitor.

> READ MONITOR DOCS

"Congratulations on your purchase of a Flabloden
15ZF monitor. Our products are fully compliant with
VESA standards, including the VESA signalling and
GTF specifications, assuring your monitor will work
with whatever the hell graphics card you have
installed..."

> GO www.vesa.org

You are at the Video Electronics Standards
Association's Web site.

There are many links here.

A Reporter from CNN visiting Jean-Louis wanders by.
He glances in your cube.

> HIDE YOYODYNE DOCS!

It is too late. The Reporter has seen the docs on
your desk. A lightning bolt stabs out of the sky
and through the ceiling, striking the Reporter,
leaving only a smoking pile of ash.

> CLEAN UP ASH

You dutifully clean up the Reporter's remains.

> SEARCH FOR GTF DOCS

You find a link here named "VESA General Timing
Formula."

> GO VESA GENERAL TIMING FORMULA

A Troll bars your way. He is demanding tribute.

> EXAMINE TROLL

He is big, strong, mean, ugly, pitiless, and
unusually well dressed.

> EVADE TROLL

Despite your best efforts, the Troll thwarts your
attempts to evade him.

> TALK TO TROLL

"THOU CANST NOT PASS LEST THOU PAYEST UNTO ME MY
RIGHTFUL TRIBUTE!" thunders the Troll.

> EXPLAIN SITUATION TO TROLL

The Troll ignores you.

> KILL TROLL

You can't do that.

> DAMMIT!

Now who's editorializing?

> PAY TRIBUTE

Reluctantly, you hand over the required tribute.
The Troll gives you a token so that you may pass
this way again.

Your wallet now contains $2500.

> GO VESA GENERAL TIMING FORMULA

There is a file here. The description says it
contains the algorithm for calculating sync timings
for any display mode.

> DOWNLOAD FILE

A copy of the file is now on your machine.

> READ FILE

There is no PDF reader here.

> TRANSFER FILE TO LAPTOP AND READ

After picking through some opaque language, you now
understand the VESA GTF.

> ADD VESA GTF CODE TO DRIVER AND TEST

You reboot the machine. The Flabloden 15ZF monitor
now works perfectly.

You have new mail.

> READ MAIL

You have 2 new message(s):

From: xf541ceuc8@aol.com
"MAKE.MONEY.FAST! Hi, my name is Dave Rhodes..."

> DELETE MESSAGE, NEXT MESSAGE

From: rjs@be.com
"We're going to need AGP support on the Yoyodyne
card so we can start on OpenGL acceleration. Can
you help with that?"

> READ DOCS ON AGP

Except for a few PCI configuration registers, there
is no mention of AGP in the docs.

> GO developer.intel.com

You are at Intel's developers' Web site.

There are many links here.

> FIND AGP DOCS

You find a single file named, "Accelerated Graphics
Port Interface Specification (v2.0)".

> DOWNLOAD FILE TO LAPTOP AND READ

AGP is an extension to PCI. Like a modern CPU's
MMU, AGP uses a translation table (called a GART) to
make disjoint blocks of system memory appear
contiguous. Both the graphics card and the
motherboard controller must be properly configured
for AGP to work. The layout and function of the PCI
AGP configuration registers are described only in
general terms. Most of the rest of the document
describes hardware implementation and signalling
details.

> EXAMINE MOTHERBOARD IN MACHINE

Your machine uses an Intel 440LX motherboard
controller.

> GO developer.intel.com

You are at Intel's developers' Web site.

There are many links here.

> FIND 440LX DOCS

You find a file named, "Intel 440LX AGPset: 82443LX
PCI AGP Controller (PAC) Datasheet"

> DOWNLOAD FILE TO LAPTOP AND READ

You now understand how to program the host's and
graphics card's AGP control registers.

> ADD CODE ENABLING AGP 1X MODE TO DRIVER AND TEST

You reboot the machine. Everything still works.

> ADD CODE ENABLING SIDEBAND ADDRESSING TO DRIVER AND TEST

You reboot the machine. Everything still works.

> ADD CODE ENABLING GART TO DRIVER AND TEST

You do not know how to create a GART.

> READ AGP DOCS ON GART

"The specific layout of the GART is
chipset-specific, and not documented here. GART
manipulation is done via a miniport driver or HAL
supplied with the chipset BIOS reference
implementation."

> READ 440LX DOCS ON GART

There is no description of the GART here.

> GO developer.intel.com

You are at Intel's developers' Web site.

There are many links here.

> FIND GART DOCS

There are no GART docs here.

> SEARCH FOR OTHER AGP RESOURCES

There is a link to the AGP Implementor's Forum, at
www.agpforum.org.

> GO www.agpforum.org

You are at the AGP Implementor's Forum Web site.

There are many links here.

> FIND GART DOCS

A Troll bars your way. He is demanding tribute.

> EVADE TROLL

Despite your best efforts, the Troll thwarts your
attempts to evade him.

> PAY TRIBUTE

Reluctantly, you hand over the required tribute.
The Troll gives you a token so that you may pass
this way again.

Your wallet is now empty.

> FIND GART DOCS

There are no GART docs here. The Troll laughs
uproariously.

> FIND ALL PROGRAMMING DOCS

You find a file named, "System Software."

> DOWNLOAD FILE TO LAPTOP AND READ

'ghostscript' reports: "This PDF file is encrypted
and cannot be processed."

> CRASH LAPTOP BACK TO WINDOWS

You close your XTerms, reboot the laptop, and in
mere minutes, Windows is ready.

> OPEN "SYSTEM SOFTWARE" DOCS

The PDF reader opens. This looks suspiciously like a
Powerpoint slide.

> SEARCH DOCS FOR "GART"

"GART manipulation is performed through the miniport
driver and DirectX 5 extensions..."

> CURSE

You heartily curse in a manner that comes only with
long practice. Co-workers pop up from their cubes
like prairie dogs.

> SCORE

Out of a possible 127 points, you have a total score
of 83 (65%).

> SAVE

Your adventure has been saved...

Last time I described how to access the configuration manager from the comfort of kernel space. Today I'll venture out into the uncharted regions of user space and show you how your applications can access this same information. Take my hand and follow my lead.

There's sample code to study; you can find it at <ftp://ftp.be.com/pub/samples/device_kit/listdev.zip>. As with last time, the relevant header file is <driver/config_manager.h>.

The /dev/misc/config device acts as the middleman between the configuration manager and user code. We've put together interface code that handles all the messiness for you. Rather than commit any energy to learning a one-shot interface, have faith and place your trust in these routines. Everything you need to know about this glue code can be divined from <cm_wrapper.h>.

The bulk of the first article concerned the mechanics of fetching information from the configuration manager. Rather than repeat myself, I'll spend time instead telling you how to make sense of this information.

The resource_descriptor is the basic unit of configuration information, describing an IRQ, DMA, I/O port, or memory used by a device. IRQs and DMAs are described by bitmasks, while I/O ports and memory are described by ranges. A line of source is worth a thousand words:

void print_mask(const char *name, resource_descriptor r)
{
  int i;
  for (i=0;i<32;i++)
    if (r.d.m.mask == (1 << i))
      break;
  if (i == 32) i = -1;

  printf("%s: %d\n", name, i);
}

void print_range(const char *name, resource_descriptor r)
{
  printf("%s: 0x%x - 0x%x\n", name, r.d.r.minbase,
    r.d.r.minbase + r.d.r.len - 1);
}

void print_resource_descriptor(resource_descriptor r)
{
  switch (r.type) {
    case B_IRQ_RESOURCE:
      print_mask("irq", r);
      break;
    case B_DMA_RESOURCE:
      print_mask("dma", r);
      break;
    case B_IO_PORT_RESOURCE:
      print_range("i/o ports", r);
      break;
    case B_MEMORY_RESOURCE:
      print_range("memory", r);
      break;
    default:
      printf("Unknown resource type (%d)\n", r.type);
      break;
  }
}

A device_configuration is an array of resource descriptors representing the resources assigned to the device. Behold:

void print_device_configuration(struct
  device_configuration *config)
{
  int i;
  for (i=0;inum_resources;i++)
    print_resource_descriptor(config->resources[i]);
}

The final structure of interest is possible_device_configurations, representing the space of configurations a device can take. It is an array of device_configurations, with each element representing a set of states the device can assume. Each resource_descriptor in a possible_device_configuration represents a set of possible values for a resource, rather than a single value, allowing for a compact description of possible resource configurations for a device.

Since a device_configuration is a variable-sized structure, you can't directly index the possible_device_configurations to obtain a given device_configuration. You have to be more clever, but only just. As you might expect:

void print_possible_device_configurations(struct
  possible_device_configurations *possible)
{
  #define NEXT_POSSIBLE(c) \
    (c) = (struct device_configuration *) \
    ((uchar *)(c) + \
    sizeof(struct device_configuration) + \
    (c)->num_resources * \
    sizeof(resource_descriptor))

  struct device configuration *config =
    possible->possible + 0;
  int i;
  for (i=0;i<possible->num_possible;i++) {
    print_device_configuration(config);
    NEXT_POSSIBLE(config);
  }
}

Each resource_descriptor in a possible_device_configurations may represent a set of possible resources, so the lower level functions will, sadly, need to be changed, leaving us with only the greasy middlemen, print_device_configuration and print_resource_descriptor, unchanged. Some parting words of advice:

void print_mask(const char *name, resource_descriptor r)
{
  bool first = true;
  int i;
  printf("%s: [", name);
  if (!r.d.m.mask)
    printf("none");
  for (i=0;i<32;i++)
    if (r.d.m.mask & (1 << i)) {
      printf("%s%d", first ? "" : ",", i);
      first = false;
    }
  printf("]\n");
}

void print_range(const char *name, resource_descriptor r)
{
  printf("%s: min %x max %x step %x length %x\n",
    name,
    r.d.r.minbase, r.d.r.maxbase,
    r.d.r.basealign, r.d.r.len);
}

"Developers' Workshop" is a weekly feature that provides answers to our developers' questions, or topic requests. To submit a question, visit

[http://www.be.com/developers/suggestion_box.html].

This week I present unto you all a Media Node, specifically a VariableTimeSource. The idea is simple: base your concept of time off another time source, but publish a time that is off by some multiple. For example, you could have a VariableTimeSource that ran at double or half the speed of some other time source. I'll use the node to go into some of the basics of managing a standard Media Node, and a BTimeSource in particular.

Managing a Node

As mentioned in past articles, a node author needs to take care of a good deal of node infrastructure. The main responsibilities are

• Allocation and release of a control port.
• Servicing that control port.
• Actual data processing.
• A system to queue at least one of each of the basic node messages: Start, Stop, and Seek.

The allocation and deletion of the control port is straightforward, and needs no explanation here. The system to queue service messages is also generally easy. The VariableTimeSource class contains a series of boolean flags and bigtime_t members that represent the service types and the time the action is supposed to take place.

/* from the class header */
bool fStarting = false;
bigtime_t fStartTime = 0;

void
VariableTimeSource::Start(bigtime_t real_time)
{
  fStarting = true;
  fStartTime = real_time;
}

When a start message comes in, the fStarting flag is set, and the time the start is to occur is set. Similar work is done in the Stop() and Seek() functions. This system allows the node to deal with one queued action of each type, which can be overwritten by a subsequent message of the same type.

The issue of thread management deserves a closer look. There are currently two main schools of Node design: the single and dual thread models. We're going to strongly recommend the single thread model, where a single thread manages the main work of the thread and of servicing the control port.

The main advantage of this system is that it uses fewer resources: usually a thread and a semaphore less than a dual thread model (which has a thread for servicing the control port and another for doing the real work).

In general, the single thread model has a thread function that looks like this:

void
VariableTimeSource::RunService()
{
  while (!fTimeToQuit) {

    /* collect timing information */
    /* potentially do some work */

    /* Handle a queued Start */
    if (!fRunning && fStarting) {

    }

    /* Handle a queued Stop */
    if (fRunning && fStopping) {

    }

    /* Handle a Seek */
    if (fSeeking) {

    }

    /* Do Some Work */
    if (fRunning) {

    }

    /* Look for incoming messages */
    read_port_etc();
    /* pass messages to superclasses */
  }
}

In the destructor, the fTimeToQuit flag is set true, and you wait for the thread to return before finishing the clean-up (including the deletion of the control port).

The logic of the thread is to determine what time it is, handle any queued event whose time has arrived (or will arrive very shortly), handle the data processing that needs to be done by that point in time, and then block in read_port_etc() until it's time to handle the next event, or until a message comes in that needs to be handled. The idea is to establish the largest timeout possible while still managing to handle events and do work in a timely fashion. As your main service thread will likely be fairly high priority, you need to block when you don't want to run. The read_port_etc() call has the dual purpose of servicing the control port and acting as a timer for the thread activity.

A Responsible TimeSource

Looking specifically at a BTimeSource, the main work that needs to be done is publishing its concept of time to the world. This is handled through the appropriately named PublishTime() function, which establishes a relationship between performance time (as seen by the time source) and real time (as seen by the system clock). It presents a known performance time for a given real time, and a drift that describes the rate at which these two times differ. As time is only published periodically (but at least 20 times a second), the drift is used to approximate the performance time for a given real time (and vice versa). The GetTime() function returns the information from the last call to PublishTime(), and functions like PerformanceTimeFor(), RealTimeFor(), and Now() use that last published time to return the correct approximation.

Time sources publish their time in microseconds, and the vast majority have a drift centered around 1.0. This means time passes at roughly the same speed as it does for the system clock, although it may be at some offset if the time source was started later than the system clock (as is likely). The drift of the time source will likely change somewhat as time goes on, perhaps fluctuating over and around the 1.0 center.

It's important to understand this concept of drift before looking at a VariableTimeSource's concept of a rate. For a VariableTimeSource, time passes at some multiple of another time source's concept of time. This rate is fixed (at least until someone specifically changes it). A rate of 2.0 means that time passes for the VariableTimeSource twice as fast as the time source it's slaved to. Correspondingly, a rate of .25 means time passes four times as slowly as the master's time. The drift that the VariableTimeSource needs to publish is not fixed, however; it is the product of the Master drift and the internal rate. For example, if a VariableTimeSource with a rate of 2.0 is slaved to a master with a current drift of .9, the published drift of the VTS would be 1.8.

The master of a VariableTimeSource is set like that of any other node, through the SetTimeSource() function. It is created with a default rate, which can be examined through the Rate() function, and changed through the SetRate() function. The published drift can be examined in the same manner as any other BTimeSource, through the GetTime() function. (As an aside, you can slave one VTS to another, and everything works fine.)

Another useful function is SyncToMaster(). If called before the VariableTimeSource has been started, it makes sure that the first published time matches the performance time of the master time source when the VTS starts. Any time afterwards, it causes the time source to conform to the last published performance time of the master. This is implemented in terms of a Seek() operation to the appropriate master time.

I'm sure you'll find plenty of uses for the VariableTimeSource. Some of the potential uses we've discovered internally include: running a node without B_OFFLINE capabilities at higher speeds to decrease export time to a file; having a node run considerably slower so that debug information can be viewed as it changed; and slaving a VTS to a sound card's time source so it can stop, start, and seek without affecting other applications.

You'll see improvements in the VariableTimeSource in the future, including the implementation of the BControllable interface so the rate can be changed from other applications. I've also been threatened with the possibility that it will become an official Media Kit class at some point in the future.

In any case, take a look at the class and the supporting application so you can see it in action. If you find bugs or have questions, send them in and I'll try to answer them. You can find the sample project at:

And remember to register for the upcoming BeDC so that you can learn more about the Media Kit and its many wonders:

You're the CEO of a PC OEM, delivering some great news to Wall Street: "In an effort to offer greater variety and performance to the customer, our factory now installs three operating systems on the hard disk -- Windows, Linux, and the BeOS. The reaction has been spectacular. Customers love having a choice of OS, and the press -- from John Dvorak in PC Magazine to John Markoff in the New York Times to Walt Mossberg in the Wall Street Journal -- has heralded us for our bold move. This is a great step forward for the consumer and for the industry. Oh, and by the way, we lost $50 million since we no longer qualify for Windows rebates. But it's a sacrifice for the common good."

You're now the ex-CEO of a PC OEM.

We know that the Windows rebate scheme exists -- but what *is* it, exactly? And why are so many OEMs afraid of losing it? Windows pricing practices are closely guarded secrets, so we don't know exactly how the rebate is structured, but we can assume that it works something like this: The total cost of a Windows license consists of a base price offset by a rebate. The base price is set; the rebate is flexible, and contingent on the "dedication" of the licensee. That is, the more you "advertise" the product -- through prominent positioning, expanded shelf space, and so on -- the greater your rebate. This quid pro quo rebate looks innocent enough, and can be a useful tool in a competitive market.

But when you're running a monopoly -- and when it comes to out-of-the-box, consumer-grade PC clones, Microsoft *is* a monopoly -- "prominent positioning" and "expanded shelf space" have little meaning. Microsoft has no interest in getting "more" footage on the OS shelf, because they've already got it all. What interests them -- the only useful advantage they can "buy" (to be kind) with their rebate -- is to ensure that no one else will get any.

So how is "dedication" measured? A real-life example: We've been working with a PC OEM that graciously -- and bravely -- decided to load the BeOS on certain configurations in its product line. However, there's a twist in their definition of "loading." When the customer takes the machine home and starts it up for the first time, the Microsoft boot manager appears -- but the BeOS is nowhere in sight. It seems the OEM interpreted Microsoft's licensing provisions to mean that the boot manager could not be modified to display non-Microsoft systems. Furthermore, the icon for the BeOS launcher -- a program that lets the user shut down Windows and launch the BeOS -- doesn't appear on the Windows desktop; again, the license agreement prohibits the display of "unapproved" icons. To boot the "loaded" BeOS, the customer must read the documentation, fish a floppy from the box and finish the installation. Clever.

One suspects that Linux suffers from the same fealty to Microsoft's licensing strictures. Linux is the culmination of 30 years of development by the Unix community. Surely an OEM can't complain about Linux's quality or its price: It's good, and it's free. If Microsoft licensees are as free to choose as Microsoft claims they are, why isn't Linux factory installed on *any* PC? If you randomly purchase 1,000 PC clones, how many have any OS other than Windows loaded at the factory? Zero.

But what about all these announcements from companies such as IBM, Dell, and others? A few URLs are supplied here for your convenience:

<http://www.dell.com/products/workstat/ISV/linux.htm>
<http://www.compaq.com/isp/news_events/index.html>
<http://www.compaq.com/newsroom/pr/1998/wa111298a.html>
<http://www.hp.com/pressrel/jan99/27jan99.htm>
<http://www.hp.com/pressrel/jan99/27jan99b.htm>
<http://www.software.ibm.com/data/db2/linux/>

If you parse the statements, Linux is offered and supported on servers, not on PCs. Another IBM story is that installation is to be performed by the reseller on some PCs or laptops, not by IBM at the factory.

As an industry insider gently explained to me, Microsoft abides by a very simple principle: No cracks in the wall. Otherwise, water will seep in and sooner or later the masonry will crumble.

Guarding against even the smallest crack is important to Microsoft, because it prevents a competitor from taking advantage of a phenomenon that economists call the "network effect." The "network effect" manifests itself as an exponential increase in the value of a product or service when more people use it. Applied to a computer operating system, the effect works like this: As more people install and use an OS, the demand for applications increases. Developers respond to the demand, which attracts the attention of OEMs and resellers, who promote the OS in order to sell the apps, which attracts more customers... The key to all this is distribution and visibility -- in other words, "shelf space."

Bill Gates understands the network effect well -- he once quoted it to me, chapter and verse. In the Fall of 1983, when I was still running Apple France, I met with Bill in Paris and we got into a conversation regarding the market share limitations of DOS. No problem, he said, with the wide distribution we enjoy, we'll get the attention of third parties, and the marketplace will fix these shortcomings.

This puts statements by senior Microsoft executive Paul Maritz in perspective. In reaction to my claim that Be wants to co-exist with Microsoft, Mr. Maritz said (as quoted by Joseph Nocera in Fortune Magazine):

  "[Gassee is] articulating his strategy for entry into the
  operating system marketplace. But on the other hand, I
  know that Be has built a full-featured operating system,
  so what I believe he's doing here is outlining his
  strategy about how he will initially co-exist with Windows
  and, over time, attract more applications to his
  platform."

Mr. Nocera interpreted Mr. Maritz's interpretation thus:

  "In other words, Gassee's spiel is little more than a
  trick intended to lull Microsoft. But Microsoft isn't so
  easily fooled! Microsoft will never ignore a potential
  threat to its Windows fortress, no matter how slight. The
  software giant may be in the middle of an antitrust trial,
  but -- as Andy Grove says -- only the paranoid survive..."

[The entire article, part of a court house diary, can be found
at <http://www.pathfinder.com/fortune/1999/03/01/mic3.html>.]

Industry sages such as T.J. Rodgers, the CEO of Cypress Semiconductors, as well as venture capitalists aligned with Microsoft, criticize the Department of Justice's intervention in the new Pax Romana we're supposed to enjoy under Microsoft's tutelage. Don't compete in court, compete in the marketplace, they say.

I'm a free marketer myself; I left a statist environment for the level playing field created by the rule of law in this, my adopted country. A free market is *exactly* what we want. One where a PC OEM isn't threatened by financial death for daring to offer operating systems that compete with the Windows monopoly.

We started with a thought experiment. We end with a real-life offer for any PC OEM that's willing to challenge the monopoly: Load the BeOS on the hard disk so the user can see it when the computer is first booted, and the license is free. Help us put a crack in the wall.