Be Newsletters - Volume 4: 1999
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
> 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:
voidprint_mask(const char *name, resource_descriptorr) { inti; 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); } voidprint_range(const char *name, resource_descriptorr) {printf("%s: 0x%x - 0x%x\n", name,r.d.r.minbase,r.d.r.minbase+r.d.r.len- 1); } voidprint_resource_descriptor(resource_descriptorr) { switch (r.type) { caseB_IRQ_RESOURCE:print_mask("irq",r); break; caseB_DMA_RESOURCE:print_mask("dma",r); break; caseB_IO_PORT_RESOURCE:print_range("i/o ports",r); break; caseB_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:
voidprint_device_configuration(struct device_configuration *config) { inti; for (i=0;i<num_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:
voidprint_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; inti; 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:
voidprint_mask(const char *name, resource_descriptorr) { boolfirst=true; inti;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"); } voidprint_range(const char *name, resource_descriptorr) {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); }
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.
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 */ boolfStarting=false; bigtime_tfStartTime= 0; voidVariableTimeSource::Start(bigtime_treal_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:
voidVariableTimeSource::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.
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: <ftp://ftp.be.com/pub/samples/media_kit/VariableTimeSource.zip>
And remember to register for the upcoming BeDC so that you can learn more about the Media Kit and its many wonders:
http://www.be.com/developers/developer_conference/
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.
