Holy cow, I wrote a book!
Corporate policies for acquiring hardware
typically require going through a bunch
of procedures, like issuing purchase orders, getting appropriate
approvals, all the usual red tape with the purpose of preventing fraud.
But the Windows 95 project was so notoriously behind schedule
that upper management removed some procedural roadblocks.
To expedite the acquisition of hardware for members of the development
team, the administrative assistant for the core development team
was issued a corporate credit card with a credit limit of $500,000.
what $500,000 in 1994 dollars
corresponds to in today's money.)
I assume the theory here was "buy first, fill out paperwork later."
"It's kind of weird having a credit card in your pocket that you could
buy a house with."
The nickname doesn't get used much at all any more,
but back in the day,
the Windows source code trunk was called the Blue Line.
Where did it get that name?
the color of the whiteboard pen.
the branching structure was worked out,
the trunk was drawn with a blue pen.
If you were in that meeting, and you wanted to raise a point about
the diagram, you might say,
"But when the red line meets the blue line…",
"How do changes get from the green line to the blue line?"
Everybody called the trunk the "blue line" in the meeting,
and that nickname carried forward into the internal documentation.
Of course, if you weren't at that meeting,
it was a giant mystery why
the trunk was called the Blue Line.
A mystery that has now been resolved,
long after everybody stopped using that nickname.
Commenter BAA says that
the -lett part of Marlett comes from the designer Virginia Howlett.
BAA adds, "I forget the 'Mar' but I believe it was a co-creator."
If so, then that co-creator was Suzan Marashi,
Vincent Connare is to be trusted.
On page 17 of the PDF document
From The Dark Side...,
Connare identifies the authors of the font as
Virginia Howlett, Rom Impas, Suzan Marashi, and Alison Grauman-Barnes.
He also identifies Eliyezer Kohen as the person whose idea it was
to use a special-purpose font.
According to Virginia Howlett,
the original name for the font Verdana was
which means window in Spanish.
Lawyers apparently objected to the name,
and the font team explored variations on
verde (which means green in Spanish)
verdigris (a green pigment),
thereby invoking the color associated both with Washington
(The Evergreen State)
(The Emerald City).
The second part of the font name comes from Howlett's granddaughter Ana,
following in the tradition of font designers naming fonts after their
Many years ago, I visited the office of a colleague
who worked on Internet Explorer in order to work on some problem
As we investigated the issue,
we took notes on a 5"×7" tear-off notepad which bore the logo
My colleague then pointed out to me that we were taking notes on
the most expensive notepads in Microsoft history.
was the code name for the project that was the precursor to
the layout engine that powers Internet Explorer.
As I recall the story as it was told to me,
project management thought it would be cool to have custom
notepads made for their project.
The people responsible for converting this idea into reality
designed a logo, laid it out, and found a vendor to produce the notepads.
But there was some sort of misunderstanding
(maybe the asked for too many colors? didn't order enough notepads
to trigger the bulk discount?),
and the price for the notepads ended up being something ridiculous
like $10 for a 50-page notepad.
That's how the most expensive notepads in Microsoft history came to be.
Oh, by the way, the word "precursor" I used up there?
Yeah, that was a euphemism for
"cancelled (but used as a learning opportunity)."
Microsoft engineers are fond of black humor when it comes to software
(especially software made by Microsoft) as a way of coping with adversity,
and after the Forms³ project was cancelled,
there was a subculture of engineers who morbidly called it
Project code names are not arrived at by teams of focus groups
who carefully parse out every semantic and etymological nuance
of the name they choose.
(Though if you read the technology press,
you'd believe otherwise,
because it turns out that taking a code name apart syllable-by-syllable
searching for meaning is a great way to fill column-inches.)
Usually, they are just spontaneous decisions,
inspired by whatever random thoughts jump to mind.
Many years ago, there was an internal user interface research project
code named RedShark.
Not Red Shark but RedShark,
accent on the Red.
Where did this strange name come from?
From a red shark, of course.
When the project started up, the people in charge were sitting around
and realized they needed to give the project a name.
It so happened that the office they were sitting in belonged to a team
member who collected a lot of strange toys.
One of those toys was an small inflatable red shark.
Somebody looked around the room and spotted the red shark.
"Let's call it RedShark."
Nobody else had a better idea, so the name passed by default.
That small inflatable red shark became their mascot and
hung from the ceiling in the hallway.
No deep, hidden meaning.
Just a $3 cheap plastic toy
that happened to be in the right place at the right time.
Registration for //build/ 2013 opens tomorrow.
I have no idea what's in store this year,
but I figure I'd whet your appetite by sharing
additional useless information
about //build/ 2011.
The internal code name for the prototype tablets handed out
at //build/ 2011 was Nike.
I think we did a good job of keeping the code name from public view,
but one person messed up and
accidentally let it slip to Mary-Jo Foley
when they said that
the contact email for people having tax problems related to the device is
The advance crew spent an entire week
preparing those devices.
One of the first steps was
unloading the devices from the pallettes.
This was done in a disassembly line:
The boxes were opened, the devices were fished out,
then removed from the protective sleeve.
At the end of this phase, you had
one neat stack of boxes and one neat stack of devices.
The advance crew also configured the hall so they would be ready
to start once Redmond sent down the final
bits of the Developer Preview build.
The hall was divided into sections, and each section consisted
of eight long tables.
Four of the tables were arranged in a square,
and the other four tables were placed outside the square, one parallel to each side,
forming four lanes.
Along the inner tables, there were docking stations,
with power, wired access to a private network, and a USB thumb drive.
Along the outer tables, there were desk organizers
like this one,
ready to hold several devices in a vertical position,
and next to the organizer was a power strip with power cables
at the ready.
In this phase of the preparation, the person working the station
would take a device, pop it into a docking station,
and power it on with the
magic sequence to boot from USB.
The USB stick copied itself to a RAM drive,
then ran scripts to reformat the hard drive
and copy all the setup files from the private network
onto the hard drive,
then it installed the build onto the machine,
installed Visual Studio,
installed the sample applications,
flashed the firmware,
and otherwise prepared the machine for unboxing.
(Not necessarily in that order; I didn't write the scripts,
so I don't know what they did exactly.
But I figure these were the basic steps.)
Once the setup files were copied from the private
network, the rest of the installation could proceed
It didn't need any further access to the USB stick or the network.
Everything it needed was on the RAM drive or the hard drive.
The scripts changed the screen color based on what step of the
process it was in, so that the person working the station could
glance over all the devices to see which ones needed attention.
Once all the files were copied from the network,
the devices were unplugged from the docking station and
moved to the vertical desk organizer.
There, it got hooked up with a power cable and left to
finish the installation.
Moving the device to the second table freed up the docking station
to accept another device.
Assuming everything went well,
the screen turned green to indicate that installation was complete,
and the device was unplugged, powered down, and placed in
the stack of devices that were ready for quality control.
The devices that passed quality control then needed to be boxed up
so they could be handed out to the conference attendees.
Another assembly line formed:
The devices were placed back in the protective sleeves,
nestled snugly in their boxes,
and the boxes closed back up.
Now, I'm describing this all as if everything ran perfectly smoothly.
Of course there were problems which arose,
some minor and some serious,
and the process got tweaked as the days progressed in order to make
things more efficient or to address a problem that was discovered.
For example, the devices were labeled preview devices,
but shortly before the conference was set to begin,
the manufacturer registered their objection to the term,
since preview implies that the device will actually
turn into a retail product.
They insisted that the devices be called prototype devices.
This meant that mere days before the conference opened,
a rush print job of 5000 stickers had to be shipped down
to the convention center in order to cover the word preview
with the word prototype.
A new step was added to the assembly line:
place sticker over offending word.
Another example of problem-solving on the fly:
The SIM chip
for the wireless data plan was preinstalled in the device.
The chip came on a punch-out card, and the manufacturer decided to
leave the card shell in the box.
Okay, I guess,
except that the card shell had the SIM card's account number printed on it.
Since the reassembly process didn't match up the devices with the original
boxes, you had all these devices with unmatched card shells.
somebody might call the service provider and give the account number
on the shell rather than the number on the SIM card.
To fix this, a new step was added to the assembly line: Remove the card
All the previously-assembled boxes had to be unpacked
so the shells could be removed.
(At some point, somebody discovered that you could extract the shells
without removing the foam padding if you
held the box at just the right angle and shook it,
so that saved a few seconds.)
Now about the devices themselves:
They were a very limited run of custom hardware,
and they were not cheap.
I think the manufacturing cost was in the high $2000s per unit,
and that doesn't count all the sunk costs.
I found it amusing when people wrote,
"What do you mean a free tablet?
Obviously they baked that into the cost of the conference registration,
so you paid for it anyway."
Conference registeration was $2,095 (or $1,595 if you registered early),
which nowhere near covered the cost of the device.
Some people whined that
Microsoft should have made these devices available to the
general public for purchase.
First of all, these are developer prototypes,
not consumer-quality devices.
They are suitable for developing
Windows 8 software
but aren't ready for prime time.
(For one thing, they run hot. More on that later.)
Second of all, there aren't any to sell.
We gave them all away!
It's not like there's a factory
sitting there waiting for orders.
It was a one-shot production run.
When they ran out, they ran out.¹
Third, these devices,
by virtue of being prototypes,
had a high infant morality rate.
I don't know exactly, but I'm guessing that maybe a quarter
of them ended up not being viable.
One of the things that the advance crew had to do was
the devices to try to catch the dead devices.
I remember the team being very worried that the hardware helpdesk
at the conference would be overwhelmed by machines that slipped
through the on-site testing.
Luckily, that didn't happen.
(Perhaps they were too successful,
because everybody ended up assuming
that pumping out these puppies was a piece of cake!)
Doing a little back-of-the-envelope calculations,
let's say that the machines cost around $2,750 to produce,
and that a quarter of them failed burn-in.
Add on top of that a 25% buffer for administrative overhead,
and you're looking at a cost-per-device of over $4,500.
I doubt there would be many people interested in buying one
at that price.
Especially since you could
buy something very similar for around $1100 to $1400.
It won't have the hardware customizations, but it'll be close.
The hardware glitches that occurred during the keynote
never appeared during rehearsals in Redmond.
But when rehearing in Anaheim, the hardware started
flaking out like crazy and eventually self-destructing.
(And like I said, those devices weren't cheap!)
One of my colleagues got a call from Los Angeles:
"When you come down here, bring as many extra Nikes as you can.
We're burning through them like mad!"
My colleague ended up pissing off everybody in the airport
security line behind her when she got to the X-ray machine
and unloaded nine devices onto the conveyer belt.
"Great, I just put tens of thousands of dollars worth of
top-secret hardware on an airport X-ray machine.
I hope nothing happens to them."
Why did the devices start failing during rehearsals
when the ran just fine in Redmond?
Because in Anaheim,
the devices were being run at full brightness all the time
(so they show up better on camera),
and they were driving giant video displays,
and they were sitting under hot stage lights for hours on end.
On top of that,
I'm told that the HDMI protocol is bi-directional,
so it's possible that
the giant video displays at the convention center
were feeding data back into the devices in a way that they
Put all that together, and you can see why the devices
would start overheating.
What made it worse was that in order to cram all the extra
doodads and sensors into the device,
the intestines had to be rearranged,
and the touch processor chip ended up being placed
directly over the HDMI processor chip.
That meant that when the HDMI chip overheated,
it caused the touch processor to overheat, too.
If you watched the keynote carefully,
you'd see that shortly before the machine
on stage blew up,
you saw the touch sensor flip out and generate phantom
touches all over the screen.
That was the clue that the machine was about to die from overheating
and it would be in the presenter's best interest to switch
to another machine quickly.
(The problem, of course, is that the presenter is looking out into
the audience giving the talk,
not staring at the device's screen the whole time.
As a result, this helpful early warning signal typically goes
unnoticed by the very person who can do the most about it.)
The day before the conference officially began,
Jensen Harris did a preview presentation to the media.
One of the glitches that hit during his presentation was that
the system started hallucinating an invisible hand that kept
swiping the Word Hunt sample game back onto the screen.
"This is our new auto-Word Hunt feature.
We want to make sure you always have Word Hunt when you need it.
We've moved beyond touch.
Now you don't even need to touch your PC
to get access to Word Hunt."
Jensen's phenomenal calm in the face of adversity
also manifested itself during his keynote presentation.
You in the audience never noticed it,
but at one point,
one of the demo applications hit a bug and hung.
Jensen spotted the problem before it became obvious and smoothly
transitioned to another device and continued.
while he was talking,
he went back to the first device
and surreptitiously called up Task Manager,
killed the the hung application,
and prepared the device for the next demo.
All this without skipping a beat.
We are all in awe of Jensen.
When he stopped by the booth,
Jensen said to me,
"I don't know how you can stand it, Raymond.
Now I can't walk down the hallway without a dozen people
coming up to me and wanting to say something or shake my hand
or get my autograph!"
(One of the rare times we are
both in the same room.)
Welcome to nerd celebrity, Jensen.
You just have to smile and be polite.
¹ My group had one of these scuffed-up devices that we used for
Somebody dropped it, and a huge spiderweb crack covered the
left third of the screen,
so you had to squint to see what was on the screen through
We couldn't order a replacement because
there was nowhere to order replacements from.
We just had to continue testing with a device that had
a badly cracked screen.
If you look in your
you'll find a MIDI file called
What's the story behind this odd little MIDI file?
considers this file a security risk because
"if an attacker can cause that file to be played,
it will cause lasting mental pain and anguish
to everybody within earshot."
Despite Wikipedia's claims,
the file is not an Easter Egg.
The file was added in in Windows XP
with the comment
"Add cool MIDI files to replace bad old ones."
So as bad as onestop is,
the old ones must have been even worse!
Okay, but why were they added?
For product support.
The product support team wants at least one MIDI file
present on the system by default for troubleshooting
That way, problems with MIDI playback can be diagnosed
without making the customer go to a Web page and download
a MIDI file.
When asked why the song is so awful,
the developer who added the file explained,
"Believe it or not, OneStop is 'less bad' than the ones
that it replaced.
(Dance of the Sugar Plum Fairy, etc.)"
Another reason for replacing the old MIDI file
is that the new one exercises more instruments.
The song was composed by
On the other hand,
Enhanced-mode Windows 3.0 ran a copy of standard-mode
Windows inside the virtual machine.
This statement isn't exactly true,
it's true enough.
"Why are you threatening us with the Nitpicker's Corner for
asking about this issue
instead of explaining it once and linking it everywhere?"
Okay, first of all,
as far as I can tell,
you're the first person to ask about the issue.
So you can't say
"Everybody who asks about the issue is threatened with the Nitpicker's
because up until you made your comment,
nobody ever asked.
Okay, well, technically you can say it,
because every statement quantified over the empty set is true.
But it is equally true that,
at the time you made your comment, that
"Everybody who asks about the issue is awarded a new car."
So it is not a meaningfully true statement.
I haven't bothered explaining the issue because the issue
has never been central to the main point of whatever article
happens to bring it up.
The statement is true enough for the purpose of discussion,
and the various little corners in which the statement breaks down
have no bearing on the original topic.
Nitpickers would point out that you can't combine velocities
by simple addition
because of the laws of Special Relativity.
Even when the situation under discussion takes place
at non-relativistic speeds.
As for the suggestion,
"Explain it once and link it everywhere,"
you're assuming that I can even explain it once,
that doing so is less work than just saying
"not exactly true, but true enough,"
and that I would enjoy explaining it in the first place.
If you don't like it, you can ask for your money back.
Okay, I went back and dug through the old Windows 3.0
source code to answer this question.
It took me about four hours to study it all,
try to understand what the code was doing,
and then distill the conclusions into this article.
Writing up the results took another two hours.
That's six hours I could've spent doing something enjoyable.
The 16-bit Windows kernel was actually three kernels.
One if you were using an 8086 processor,
another if you were using an 80286 processor,
and a third if you were using an 80386 processor.
The 8086 kernel was a completely separate beast,
but the 80286 and 80386 kernels shared a lot of code in common.
The major difference between the 80286 and 80386 kernels was
in how they managed memory,
because the descriptor tables on the 80386 were a different
format from the descriptor tables on the 80286.
The 80386 memory manager could also take advantage of the new
But the difference between the 80286 and 80386 kernels were not
based on whether you were running Standard or Enhanced mode.
If you're running on an 80386 processor, then you get
the 80386 kernel, regardless of whether you're using
Standard or Enhanced mode Windows.
And since Enhanced mode Windows required an 80386 processor,
the behavioral changes between Standard and Enhanced mode
were restricted to the 80386 kernel.
The 80386 kernel was designed to run as a DPMI client.
It asked the DPMI host to take it into protected mode,
then used the DPMI interface to do things like allocate
selectors and allocate memory.
If you ran Windows in Standard mode,
then the DPMI host was a custom-built DOS extender that
was created just for
Standard mode Windows.
If you ran Windows in Enhanced mode,
then the DPMI host was the 32-bit virtual machine manager.
Abstracting to the DPMI interface
allowed a single 80386 kernel to run in both Standard
and Enhanced modes.
And in fact if you ran Enhanced mode Windows
with paging disabled,
then the code running in the 80386 kernel was pretty much
the same code that ran if you had run the 80386 kernel
under Standard mode Windows.
One obvious place where the behavior changed was in the
code to manage MS-DOS applications,
because Enhanced mode Windows could multi-task MS-DOS applications,
and Standard mode Windows could not.
Another place where the behavior changed was in
in the code to allocate more selectors:
The attempt to retry after
extending the local descriptor table was skipped if
you were running under the Standard mode DOS extender,
because the Standard mode DOS extender didn't support
extending the local descriptor table.
And another difference is that the Windows idle loop
in Enhanced mode would issue a special call to release
its time slice to any multi-tasking MS-DOS applications.
(If you were running in Standard mode, there were no
multi-tasking MS-DOS applications,
so there was nobody to release your time slice to.)
Another thing special that the 80386 kernel did was
register with the virtual machine manager so that it
could display an appropriate message when you pressed
For example, you saw this message if you hit
while there was a hung Windows application:
But all these differences are minor in the grand
scheme of things.
The window manager behaved the same in Standard mode
and Enhanced mode.
GDI behaved the same in Standard mode
and Enhanced mode.
Printer drivers behaved the same in Standard mode
and Enhanced mode.
Only the low-level kernel bits had to change behavior
between Standard mode and Enhanced mode,
and as you can see,
even those behavior changes were relatively minor.
That's why I said it was "true enough" that what was running
inside the virtual machine was a copy of Standard-mode Windows.
some time ago
that the nominal mouse wheel amount for
one click (known as a "detent")
is specified by the constant
which has the value 120.
Why not a much more convenient number like 100, or even 10?
Because the value 120 made it easier to create
higher-resolution mouse wheels.
noted in the documentation:
The delta was set to 120 to allow Microsoft or other vendors
to build finer-resolution wheels
(a freely-rotating wheel with no notches)
to send more messages per rotation,
but with a smaller value in each message.
Suppose the original wheel mouse had nine clicks
around its circumference.
Click nine times, and you've made a full revolution.
(I have no idea how many actual clicks there were,
but the actual number doesn't matter.)
Therefore, each click of the wheel on the original mouse
resulted in 120 wheel units.
Now, suppose you wanted to build a double-resolution wheel,
say one with eighteen clicks around the circumference
instead of just nine.
If you reported 120 wheel units for each click,
then your mouse would feel "slippery",
because it scrolled twice as fast as the original mouse.
Have each click of your double-resolution mouse report
60 wheel units instead of 120.
That's why the number chosen was 120.
The number 120 has a lot more useful factors than 100.
The number 100 = 2² × 5²
can be evenly divided by the small integers 2, 4, 5, and 10.
On the other hand, the number 120 = 2³ × 3 × 5
can be evenly divided
by 2, 3, 4, 5, 6, 8, and 10.
On the other hand, if MOUSE_WHEEL were 120,
then the triple-resolution mouse could simply report 40 units per
Okay, so why 120 instead of just 12?
As noted in the documentation,
the value was chosen so that it would be possible to
build a mouse with no clicks at all.
The wheel simply spun smoothly,
and you could stop it at any point.
Such a wheel would report one wheel unit for every
one-third of one degree of rotation.
If the detent were only 12 units,
then the wheel would report one unit for every 3 1/3
degrees of rotation,
which wouldn't be as smooth.
I don't know if anybody has developed such a mouse,
but at least the possibility is still there.
(There are free-spinning mouse wheels, but I don't know
whether they are normal WHEEL_DELTA
wheels just without the mechanical detents,
or whether they really do report fine rotational information.)
The History of the Scroll Wheel,
written by its inventor,
Mouse wheel trivia:
The code name for the mouse wheel project was Magellan.
The code name still lingers in
that pop up from the original wheel mouse driver.
has a long and troubled history.
The first bit of confusion is that the day it was introduced
in Windows NT 3.1, it was exported funny.
The UNICODE version was exported under the name
but the ANSI version was exported under the name
without the usual A suffix.
A mistake we have been living with for over two decades.
This is why the winbase.h header file
contains these confusing lines:
#define GetEnvironmentStrings GetEnvironmentStringsW
#define GetEnvironmentStringsA GetEnvironmentStrings
#endif // !UNICODE
It's trying to clean up a mess that was created long ago,
and it only partly succeeds.
This is why your IDE may get confused when you try to call
and send you to the wrong definition.
It's having trouble untangling the macros whose job is to
try to untangle the original mistake.
The kernel folks tried to clean this up as quickly as they could,
by exporting new functions with the names
like they should have been in the first place,
but for compatibility purposes, they still have to export the weird
And then to avoid all the "gotcha!"s from people
looking for proof of nefarious intent,
they kept the mistake in the public header files
to make their actions visible to all.
Though personally, I would have tidied things up differently:
#define GetEnvironmentStrings GetEnvironmentStringsW
#define GetEnvironmentStrings GetEnvironmentStringsA
#endif // !UNICODE
I would have left the declaration of the mistaken
in the header file, but redirected the symbolic name
to the preferred suffixed version.
But then again, maybe my version would have confused IDEs
even more than the current mechanism does.
The other unfortunate note in the history of the
is the odd way it handled the Unicode environment.
Back in the old days,
the GetEnvironmentStrings function
returned a raw pointer to the environment block.
The result was that if some other code modified the environment,
your pointer became invalid,
and there was nothing you could do about it.
As I noted, the function was subsequently changed so that
both the ANSI and Unicode versions return snapshots
of the environment strings,
so that the environment strings you received wouldn't get
spontaneously corrupted by another thread.