Last month I happened to run into a former member of the shell team
who worked on the Windows XP Welcome screen.
He told me a story from CES 2001,
where Windows XP's interface (code-named Luna) was unveiled.
There was going to be a segment on the
Today show, and the
Welcome screen was going to make an appearance,
but the designers wanted to make one last tweak before it
showed up on national television.

Two hours before air time.

So with a hard deadline of two hours,
my colleague connected back to the computer at the office,
made the requested changes, compiled a new binary,
transferred it back to Las Vegas,
installed it onto a laptop, and handed it over
to the production crew.
Everybody crossed their fingers.

I first heard
Ofeibea Quist-Arcton
when she reported for the BBC.
Now she's on NPR
(you can listen to her discuss
corruption in Nigeria in this recent report),
thereby wresting the title of
"most mellifluous NPR reporter name" from its previous holder,
Sylvia Poggioli.
(Sylvia Poggioli's dirty secret: She was born
and grew up in the United States!)

Windows XP shipped with new icons for many common items in the
shell, and Windows Vista will have even more and newer icons.
One of the things the designers have to be careful about with
drawing these icons is to make sure they don't actually look like
anything.
Let me clarify.

The folder icon, for example, is not based on any actual physical
folder you can buy in the store.
If it were a rendition of an actual folder,
Windows would become vulnerable to a copyright infringement
charge from the manufacturers of that folder.
Instead, the manila folder icon is just something the designers
made up from their fertile imagination.

As another example, Windows XP came with new icons for
the drives in your My Computer folder.
One company complained that the icon for removable mass storage
devices too closely resembled the drive manufactured by their
competitor.
The designers had to go back and draft a new icon that looked
even less like any actual drives out on the market, yet which
users would still recognize as a removal mass storage device.

I'm sure every discipline has its share of crackpots.
I suspect the physicists get it the worst,
starting with the old standbys of
perpetual motion machines and faster-than-light travel,
then tossing in quantum mechanics and nuclear physics, and stirring with
large quantities of long rambling text that makes no sense.
But my experience is with mathematics.

When I was in college, the mathematics department
would post
"interesting letters"
onto the bulletin board.
The ones I remember:

A claimed proof of Fermat's Last Theorem by means of music theory.
It started with 3² + 4² = 5²,
then somehow converted this into musical notation,
transposed it into another key,
and then concluded that the proof was complete.
There were many "proofs" of Fermat's Last Theorem on the bulletin board.

A letter from an inmate at a correctional facility who had
developed a system for winning the lottery and merely needed
a printout of all possible ways of choosing 6 numbers from
a pool of 46.

A number theorist working on factorization
explained to me that he would frequently receive "manuscripts"
from people who claim to have found a high-speed algorithm for
factoring large numbers.
At first, he would take the time to study these manuscripts,
and each time he would
determine that the algorithm boiled down to trial division,
often cleverly-disguised trial division, but trial division nevertheless.
(Though when this was pointed out, the authors often rejected
his analysis.)
Eventually, he realized that he could separate the wheat from the
chaff very easily by simply replying with the following message:

Thank you for your fascinating manuscript on the factorization
of large numbers.
There are some numbers that have been giving me difficulty
of late.
I would be most appreciative if you could use your technique to factor
this one for me.

Upon which he would include a number whose factorization
would take years on generally-available computational hardware
at the current state of understanding.
He never heard back from these people.

Another of my professors
told a story of one "correspondent" who was convinced that the speed of
light could be overcome. (Yes, that's actually a physics
question, not a mathematics question, but it was sent to the
math department anyway.)
The professor started by trying to explain
the principles of special relativity
to his new pen-pal
but quickly realized that wasn't going to lead anywhere.
The correspondence was quite pleasant;
the other person was a retired gentleman who gardened and enjoyed
going for walks when he wasn't working on pushing the envelope
of modern physics.
At one point, the correspondent wrote back a multi-page letter
consisting of crayon drawings that proved that the speed of
light could be exceeded. It went something like this:

The first page consisted of a drawing of the earth with a little
rocket ship in orbit around it.

Consider a rocket ship that circles the earth once a day.
This rocket is travelling at 463.831019 meters per second.

Say what you will, but these people never suffer from the problem
of too few significant digits.

Now imagine that each day, the time it takes to circle the earth
SHRINKS IN HALF.

So that on the SECOND DAY it takes only
twelve hours to circle the earth at a speed
of 927.662037 METERS PER SECOND.

The rocket ship on the second day has a few extra zoom-lines on it.

By the THIRD DAY it takes only
SIX HOURS to circle the earth at a speed
of 1855.32407 METERS PER SECOND.

The rocket ship on the third day is going a little faster.

Each page consisted of a daily status report on our little
rocket ship, illustrated in glorious crayon,
each drawing more elaborate than the last.
As the rocket ship goes faster and faster, the report
on its speed gets bigger and bigger.
I'll skip ahead a bit.

On DAY TWENTY

the rocket ship circles the earth in
164.794922 MILLISECONDS

at a speed of
243,181,037 METERS PER SECOND.

Finally, the hammer falls:

On DAY TWENTY-ONE
the rocket ship circles the earth

in only 82.3974609 MILLISECONDS

at a speed of
486,362,075 METERS PER SECOND.

IT HAS BROKEN THE LIGHT BARRIER.

The professor realized the jig was up.
He wrote back,
"Yes, it looks like you've done it."

This morning I saw a screening of
Wordplay,
a documentary on crossword puzzles featuring
Will Shortz.
If you're a crossword puzzler, this movie is a must-see.
In addition to Will, there are plenty of other
rock stars of the crossword puzzle subculture who play major roles:
Merl Reagle,
Trip Payne, and
Ellen Ripstein.
(I was particularly amused by
this entry.
Hey, if you're not going to appreciate Ellen Ripstein's autograph,
give it to somebody who will!)

The audience loved this movie,
laughing so hard in places that it drowned out the dialogue.
(And gasping in horror when...
well, you'll have to watch the movie to find out.)
Crowd-pleasing one-liners (paraphrased):

Getting Merl Reagle to compose a Tuesday puzzle
is like getting Barry Bonds to play on your Little League team.
— Daniel Okrent reacts to seeing Merl Reagle's
byline on a Tuesday puzzle.
(Monday puzzles are easiest, with the difficulty increasing
as the week progresses.)

I had a boyfriend who would put me down, but I would just
come back with, "Oh yeah? And what are you the best
in America at?"
— Ellen Ripstein, 2001 American Crossword Puzzle
Tournament champion.

As a recovering crossword-aholic myself, I found myself using the
on-screen clues to race against Al Sanders
as he himself raced the clock to solve a
New York Times crossword.
Although I'm no crossword slouch,
I'm no match for Al Sanders.

Okay, nobody would write a dialog box that stupid, would they?
But the following dialog boxes don't really help much either:

"You clicked on an mp3 file.
Do you want to open it with that program you just installed?"

"You clicked on an avi file.
Do you want to open it with that program you just installed?"

"You clicked on an mpg file.
Do you want to open it with that program you just installed?"

"You clicked on a wmv file.
Do you want to open it with that program you just installed?"

"You clicked on a wma file.
Do you want to open it with that program you just installed?"

A phenomenon known as
"Dialog box fatigue" quickly sets in
(with a big dose of "You stupid computer" thrown in for good measure).
The system today is already filled with so many dialog boxes that
users are conditioned just to click "Yes" to everything.
If you click "Yes", then the computer does the thing you told it do.
If you click "No", then nothing happens.
In other words, users have already learned to interpret these
dialog boxes as saying
"Click Yes to do the thing you want to do or No to give up and cancel."
Why would anybody click "No"?

Moving to the specific case of programs that display media content:
I am led to believe that all the media players
include a page in their install wizard that list the file types
they are capable of playing
and give you a chance to check/uncheck the ones you want them to
assume responsibility for.
I believe this was the armistice that resulted after
a bunch of industry wrangling
wherein companies were busy accusing each other of sabotaging
each other's file types.
The upshot is that all reputable media players have already gotten
your permission to take over playback of those media types.
Why ask the user to confirm something they have already confirmed?
"Stupid computer."

Okay, so those dialog boxes are unnecessary for reputable media players.
What about the disreputable ones?
Well, once you've established that you're dealing with disreputable
media players,
they're just going to go in and hack the settings to say,
"Oh, the user already confirmed this take-over, don't bother asking.
It's all good."

So you now have a dialog box that (1) is redundant with reputable
media players, and (2) has no effect for disreputable media players.
What did this dialog box accomplish again?

If you view NTVDM.EXE in a hex editor,
you'll find the message
"Using Yoda on an x86 may be hazardous to your systems' health"
buried inside it.
Yoda was the name of the internal debugger that was used to
debug the
MS-DOS emulator, also known as the Virtual DOS Machine or VDM.
(Buried inside the Yoda source code are such wonderful variables
as "luke" and "chewy".)

The Intel 80386 has a mode known as "Virtual-8086 mode"
or just "V86 mode" wherein the CPU ran as if it were an 8086,
except that if the program did anything interesting like
issue a privileged instruction, call a software interrupt,
or fault, control would return to the protected-mode supervisor
for handling.
(Win386 used this same CPU mode to support multiple MS-DOS sessions.)
When running on an 80386-class processor, NTVDM used this mode
to do its emulation, making the CPU do the heavy lifting of
decoding instructions and emulating them, which took place
at very close to full speed.

On the other hand, NTVDM on the non-x86 processors (Alpha, PPC, MIPS, etc.)
had to implement
an entire 8086 emulator, with all the decoding and execution performed
in software.
Yoda was the debugger you used if you needed to debug the emulator.

And that's why NTVDM has a message warning you not to use Yoda on an x86.
Because on an x86, there is no instruction emulator.
There is nothing to debug.

I am working on a stack overflow bug.
To reduce the size of the stack frame,
I removed as many local variables as I could,
but there's still a a lot of stack space that I can't
account for.
What else lives on the stack aside from local variables,
parameters, saved registers, and the return address?

Well, there's also structured exception handling information,
but that's typically not too much and therefore wouldn't
be the source of "a lot" of mysterious stack usage.

My guess is that the code is generating lots of large C++ temporaries.
Consider the following program fragment:

"How does this code even compile?
The function Foo wants a BigBuffer,
not an integer!"
Yet compile it does.

That's because the compiler is using the BigBuffer
constructor as a converter.
In other words, the compiler inserted the following temporary
variable:

void oops()
{
BigBuffer temp(3);
Foo(temp);
}

It did this because a constructor that takes exactly one argument
serves two purposes:
It can be used as a traditional constructor (as we saw with
BigBuffer temp(3))
or it can be used to provide an implicit conversion from the
argument type to the constructed type.
In this case, the BigBuffer(int) constructor is
being used as a conversion from int to BigBuffer.

I have gazed into my crystal ball and emerged with a prediction for 2006.
Revealing my prediction now may influence the event itself,
so I will post only the hash for the prediction.
I will post the actual prediction at the end of the year.

The J started out its life as a smiley-face.
The
WingDings
font puts a smiley face where the letter J goes.
Here, let me try:
<FONT FACE=WingDings>J</FONT>
results in J.
As the message travels from machine to machine, the font formatting
may get lost or mangled, resulting in the letter J appearing
when a smiley face was intended.
(Note that this is not the same as the smiling face incorporated
into Unicode as U+263A, which looks like this: ☺.
Some of you might see it; others might not.)

I recall a story (possibly apocryphal) of somebody who regularly exchanged
a lot of e-mail with Microsoft employees and who as a result
started signing their own messages with a J,
figuring this was some sort of Microsoft slang.
The Microsoft employees who got the J-messages scratched their heads
until they were able to figure out how their correspondent arrived
at this fabulous deduction.

And now, the mysterious J has come full circle,
because some people use it ironically,
intentionally just writing a J without setting the font,
in the same way people making fun of
"leet" writing may
"accidentally" type "1"s (or even more absurdly,
the word "one") into a row of exclamation points.