Holy cow, I wrote a book!
The United States government authorized a
one-time refund of long-distance
excise taxes paid between March 2003 and July 2006,
but early returns suggest that many taxpayers are unaware of this refund.
the IRS press release that goes into more detail
and includes a list of most common mistakes people have been making.)
The easy way to claim this is merely to take the standard deduction
the hard way is to collect all your telephone bills from that period
and compute how much long distance excise tax you actually paid.
This entry also illustrates how all the nitpicking from commenters
over the years has altered the way I write,
forcing me to put all sorts of clarifying information into the
subject line—making it rather unwieldy—so that
people won't carp about how the entry applies
only to United States income taxes.
Remember when blogs were an informal communication mechanism?
Where you could leave mathematical precision behind,
relying on your readers to fill in the gaps?
When you could toss together a sample program without people
obsessing over the grayscale algorithm you used?
Or use phrases like "regular people like you and me"
taken to task for implying that other people aren't regular?
I miss those days.
Blogging isn't all that much fun now;
it's more of a chore.
(And I predict that somebody is going to nitpick my article and
lambaste me for missing the fact that the
exact amount of the refund varies depending on how
many exemptions you claim.
So here's the disclaimer:
This entry is provided for informational purposes only and
should not be construed as providing tax advice.
Consult with an attorney or tax professonal regarding any specific
legal or tax situation.)
A commenter asked,
"As an application programmer,
can I really ignore DDE if I need to interact with explorer/shell?"
The answer is, "Yes, please!"
While it was a reasonable solution
back in the cooperatively-multitasked world of 16-bit Windows
where it was invented,
the transition to 32-bit Windows was not a nice one for DDE.
the reliance on broadcasts
to establish the initial
DDE conversation means that unresponsive programs can jam up
the entire DDE initiation process.
The last shell interface to employ DDE was the communication
with Program Manager to create program groups and items inside
This was replaced with Explorer and the Start menu back in
DDE has been dead as a shell interface for over ten years.
Of course, for backwards compatibility,
the shell still supports DDE
for older programs that choose to use it.
You can still create icons on the Start menu via DDE and
you can still register your documents to launch via DDE
if you really want to,
but if you take a pass on DDE you won't be missing anything.
On the other hand, even though there is no technological reason
for you to use DDE, you still have to be mindful of whether your
actions will interfere with other people who choose to:
If you stop processing messages, you will clog up DDE initiation,
among other things.
It's like driving an automatic transmission instead of a manual
There is no requirement (in the United States, at least)
that you own a manual transmission or even know how to operate one.
But you still have to know to ensure that your actions do not interfere
with people who do have manual transmissions,
such as watching out for cars waiting for the traffic light to change
while pointed uphill.
I post this entry with great reluctance, because I can feel the
heat from the pilot lights of the flame throwers all the way from here.
The struggle with the network interoperability problem continued
for several months after
I brought up the topic.
In that time, a
significant number of network attached storage devices
were found that did not implement "fast mode" queries correctly.
(Buried in this query are some of them; there are others.)
Some of them were Samba-based whose vendors did not have an upgrade
available that fixed the bug.
But many of them used custom implementations of CIFS;
consequently, any Samba-specific solutions would not have helped
(Most of the auto-detection suggestions
people proposed addressed only the Samba scenario.
Those non-Samba devices would still not have worked.)
Even worse, most of the devices are low-cost solutions which
aren't firmware-upgradable or have any vendor support.
Some of the reports came from people running fully-patched well-known
So much for being in
all the new commercially supported offerings over the next couple months.
Furthermore, those buggy non-Samba implementations mishandled fast mode
queries in different ways.
For example, one of them I was asked to look at didn't return
any error codes at all.
It just returned garbage data (most noticeably,
corrupting the file name by deleting the first five characters).
How do you detect that this has happened?
If the server reports "I have a file called e.txt",
is Windows supposed to say, "Oh, I don't think so. I bet you're
one of those buggy servers that chops off the first five letters
of file names and that you really meant to say (scrunches forehead
in concentration) readme.txt"?
What if you really had a file called e.txt?
What if the server said, "This directory has two files, 1.txt
Is this a buggy server?
Maybe the files are really abcde1.txt and defgh2.txt,
or maybe the server wasn't lying and the files really are
1.txt and 2.txt.
One device simply crashed if asked to perform a fast mode query.
Another wedged up and had to be reset.
"Oh, looks like somebody brought their Vista laptop from home
and plugged it into the corporate network.
Our document server crashed again."
Given the much broader ways that servers mishandled fast queries,
any attempt at auto-detecting them will necessarily be incomplete
and fail to detect broken servers.
This is fundamentally the case for servers which return perfectly
formed, but incorrect, data.
And even if the detection were perfect, if it left the server in
a crashed or hung state, that wouldn't be much consolation.
Given this new information, the solution that was settled on was
simply to stop using "fast mode" queries for anything other than
The most popular
file system drivers for local devices (NTFS, FAT, CDFS, UDF)
are all under Microsoft's control and they have already been tested
with fast mode queries.
Such is the sad but all-too-true
cost of interoperability and compatibility.
(To address other minor points:
It's not the case that the Vista developers
"knew the [fast mode query] would break Samba-based devices since
The fast mode query was added, and the incompatibility with Samba
wasn't discovered until March 2006.
"Why didn't you notify the Samba team?"
Because by the time we found the problem,
they had already fixed it.)
If you try to set the current directory of a command prompt, you
get the error message
"CMD does not support UNC paths as current directories."
What's going on here?
It's MS-DOS backwards compatibility.
If the current directory were a UNC,
there wouldn't be anything to return to
MS-DOS programs when they call function 19h (Get current drive).
That function has no way to return an error code,
so you have to return a drive letter.
UNCs don't have a drive letter.
You can work around this behavior by using the pushd
command to create a temporary drive letter for the UNC.
Instead of passing script.cmd to the
CreateProcess function as the lpCommandLine,
you can pass
cmd.exe /c pushd \\server\share && script.cmd.
cmd.exe /c pushd \\server\share && script.cmd
(Griping that seems to happen any time I write about batch files,
so I'll gripe them pre-emptively:
Yes, the batch "language" sucks because it wasn't designed;
it just evolved.
I write this not because I expect you to enjoy writing batch files
but because you might find yourself forced to deal with them.
If you would rather abandon batch files and use a different command
interpreter altogether, then more power to you.)
One of my colleagues recently posted the story of
the work he did to get laptops to resume quickly.
The fun part was implementing the optimizations in the kernel.
The not-fun part was finding all the drivers who did bad things
and harassing their owners into fixing the bugs.
One some laptops, he could get the resume time down to an impressive
And then entropy set in.
It's likely you've never seen a real off-the-shelf laptop resume this quickly.
And the reason is that as soon as you stop twisting the arms of
all the driver writers,
they stop worrying about how fast your laptop resumes
and go back to worrying about when they can get their
widget driver mostly working so they can get through WHQL
and sell their widget.
But now you have some tools to fight back, at least a little bit.
The second half of that article explains how to use
the event viewer to track down which drivers are ruining your
resume time and disable them.
They've been nicknamed the sushi police.
In response to horror stories from Japanese travelling abroad
and being shocked by what passes for Japanese food outside their
the Japanese agriculture ministry is developing certification standards
for restaurants abroad that want to call themselves Japanese.
Their results are supposed to be out at the end of this month
with inspections to begin in April.
You can't say that the Japanese aren't looking out for the psyche
of their citizens abroad.
(But if they've made the effort to travel to another country,
shouldn't they be eating the local food instead of Japanese food?)
The ironic thing about fixing a bug,
or at least once I mention on this web site that I fixed a particular bug,
is that people immediately
complain that I
some other bug.
One school of complaint believes that cosmetic bugs should be fixed first:
"You suck. I mean, look at these egregious cosmetic bugs.
If you can't get even those right,
then obviously you can't get the other stuff right either."
The opposite school believes that cosmetic bugs should be fixed last:
"You suck. I mean, why are you fixing cosmetic bugs
when there are these other bugs!"
I think I'd be better off if I said I didn't fix any bugs at all.
Now that you understand the intended purpose of
I'm going to tell you why you don't want to use it,
not even for its intended purpose!
You have to go back to the historical context in which
LockWindowUpdate was created.
Rewind back to 16-bit Windows, specifically Windows 3.1.
Back in these days, memory was expensive.
Video drivers were pretty limited in functionality.
There was no DirectX.
There was no AlphaBlend function.
All you had was a screen buffer.
The LockWindowUpdate function let you take
control over one window's portion of that screen buffer
so you could apply your fancy effects to the window
without that window's knowledge.
It's been over a decade since Windows 3.1,
and in the meanwhile, we gained DirectX overlays,
regional windows, layered windows, alpha blending,
all sorts of cool graphical effects that weren't available
back in the old days.
In particular, those layered windows and regional windows
pretty much let you do nearly all of the stuff you would have wanted to
do with LockWindowUpdate anyway.
If you want to draw a highlight around a window,
you can position a regional window around it.
If you want to draw a drag image over a window,
you can just create layered window and position it over
the target window.
Give the layered window a region and whatever fancy alpha
channel you want, and let the graphics engine do the heavy
lifting of alpha blending and composition.
Even better, the layered window can extend outside the window
you are dragging over, something that
LockWindowUpdate can't do.
(You can see this effect in Windows XP if you do a "select all"
in an Explorer window and drag the entire selection around the screen.
Notice that the drag image is not constrained to the boundaries of
the window you are dragging over.)
What's more, in the exciting new composited world of Vista's
desktop window manager,
LockWindowUpdate is even less desirable.
Locking a particular window for update isn't so bad
since the desktop window manager can just give you the
backing bitmap for the window.
But if you lock the entire screen
(which I've seen may people do),
the desktop window manager needs to compose all of the
windows into an actual bitmap that it can give
you when you call GetDCEx with the
The desktop window manager does composition on the fly
with the help of DirectX and accelerated video drivers.
The result of all this composition normally goes straight
to the screen without actually residing in a "composited"
But if you lock the screen and ask for a DC to it,
the desktop window manager needs to emulate the old
behavior and give you access to something that represents
what you would have gotten if there were no
composition in the first place.
That ain't cheap.
Epilogue. I'm not sure if this series was a success or not.
My goal was just to help people use LockWindowUpdate
more effectively and guide them towards alternatives when
LockWindowUpdate is the wrong tool for the job.
In other words, it's an article about LockWindowUpdate,
not function documentation.
I tried to keep the presentation light,
but I guess my jokes fell flat,
and people just used them as a springboard for negative comments.
And extra thanks to the people who took it as an opportunity to
complain about the documentation.
I mean, duh, if the documentation were perfect,
I wouldn't have written this series in the first place.
Though these people also neglected to read all of the
documentation; they looked only at the function description page.
There's more to documentation than dry function descriptions, people!
The function description is a reference; you go there when
you already know what's going on and you just need to fine-tune a detail.
The real learning happens in the overviews and articles.
If you want to learn how to operate your radio,
you don't read the schematic first.
I think Ronald D. Moore is really onto something when he says,
"You have to be tough enough to listen to the podcast."
I learned this from Yes, Minister.
They call it the politician's fallacy:
As befits its name, you see it most often in politics,
where poorly-thought-out solutions are proposed for
But be on the lookout for it in other places, too.
You might see somebody falling victim to the politician's
fallacy at a business meeting, say.
Something else I picked up is what I'm going to call
the politician's apology.
This is where you apologize for a misdeed not by apologizing
for what you did, but rather apologizing that other people
One blogger coined the word "fauxpology" to describe this sort of
In other words, you're not apologizing at all!
It's like the childhood non-apology.
"Apologize to your sister for calling her ugly."
"I'm sorry you're ugly."
In the politician's apology, you apologize
not for the offense itself,
but for the fact that what you did offended someone.
"I'm sorry you're a hypersensitive crybaby."
regretted any hurt feelings
his statements may have caused.
Another form of non-apology is to state that bad things happened
without taking responsibility for causing them:
There should not have been any physical contact in this incident.
I am sorry that this misunderstanding happened at all,
I regret its escalation
and I apologize.
This particular non-apology even begins with the accusation that the
other party was at fault for starting the incident!
What bothers me is that these types of non-apologies are so common
that nobody is even offended by their inadequacy.
They are accepted as just
"the way people apologize in public".
(It's become so standard that Slate's William Saletan has
broken it down into steps for us.)
In Windows 95,
if you had a shortcut to a file on the desktop, view the shortcut's
properties, and then clicked "Find Target",
you got the message
"The target you specified is on the desktop".
It also selected the item on the desktop to help you find it.
But why didn't it just open an Explorer window that viewed the desktop?
Because in Windows 95, you couldn't display the desktop in an
The only way to see the desktop was to minimize all your application
There wasn't a "Show Desktop" button in Windows 95 either.
Therefore, the shortcut property sheet did as much as it could:
It highlighted the item on the desktop, but it couldn't open
Explorer or show the desktop.
Instead, it just told you "Hey, it's on your desktop,"
with an implied, "I took you as far as I could, sorry."
Fortunately, the inability to show the desktop in an Explorer
window was removed in later versions of Windows, and the strange
dialog box disappeared as well.