If you look in your
C:\Windows\Media folder,
you'll find a MIDI file called
onestop.
What's the story behind this odd little MIDI file?
Aaron Margosis
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[citation needed],
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
purposes.
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.

Commenter
Nitpicker objected,
"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
Corner"
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
32-bit registers.

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
Ctrl+Alt+Del.
For example, you saw this message if you hit
Ctrl+Alt+Del
while there was a hung Windows application:

Contoso Deluxe Music Composer

This Windows application has stopped responding to the system.

* Press ESC to cancel and return to Windows.* Press ENTER to close this application that is not responding. You will lose any unsaved information in this application.* Press CTRL+ALT+DEL again to restart your computer. You will lose any unsaved information in all applications.

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.

You're debugging a program and
you want to set a breakpoint on some function,
say,
netapi32!Ds­Address­To­Site­NameW,
but when you execute the
bp netapi32!Ds­Address­To­Site­NameW command in the debugger,
the debugger says that there is no such function.

The
Advanced Windows Debugging book
says that the bp command should set a breakpoint
on the function,
but the debugger says that the symbol cannot be found.
I used the x netapi32!* command to see that
the debugger did find a whole bunch of symbols,
and it says that the symbols were loaded
(from the
public symbol store),
but
netapi32!Ds­Address­To­Site­NameW
isn't among them.
The MSDN documentation says that Ds­Address­To­Site­NameW is
in the netapi32.dll,
but it's not there!
I can't believe you guys stripped that function out
of the symbol file,
since it's a function that people will
want to set a breakpoint on.

Okay, first let's
rule out the conspiracy theory.
The symbols were not stripped from the public symbols.
And even if they were,
that shouldn't stop you, because after all,
the loader has to be able to find the function
when it loads your program,
so it's gotta be obtainable even without symbols.

Don't be helpless.
You already have the tools to figure out where the function is.

Just write a program that calls the function,
then load it into the debugger and see what the
destination of the call instruction is.
You don't even have to pass valid parameters to the
function call,
since you're never actually executing the code;
you're just looking at it.

And hey looky-here,
you already have a program that calls the function:
The program you're trying to debug!
So let's see where it goes.

What you saw was the effect of a
DLL forwarder.
The code for the function
Ds­Address­To­Site­NameW doesn't live in
netapi32.dll.
Instead,
netapi32.dll has an export table entry that says
"If anybody comes to me asking for Ds­Address­To­Site­NameW,
send them to
logoncli!Ds­Address­To­Site­NameW instead."

Officially, the function is in netapi32.dll
for linkage purposes,
but internally the function has been forwarded to another DLL
for implementation.
It's like a telephone call-forwarding service for DLL functions,
except that instead of forwarding telephone calls,
it forwards function calls.
You publish a phone number in all your marketing materials,
and behind the scenes, you set up the number to forward
to the phone of the person responsible for sales.
That way,
if that person quits,
or the responsibility for selling the product changes,
you can just update the call-forwarding table,
and all the calls get routed to the new person.

That's what happenned here.
The MSDN phone book lists the function as being in
netapi32.dll,
and whenever a call comes in,
it gets forwarded to wherever the implementation happens to be.
And the implementation has moved around over time,
so you should continue calling
netapi32!Ds­Address­To­Site­NameW
and let the call-forwarding do the work of getting you to
the implementation.

Don't start calling logoncli directly,
thinking that you're cutting out the middle man,
or in a future version of Windows,
your program may start failing with a
"This number is no longer in service" error,
like calling the direct office number for
the previous sales representative,
only to find that he left the company last month.

Now, the division by zero results in IEEE positive infinity,
would would normally be printed as
1#INF.
But the catch here is that the print format says
"Display at most two places after the decimal point."
But where is the decimal point in infinity?

The Visual C runtime library arbitrarily decided that
all of the exceptional values have one digit before
the decimal (namely, the "1").
Actually, it turns out that this puzzle might be an
answer to Random832's question,
"What's
the 1 for?"
Maybe the 1 is there so that there is a digit at all.

Okay, so now you have one digit before the decimal
(the "1"),
and now you need to show at most two places after the decimal.
But "#INF" is too long to fit into two characters.
The C runtime then says,
"Well, then I'd better round it off to two places, then."

The first character is "#".
The second character is "I".
Now we need to round it.
That's done by inspecting the third character,
which is "N".
We all learned in grade school that you round up if the next
digit is 5 or greater.
And it so happens that the code point for
"N" is numerically higher than the code point for
"5",
so the value is rounded up by incrementing the previous digit.
Incrementing "I" gives you
"J".

That's why printing IEEE positive infinity to two places
gives you the strange-looking "1#J".
The J is an I that got rounded up.

I doubt this behavior was intended;
it's just a consequence of taking a rounding algorithm intended
for digits and applying it to non-digits.

Of course, in phonetics, rounding an i
produces a ü.
Imagine the nerdiness of rounding
"1#INF" to two places and producing
"1#Ü".
That would have been awesome.

A frustrating pattern that shows up occasionally in customer
questions is the case where the customer poses a problem,
and pre-emptively rejects the mechanism explicitly designed
to solve that problem.

How can we change the widget color without using
IWidget::Set­Color?

Um, the whole point of
IWidget::Set­Color
is to change the color of a widget.
Why are you rejecting the mechanism whose sole purpose
in life is to solve the very problem you are having?

Usually, if you press hard enough, they will cough up the
reason why they think they cannot use the solution specifically
designed to do what they want.
Various excuses tend to come up over and over.

One excuse is the belief that the proposed solution
does not work in a particular scenario.
"We cannot use ACLs because they don't work on network volumes."
Um, yes they do.
Check it out.

Or that the proposed solution doesn't fit their choice
of technology.
"We are programming in a language that does not support
COM objects.
We can only p/invoke to C-style APIs."
Well, you can work around that problem by writing a helper
DLL that exposes a C-style API, and implements it by
calling the COM method.

Or that the proposed solution violates some vague corporate
policy.
"We have a corporate policy that users cannot change widget colors,
so the
IWidget::Set­Color method returns
E_ACCESS­DENIED.
We're looking for a way around that policy."
Okay, well, now that's something you need to take up with the
people who establish your corporate policies.
Don't come to us looking for ways to circumvent corporate policy.

One time, the reason came from our
own technical support staff:
"We cannot write a C++ program that calls
IWidget::Set­Color
and provide it to the customer
because we are not a developer support team.
We are not allowed to send compiled binaries to the customer
for liability reasons,
and we generally do not send
source code because our customers
typically do not have the expertise or desire to install
Visual Studio and
the Platform SDK just to compile and run a five-line C++ program.
(Did I mention that we are not a developer support team?)
Can it be done from a batch file?"

The non-joking answer is
"The customer can take this information to a developer support team,
or at least somebody who will write the program for them,
if they don't know how to write a program themselves."
Microsoft Consulting Services exists for this, but that is
likely overkill for a five-line program.

As
every computer scientist knows,
the IEEE floating point format reserves a number of representations
for infinity and non-numeric values
(collectively known as NaN, short for not a number).
If you try to print one of these special values with the
Visual C runtime library,
you will get a corresponding special result:

Output

Meaning

1#INF

Positive infinity

-1#INF

Negative infinity

1#SNAN

Positive signaling NaN

-1#SNAN

Negative signaling NaN

1#QNAN

Positive quiet NaN

-1#QNAN

Negative quiet NaN

1#IND

Positive indefinite NaN

-1#IND

Negative indefinite NaN

Positive and negative infinity are generated by arithmetic overflow,
or when the mathematical result of an operation is infinite,
such as taking the logarithm of positive zero.
(Don't forget that
IEEE floating point supports both positive and negative zero.)
For math nerds:
IEEE arithmetic uses affine infinity,
not
projective,
so there is no
point at infinity.

Signaling and quiet NaNs are not normally generated by computations
(with one exception noted below),
but you can explicitly create one for a floating-point type
by using the
std::numeric_limits<T>
class,
methods
signaling_NaN() and
quiet_NaN().

Recall that there is not just one signaling and quiet NaN,
but rather a whole collection of them.
The C runtime does not distinguish among them when printing, however.
All signaling NaNs are reported as 1#SNAN,
regardless of the signal bits.
The C runtime does report the sign of the NaN,
for what little that is worth.

The weird one is the Indefinite NaN,
which is a special type of quiet NaN generated under specific conditions.
If you perform an invalid arithmetic operation like
add positive infinity and negative infinity,
or take the square root of a negative number,
then the IEEE standard requires that the result be a quiet NaN,
but it doesn't appear to specify what quiet NaN exactly.
Different floating point processor manufacturers chose different
paths.
The term Indefinite NaN refers to this special quiet NaN,
whatever the processor ends up choosing it to be.

Some floating point processors generate a quiet NaN with the signal
bits clear but the sign bit set.
Setting the sign bit makes the result negative,
so on those processors, you will see the indefinite NaN
rendered as a negative indefinite NaN.
(The x86 is one of these processors.)

Other floating point processors generate a quiet NaN with the signal
bits and the sign bit all clear.
Clearing the sign bit makes the result positive,
so on those processors, you will see the indefinite NaN
rendered as a positive indefinite NaN.

In practice, the difference is not important, because either way,
you have an indefinite NaN.

By default,
when the taskbar or any other application wants to display
a thumbnail for a window,
the result is a copy of the window contents shrunk down to the
requested size.
Today we're going to override that behavior
and display a custom thumbnail.

We start by enabling custom thumbnails by setting the
DWMWA_HAS_ICONIC_BITMAP attribute
to TRUE.
This overrides the default thumbnail generator and allows us to
provide a custom one.

Next is a helper function that I broke out from
this program because it's useful on its own.
It simply creates a 32bpp bitmap of the desired size
and optionally returns a pointer to the resulting bits.

One of the quirks of the
WM_DWM­SEND­ICONIC­THUMB­NAIL
message is that it passes the x- and y-coordinates backwards.
Most window messages put the x-coordinate in the low word and
the y-coordinate in the high word, but
WM_DWM­SEND­ICONIC­THUMB­NAIL
does it the other way around.

Since we're generating a custom thumbnail and live preview bitmap,
we need to let the window manager know that the custom rendering
is out of date and needs to be re-rendered:
Invalidate the custom bitmaps when the counter changes.

And finally,
just to be interesting, we'll also stop rendering content into
our main window.

void
PaintContent(HWND hwnd, PAINTSTRUCT *pps)
{
// do nothing
}

Run this program and observe that the window comes up blank.
Ah, but if you hover over the taskbar button, the custom thumbnail
will appear, and that custom thumbnail has the number 0 in it.
Click on the button in the thumbnail, and the number in the custom
thumbnail increments.

As a bonus, move the mouse over the thumbnail to trigger Aero Peek.
The live preview bitmap contains the magic number!
Move the mouse away, and the magic number vanishes.

Now, this was an artificial example, so the effect is kind of weird.
However, you can imagine using this in less artificial cases where
the result is useful.
You application might be a game,
and instead of using the default thumbnail which shows a miniature
copy of the game window,
you can have your thumbnail be a tiny scoreboard or focus
on a section of the board.
For example, if you are a card game,
the thumbnail might show just the cards in your hand.

I can't think of a useful case for showing a live preview bitmap
different from the actual window.
The intended use for a custom live preview bitmap is for applications
like Web browsers which want to minimize a tab's memory usage when it
is not active.
When a tab becomes inactive,
the browser can destroy all graphics resources except for
a bitmap containing the last-known-valid contents of the window,
and use that bitmap for the thumbnail and live preview.

I decided to shake things up and use a different smart
pointer library:
com_ptr_t.
(That'll teach you to complain that I don't use a smart
pointer library in my samples.
Now you get to complain that I use the wrong
smart pointer library.)

If you're really clever, you might generate your overlay icons
on the fly,
say, if you wanted to report the number of
unread messages or something.

I've heard that there's one program out there that abuses the
ITaskbar­List3::Set­Progress­State
method
by changing its progress state repeatedly,
causing its taskbar button to cycle through different colors
to get the user's attention.

Just a reminder: The user interface guidelines say that the way
to get the user's attention is to flash your taskbar button.
Various parts of the system understand this convention and
respond to it.
(For example, the taskbar will temporarily unhide if a button
starts flashing,
and accessibility tools know how to signal the flash state to
the user.)
As always, the shell reserves the right to block this sort of
abusive behavior in the future,
just like it has done with abusive notification icons.

According to legend, there was a project whose product
was running too slow,
so they spun off a subteam to see what architectural changes
would help them improve their performance.
The subteam returned some time later with a fork of the project
that they had "tuned".
And it was indeed the case that the performance-tuned version
ran a lot faster.

Later, the development team discovered that part of the "tuning"
involved simply deleting all the synchronization.
They didn't replace it with lock-free algorithms
or anything that clever.
They just removed all the critical sections.

Many years ago, I wrote,
"Do not write in-process shell extensions in managed code."
Since I originally wrote that article,
version 4 of the .NET Framework was released,
and one of the features of that version is that it supports
in-process side-by-side runtimes.
Does that mean that it's now okay to write shell extensions in managed code?

The answer is still no.

The
Guidance for implementing in-process extensions
has been revised, and it continues the recommendation against writing
shell extensions and Internet Explorer extensions (and other types of
in-process extensions) in managed code,
even if you're using version 4 or higher.

Although version 4 addresses the side-by-side issue,
it is still the case that the .NET Framework is a
high-impact runtime, and that there are various part of
COM interop in the .NET Framework that are not suitable for
use in an extension model designed around native code.