|
 |


Table of Contents
BE ENGINEERING INSIGHTS: Adventures in Graphics Drivers
By Leo Schwab - ewhac@be.com
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...
BE ENGINEERING INSIGHTS: The Configuration Manager, Part II (Back into the fold)
By Victor Tsou - vyt@be.com
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: Time isn't Relative, its Variable
By Stephen Beaulieu - hippo@be.com
"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:
<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/>
A Crack in the Wall
By Jean-Louis Gassée
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.
Recent Be Newsletters |
1998 Be Newsletters
1997 Be Newsletters |
1995 & 1996 Be Newsletters
Copyright ©1999 Be, Inc. Be is a registered trademark, and BeOS, BeBox, BeWare, GeekPort, the Be logo and the BeOS logo are trademarks of Be, Inc. All other trademarks mentioned are the property of their respective owners.
|