Well, the computer once again died, and before it finally kicked
the bucket, the onboard video card started pumping out corrupted pixels.
My suspicion that my motherboard ate video cards was correct.
In fact, its appetite for video cards was so voracious,
it ate itself.

Okay, so here are the options I've been able to come up with so far.

Feed the computer video cards.

Replace just the motherboard.

Replace the entire computer.

The first option is out because the rate of consumption appears to
be one video card per month, which is a rather expensive diet.

The second option is a possibility, but the computer was purchased
pre-assembled from a name-brand manufacturer, so the odds of finding
a motherboard that exactly fits into the original case are pretty
slim.
I'll probably have to move everything to a new case.

The third option is the lazy way out,
and is in fact the solution employed by most non-technical users.

For now I'm going to investigate option two.
I'll have to take the computer apart to get at the motherboard anyway,
and then I can investigate what type of replacement I need to get.
(In terms of socketry and stuff.)
Though who knows how long it will be before I actually get around
to fixing the computer.

Meanwhile,
my laptop
which was manufactured back in 2000
continues to chug along happily.

When the Internet Explorer folks
announced
that they were going to call
their next version of Internet Explorer
Internet Explorer 7 for Windows XP and
Internet Explorer 7 in Windows Vista,
many people responded to the awkward name by suggesting that it
be shortened to
Internet Explorer 7 XP
and
Internet Explorer 7 Vista.
Why the longer names?

Lawyers.

Microsoft's own trademark guidelines† specify that
the product names are Windows XP and
Windows Vista and not just
XP and Vista.
The trademark is on the entire phrase, not just the last word.
Furthermore, the trademark guidelines specify that
products may not append just XP or Vista to
their names; they have to say X for Windows XP or
X for Windows Vista.

In an earlier era, you had to be careful to say
Windows NT and not just NT for the same reason.
You see, the name NT is a registered trademark of
Northern Telecom, and part of the agreement with "the other NT"
is that the Windows product
would always be used with the word Windows in front.

If you took a close look at the Windows 2000 box,
you may have seen the phrase "Built on NT Technology."
I don't know how hard it was to do, but I suspect a good amount
of negotiations with Northern Telecom took place to allow
Microsoft to use that alternate formulation
without the word Windows in front.
Indeed, if you looked really closely at the box,
you'd have found a trademark acknowledgement for Northern Telecom
deep in the fine print.

Lawyers by training are very cautious people.
After all, a new lawsuit against Microsoft gets filed approximately
once every thirty seconds.¶
They're probably also responsible for all your Office# shortcuts
on the Start menu being named
Microsoft Office This 2007 and
Microsoft Office That 2007
instead of
This 2007 and
That 2007, or even (shocking!) just
This and
That.
It's a daring move, and lawyers don't like to be daring.
Nobody ever got sued for playing it safe.††

Nitpicker's corner (guest appearance)

*Just burning off a footnote marker because I don't like asterisks.

†I myself violate some of these guidelines because
I try to write like a human being and not
a robot.
Only robots say Windows-based programs.‡

‡That statement is not literally true.
Here's a reformulation of that statement for the benefit of robots:§
"People who say Windows-based programs sound like robots."

§That statement is also not literally true.
Here's a reformulation of that statement for the benefit of people
who take a robotic approach to reading:
"Here's a reformulation of that statement for the benefit of people
who take a robotic approach to reading:"

||Burning off another footnote marker because I don't like parallel
lines either.

¶An exaggeration, not a statement of fact.

#s/Office/Microsoft® Office™ System/**

**I have not researched whether that's the correct way of writing it.

††Okay, maybe somebody somewhere has gotten
sued for playing it safe.
It was just a catchy sentence, not a statement of fact.

In college, the hallway that led to
the basement lab where most of the computer science
students did their work had a big red switch, a pushbutton,
labeled "Emergency power shutoff".
Nobody was sure whether it actually was hooked up to anything
or was simply a joke,
but nobody wanted to take the chance of finding out, either.
I remember one evening some people were goofing off with a basketball,
and somebody missed a pass, and the ball
hit the wall dangerously close to the big red switch.
They (and everybody in the lab)
immediately realized what had almost happened, and the group
sheepishly took their ball outside.

Some time later,
the legend of the big red switch was ultimately resolved.
The morning after a particularly bad rainstorm,
one of my colleagues came into the computing center and explained
that he had gone down to the computer lab
the previous evening and found it flooded,
with water still coming in.
Realizing that electricity plus water equals danger,
he went over to the big red switch and pushed it.
And true to its label, it shut off the power to the lab and
the central file server.
We were all in awe that he got to push the big red button
for a legitimate reason.
An opportunity like that comes only once in a lifetime.

In Lisbon, walk/don't walk signs are mostly decorative.
The real rule for crossing the street is
look both ways and cross when safe.
There's no requirement that you use a designated crosswalk.
As long as the coast is clear, you can cross the street anywhere.
When my host for
the conference
accompanied me to the conference center,
we crossed the street and my host pointed out,
"You know, we're actually using the official crosswalk this time."

(For what it's worth, people in Madrid restrict themselves to crossing
at crosswalks and generally observe the walk/don't walk signs, although
if the light says don't walk and there are no cars anywhere nearby,
they will cross anyway.
This evaluation of Madrid crosswalk behavior is probably
skewed by the higher concentration of tourists.)

The FlashWindowEx function
and its simpler precursor FlashWindow
let a program flash its window caption and taskbar button manually.
The window manager flashes the caption automatically
(and Explorer follows the caption by flashing the taskbar button)
if a program calls SetForegroundWindow
when it doesn't have permission to take foreground,
and it is that automatic flashing that the
SPI_SETFOREGROUNDFLASHCOUNT setting controls.

For illustration purposes, I'll demonstrate flashing the caption
manually.
This is generally speaking not recommended, but since you asked,
I'll show you how.
And then promise you won't do it.

Compile and run this program, then minimize it.
When you do, its taskbar button flashes indefinitely
until you click on it.
The program responds to being minimzed by calling the
FlashWindowEx function asking for everything possible
(currently the caption and taskbar button)
to be flashed until the window comes to the foreground.

Other members of the FLASHWINFO structure let
you customize the flashing behavior further,
such as controlling the flash frequency and the number of flashes.
and if you really want to take control,
you can use FLASHW_ALL
and FLASHW_STOP to turn your caption and taskbar
button on and off exactly the way you want it.
(Who knows, maybe you want to send a message in Morse code.)

When you ask the debugger to set a read or write breakpoint,
the breakpoint fires only if the address is read from or written
to by the address you specify.
If the memory is mapped to another address and modified at that
other address, then your breakpoint won't see it.

The hardware breakpoint status is part of the processor context,
which is maintained on a per-thread basis.
Each thread maintains its own virtualized hardware breakpoint status.
You don't notice this in practice because debuggers are kind enough
to replicate the breakpoint state across all threads in a process
so that the breakpoint fires regardless of which thread triggers it.
But that replication typically doesn't extend beyond the process
you're debugging; the debugger doesn't bother replicating your
breakpoints into other processes!
This means that if you set a write breakpoint on a block of shared memory,
and the write occurs in some other process, your breakpoint won't fire
since it's not your process that wrote to it.

When you call into kernel mode, there is another context switch,
this time between user mode and kernel mode, and the kernel mode
context of course doesn't have your data breakpoint.
Which is a good thing, because if that data breakpoint fired
in kernel mode, how is your user-mode debugger expected to be able
to make any sense of it?
The breakpoint fired when executing code that user mode doesn't have
permission to access, and it may have fired while the kernel mode code
owned an important critical section or spinlock, a critical section
the debugger itself may very well need.
Imagine if the memory were accessed by the keyboard driver.
Oops, now your keyboard processing has been suspended.
Even worse, what if the memory were accessed by a a hardware interrupt
handler?
Hardware interrupt handlers can't even access paged memory,
much less allow user-mode code to run.

This "program being debugged takes a lock that the debugger itself needs"
issue isn't usually a problem when a user-mode debugger debugs a user-mode
process, because the locks held by a user-mode process typically affect only
that process.
If a process takes a critical section, sure that may deadlock the
process, but the debugger is not part of the process, so it doesn't care.

Of course, the "debugger is its own world" principle falls apart
if the debugger is foolish enough to require a lock that the program being
debugged also uses.
Debugger authors therefore must be careful to avoid these sorts of
cross-process dependencies.
(News flash: Writing a debugger is hard.)
You can still run into trouble if the program being debugged has
done something with global consequences
like create a fullscreen topmost window
(thereby covering the debugger)
or installed a global keyboard hook
(thereby interfering with typing).
If you've tried debugging a system service,
you may have run into this sort of cross-process deadlock.
For example, if you debug the service that is responsible for the
networking client,
and the debugger tries to access the network (for example, to load symbols),
you've created a deadlock since the debugger needs to access the network,
which it can't do because the networking service is stopped in the debugger.

Hardware debugging breakpoints are a very convenient tool for
chasing down bugs, but you have to understand their limitations.

I'm fascinated by economics, specifically the application of economic
theories to things you wouldn't normally consider as economics.
Back during the World Cup,
Slate's undercover economist column took a look at
the economics of penalty kicks.

Levitt highlighted the "anti-straight-ahead bias" of the press,
pointing out that the second Swiss shooter hit the crossbar
and was not lambasted.
But isn't that worse than shooting straight ahead and being stopped?
I mean, if you hit the crossbar, it means that the opposing goalie
didn't even have to be there.
He could've been playing Nintendo or picking his nose.
You'd think the cardinal rule of taking a penalty kick is
at least make it a shot on goal.

I know most of you know this, but I'm going to say it for the record.
When you have a dialog box with an OK and/or Cancel button,
do not give the keys accelerators.
In other words, simply write

DEFPUSHBUTTON "OK", IDOK, ...
PUSHBUTTON "Cancel", IDCANCEL, ...

The dialog manager already has those buttons covered.
The hotkey for the OK button is Enter
(since it is the default pushbutton),
and the hotkey for the Cancel button is ESC
(since its ID is IDCANCEL).

Note of course that during the lifetime of a dialog box,
the default pushbutton may change,
but the principle still stands:
Do not give the OK button a keyboard accelerator.

Oh, and while you're there, don't forget that the recommended
minimum size for pushbuttons is 50dlu by 14dlu.

Non appetit,
the modern quandary of preparing a dinner for people who
all have different types of dietary restrictions.
Depending on whom I invite to dinner, I may have to
put together a meal that conforms to one or more of the
following restrictions: low-fat, pescetarian, vegetarian, nondairy,
non-pork, non-beef.
(Yes, many of these categories overlap.)
To the best of my knowledge, none of my dinner guests have
had nut allergies or been gluten intolerant.

I remember telling a story once and mentioning that the subject of the
story was a vegetarian.
The person I was telling the story to
(who is from an older generation)
asked,
"Are they so poor that they can't afford meat?"
Because in an older era,
people were vegetarians because they had no choice.