In the category of dubious security vulnerability, I submit
for consideration the following report:

A machine with the kernel debugger enabled is vulnerable to
a denial of service attack from an unprivileged user.
The unprivileged user need only deference a null pointer.
Once this occurs, the computer becomes completely unusable to all users.

Um, yeah.
That's sort of the whole point of the kernel debugger,
to halt system execution as soon as a problem has been detected.
Enabling the kernel debugger requires administrative privileges,
so it's not like unprivileged users can force a system halt
on their own;
they need the help of an administrator to turn on kernel debugging first.
At that point, you've already made it to the other side of the
airtight hatchway.
If you have an accomplice who is already an administrator,
then you may as well just cut to the chase and tell your accomplice
to add you to the administrators group, too.
Then you can do much more than simply halting the system.

Clarification:
As Bob noted, and which I apparently didn't make clear enough
from the title of the article,
this message arrived as a security vulnerability report.
It's not a security vulnerability if it requires assistance from
an administrator to pull off.

It was around 10:30 in the morning, and I got on the train
to head into town, planning to climb the steps through the
Alfama district to visit the
castle
which looms over the city.
The morning rush was over, and the Metro car was nearly empty.

Just before the doors closed,
a group of about four twentysomething guys stumbled onto the train,
walking unsteadily and talking quite loudly among themselves.
I found this immediately suspicious.
They are acting drunk, but who is drunk at 10:30 in the morning?
At 10:30, you're hung over, not drunk.
And even if you are drunk, you are drunk in the comfort of your home,
not stumbling around the subways.

Even though the subway car had only about three people,
and there was plenty of room to spread out,
this group of pretend-drunks hung around close to me.
I went on high alert.

A few seconds later, one of the guys "stumbled" into me and thrust
his hand into my pants pocket.
I immediately grabbed his hand and yanked it back out, making sure
he didn't get anything,
adding a shout of "Hey!"
(I don't speak Portuguese, so I couldn't say anything more eloquent.)

Still keeping up the ruse of just being a bunch of loud-mouthed drunks,
the group of would-be pickpockets stumbled off the train just as the
doors closed.
Well, three of them did.
One of them didn't quite get off in time and stood with his face
against the wall until the train reached its next stop,
at which point he ran off.

After Lisbon, I headed over to Madrid, and on the Metro
I was on one of the long escalators connecting between two train lines,
and I caught the person behind me surreptitously trying to unzip
an outside pocket on my shoulder bag.
He hadn't made much progress, but just to make sure he didn't get anything,
I said hello and shook his hand.

After all, the point of the clipboard is to hold information
temporarily.
Programs are permitted to empty the clipboard, add data to the clipboard,
or retrieve data from the clipboard.
That's why it's there.

(I'm assuming that the naming of the program Excel was just
an example of a program, and that the question wasn't
"Why doesn't Windows have a specific check for the program
EXCEL.EXE and block its clipboard access while
still allowing clipboard access to everybody else.")

Okay, maybe the question wasn't so much
"Why are programs allowed to empty the clipboard"
as it was
"Why are programs allowed to empty the clipboard when they launch?"
Well, because that might have been the whole point of the program!
Somebody might write a program called empty­clip whose
sole purpose in life is to empty the clipboard.
You run the program, it empties the clipboard,
and then it exits.
Short and sweet.
If Windows didn't allow programs to empty the clipboard when
they started up, then this program would not be able to get its
work done.

You might not consider that particularly useful,
but there are actually quite a few programs which empty the
clipboard when they start up.
For example, the clip program that comes
with Windows takes its standard input and places it on the clipboard.
Implied in that functional description is that it erases what used
to be on the clipboard.
Everything the program does is in its startup.

echo I'm on the clipboard! And I erased what use to be there.| clip

Many scripting languages provide access to the clipboard,
if not natively, then through an extension.
Since these are typically
not GUI programs, as far as the window manager can tell,
these programs as perpetually stuck in their startup code:
They never go input idle because they never pump messages.
Prohibiting programs from accessing the clipboard during
startup means that console programs are effectively banned
from modifying the clipboard at all.

Okay, maybe the question wasn't
"Why are programs allowed to empty the clipboard when they launch?"
so much as it was
"Why are programs allowed to empty the clipboard outside
of an explicit user action (like a click or a hotkey)?"
Well, we still have the problem of programs whose design is to
empty the clipboard without any user interaction,
like all those console scripts.
But you also remove many GUI usage patterns, such as pushing
work to a background thread
so that the program can remain responsive.
And it would also prevent you from writing a program that
modified the clipboard in response to a drop operation.
I can imagine a program called file­contents­to­clip
which just sits there and waits for you to drag/drop a file
onto its window.
When you do that, it opens the file and places the file's
contents onto the clipboard.
Since the drag/drop operation is handled by the drag source,
the drop target receives no input and (according to the
rule of "no clipboard access without user input") is denied
permission to erase the old clipboard contents.

In order for these sorts of interaction models to work,
there would have to be some sort of Allow­Clipboard­Access
function (akin to Allow­Set­Foreground­Window)
so that one process can temporarily
transfer clipboard access permission
to another process.
It could be done, but it would make writing applications more
complicated,
because you would have to anticipate what operations
might result in another application wanting to access the
clipboard and scattering calls to Allow­Clipboard­Access
in various places in your program.
If you miss a spot, you'll get some bug filed against your
program that says,
"When I click the Preview button,
and I've set my custom previewer to program X
and configure program X to say 'always copy image
to clipboard when previewing', the feature doesn't work."

The clipboard was part of Windows 1.0,
and back in those days, you didn't have a lot of
memory available.
You had to get a lot done with very little.
Programmers were trusted to use their great power
with great responsibility.
And besides, as we saw with programs like
clip (and hypothetical programs like
empty­clip and
file­contents­to­clip),
allowing programs to empty the clipboard at startup
made it possible to write some interesting and
useful tools.
Windows historically didn't stop programmers from doing stupid things
because that would also prevent them from doing
clever things.

As a child, my mother would always call out
"banzai" when she wanted me to raise my arms above my head
so she could put on or take off a pullover shirt.
I assumed that banzai was the word for
"stick your hands in the air!"

It wasn't until
well into my adult life that my mother explained to me that,
no, banzai does not mean "stick your hands in the air."
It's a Japanese word meaning "ten thousand years",
shouted as a term of approbation and accompanied by
(you guessed it) throwing one's hands into the air.
My mother was using it as a play term;
in the United States,
when you get your child to throw his hands into the air,
you might accompany it with a shout of
"Touchdown!"

A customer asked,
"I'm looking for a way to convert English characters to another
language.
For example, if the target language is Arabic and the string
is the word Hello, I want it to convert to
H(Arabic)e(Arabic)l(Arabic)l(Arabic)o(Arabic)."

The question is still vague, even with the assistance of the example,
since it's not clear what "H(Arabic)" means.

There are a variety of ways of converting a string from one
language to another.
Here are a few I was able to think of.

Translation. For example, converting cat to German
would result in Katze.
Of course, there are many words with no good direct translation
and others which are ambiguous.
Good-bye is normally Auf Wiedersehen,
but if you're saying good-bye to someone on the telephone, then it's
Auf Wiederhören.
But at least in that case, even if you get it wrong, the
reader has some idea of what you meant.
Whereas sort could be translated as
Art (as in What sort of apple is this?)
or as ordnen
(as in Sort these alphabetically),
and if you get the wrong one,
the reader is completely baffled.
(Now, translation is clearly not what was intended here,
but I included it for completeness.)

Transliteration.
This is an operation most commonly performed between scripts,
such as how the name of the capital of China
北京
becomes Beijing in English.
The great thing about transliteration systems is that you usually have
many to choose from.
For example, if you prefer Wade-Giles over Pinyin, then
the capital city would be spelled Pei-Ching.
Transliterating to non-alphabetic scripts can be quite a
challenge as well: Everyone is familiar with the story of
Coca-Cola in Chinese.
(Learn more about Extended Linguistic Services from
Kieran Snyder, the long-distance linguist.
I considered linking to specific articles until I realized that
I was basically linking to everything,
so here's
the main page. Go nuts.)

Phoneticization.
This is similar to transliteration, but spells out the
sounds when you
cannot assume that the reader is familiar with any particular
transliteration system.
The capital of China would be phoneticized as
bay-jing.

As it turns out, the customer wasn't interested in any of these!

What the customer wanted was,
"Take the word Hello and imagine how you would type it on
a US-English keyboard.
Now change the keyboard layout to Arabic and then press
exactly the same keys.
That's what I want."
In other words, the customer wanted to see what the result
would have been if you had told a blindfolded touch-typist
to type Hello,
but secretly replace the US-English keyboard with an Arabic one.

Wow, that's something that hadn't even occurred to me
as a possibility.

In restaurants in the United States,
the custom is that
anything brought to the table that you didn't
order is complimentary.
For example, after you place your order, the waiter returns to your
table with a basket of bread.
The bread is provided at no extra charge.
These complimentary items are usually small, like some bread
or a one-bite appetizer.
(If anything bigger is brought to the table that you didn't request,
it is customary to ask the waiter,
"Is this ours?" just to make sure
it wasn't delivered to the wrong table by mistake.)

In Portugal, the custom is that these items (known as
couvert) are brought to your table
as a convenience so you don't have to order them,
but you still have to pay for them if you eat them.
Again, they are typically small items like bread or a small plate of olives.
It took me a while to adjust to the Portuguese custom,
and I would absently start eating them before realizing that they
weren't complimentary.
Fortunately, the mistake is not costly;
these couvert items usually cost only about one Euro,
two tops,
and they are things you usually wouldn't have minded ordering anyway.

There was one restaurant in the touristy restaurant part of Lisbon
which was clearly trying to exploit the inattentive foreigners.
Before my main course was ready,
the waiter brought a not insubstantial cheese plate to the table.
The cheese appeared quite old.
(Yes, I know cheese is supposed to be old, but this one
had dried out at the edges.)
I may even have detected a layer of dust on it.
This was the last meal of my visit, so by then I had figured
out this couvert thing and knew to stay away.
Which was a good move, because I checked the menu on the way out,
and the cheese plate costs a whopping €7.50.

Another restaurant custom different between the United States and
Portugal is the doggie bag,
In the United States,
it is customary for restaurants to offer to pack your uneaten food
for you to take home.
This is common because
portion sizes in the United States
have grown to ridiculous levels.
The term doggie bag appears to have fallen out of favor,
though.
Now it's just called a box, as in "Would you like a box for that?"
or "Would you like me to box this up?"
The doggie bag is not part of Portuguese custom;
when asked for a box to take home uneaten food,
the waiter reacted as if this were a completely unheared-of situation.
To his credit, he did find a solution:
He went to the Chinese restaurant next door and took one of their
take-out containers.

Nice to know that Chinese restaurants are the same all over the world.

Bonus restaurant tip:
In my experience, in Portugal, you have to ask for the check.
In the United States, whether you have to ask for the check or whether
it will be brought to you varies regionally.
In the Northeast, you have to ask for it;
in the Seattle area, it will typically be brought to you,
usually with a remark from the waiter like "Take your time,"
which means "I'm not trying to rush you out of here;
I'm just saving you the trouble of asking for the check.
Pay when you're ready."
(Unless you're in a
Vietnamese restaurant,
in which case you have to ask for the check, per custom.)

You won't see them when you execute a SET command,
but if you write a program that manually enumerates all the
environment variables and prints them out,
and if you launch it from a command prompt,
then you'll see weird
variables with names like =C: and whose values correspond to
directories on that drive.
What are these things?

These variables are part of the private bookkeeping of the command
processor cmd.exe.
That's why I added if you launch it from a command prompt
to the steps above, because if you run the program from Explorer's
Run dialog, you won't see them.
If a cmd.exe is not in the chain of custody of your environment block,
then you won't see the weird cmd.exe bookkeeping variables.

Okay, so the command processor sets these things, but what are they?
They are a leftover from the command processor's attempt to mimic
the old MS-DOS way that drives and directories were handled.
Whereas in Win32, there is only one current directory,
in MS-DOS, there was one current directory for each drive.
Consider the following sequence of commands:

During this sequence of commands, we start with A: as the
current drive and set its current directory to A:\SUBDIR.
Next, we set the current drive to B: and set
B:\TWO as its current directory.
Finally, we set the current drive back to A:,
and when we ask for a listing,
we get the contents of A:\SUBDIR because that is the
current directory on the current drive.

Win32 does not have the concept of a separate current directory
for each drive, but the command processor wanted to preserve
the old MS-DOS behavior because people were accustomed to it
(and batch files relied upon it).
The solution was to store this "per-drive current directory"
in the environment, using a weird-o environment variable name
so it wouldn't conflict with normal environment variables.

If you repeated the above commands in cmd.exe, the output
is the same, but it is accomplished in a very different way.

When we switch back to drive A:,
the command processor says,
"Hey, what was the current directory on drive A: the last
time I was there?"
It looks into its environment and finds the =A: variable,
which tells it, "Oh, it was A:\SUBDIR".
And that's the Win32 directory that it sets as current.

But why put these internal variables in the environment?
Can't they just be regular variables inside the cmd.exe process?

The variables are exported into the environment because you
want these "fake per-drive current directories" to be inherited
by child processes.
For example, consider that you are sitting at your command prompt,
you run emacs, then from emacs, you shell out to another command prompt.
You would expect that the nested command prompt will have the same
"per-drive current directories" that you set back in the outer
command prompt.

In Belém,
directly to the east of the
Mosteiro dos Jerónimos
is a block of small shops,
the most famous one of which being the
Pastéis de Belém
which sells the, um,
Pastel de Belém,
the Belém version of the unofficial dessert of Portugal.
(This photo of a group of people eating
was taken in front of the
Pastéis de Belém
shop.
You can see the blue awnings in the background.)
The place is always packed shoulder-to-shoulder with tourists.
So turn around, leave the store, and walk back toward the
Mosteiro dos Jerónimos.
At about where the pink building is in the photo referenced above
is a tiny
shop called
Pão Pão, Queijo Quejo,
which means
Bread Bread Cheese Cheese.
If the photo doesn't help, here's how you find it:
It's the one packed to the gills with teenagers.

Now,
following the teenagers to decide where to eat is a hit-or-miss affair.
You might find an awesome little shop,
or you might end up at McDonalds.
I lucked out and scored a major win.

Here's how you enjoy lunch at
Pão Pão, Queijo Queijo:

Read the menu board posted outside to decide what you want.
Have your dictionary handy since it's only in Portuguese.

When you reach the register near the door,
place your order and pay for it.
You will receive an order slip.

Join the mob inside the store and try to work your way to
the counter where all the food is.

Get the attention of somebody behind the counter.
You are competing with two dozen other people at this point,
so it may take some effort.

Hand the person your order slip and do your best to answer
questions like "Do you want sauce?" and "For here or to go?"
The correct answers are "Only a little" and "To go", by the way.

Receive your sandwiches, grab some extra napkins,
and walk across the street to the park.

Enjoy your sandwich in the park while taking in the view of the
Ponte 25 de Abril
(the April 25 Bridge),
then take a nap in the warm sunshine.

Second only to salt in the Portuguese diet
appears to be
ranch dressing/mayonnaise/whatever that white sauce is.
(Hence the need for extra napkins and the correct answer of "Only a little.")
If you're not careful, you'll find your sandwich drowning in
approximately ten cubic meters of the stuff.
But once you get past that, you have a tasty sandwich with
warm meat and crunchy slaw on a crisp baguette.
It's sort of a Portuguese version of a
Vietnamese sandwich.

A customer had trouble getting an icon to display for a registered
file type.

In my resource file, I specify the icon like this:

101 ICON awesome.ico

And when I register my file type, I set it like this:

[HKEY_CLASSES_ROOT\.xyz\DefaultIcon]
@="C:\path\to\awesome.exe,101"

However, when I view an .xyz file,
my awesome icon doesn't appear.
On the other hand, if I change the 101 to a 0,
then it works.
Why?
Isn't the number in the resource file the resource ID?

Why yes, in fact, the number in the resource file is indeed
the resource ID.
But the number after the comma in the Default­Iconisn't.

The format of shell icon locations (used most visibly
by Default­Icon, but also used in other places)
is «file»,«index»,
where the index is a zero-based index of the icon in your
resources.
In other words,
an index of zero means "Give me the first icon in the file."
The resource compiler sorts icons numerically by resource ID,
so the first icon in the file is the icon with the numerically
lowest resource ID.
In the above example, apparently there are no icons with resource IDs
less than 101;
that would explain why asking for icon index zero results in the awesome
icon.

The function behind all this icon hunting is Extract­Icon.
The icon location string is split up at the comma into a path and
an integer, and that path and integer are passed to the
Extract­Icon function.
Since the Extract­Icon
function interprets the integer
as the icon index, that's what the integer in your icon location
string means.

In Windows 95, the
Extract­Icon function was enhanced
so that you could also specify an icon by its resource ID
by passing its negative as the icon index.
In other words, if you place a negative number after the comma,
then its absolute value is interpreted as the resource ID.

The workaround for this is actually straightforward,
and you should be able to figure it out on your own
based on information provided in this article.
How do you specify that you want the icon whose resource ID is 1?

I learned this term from a chart presented at a team meeting.
It contained a column labelled BIS.
When asked what those letters meant, the team manager explained
that it's an abbreviation for butts in seats.
Everybody in the room instantly understood.
It is the number of
actual human beings sitting at desks doing work.

When doing project planning, you sometimes get carried away
with the imaginary people who would be working
on your project someday,
treating them as if they were real people:
coming up with features for these imaginary people to work on,
projecting how many bugs these imaginary people will fix,
looking forward to the funny stories these
imaginary people will tell when you go out for a beer after work.

This is all ridiculous, of course, because
imaginary people don't write code or fix bugs or
buy you a pint of beer after work.

You need to base your calculations
on actual human beings and not imaginary people.
That's why you work with butts in seats and not empty seats.
Sure, you have two open positions on your team,
and you have every intention of hiring people to fill them
over the next few months,
but until there are butts in those seats,
those people are still imaginary,
and they're not doing any work,
so you shouldn't count them in your charts.