Holy cow, I wrote a book!
While wasting time doing valuable background
research on my computer,
I received the following suggestion:
For enchanced video quality,
It's good to know that
the typo that I first encountered in 1993
is still alive and kicking.
(And even though it's not important to the story, people will demand
some sort of follow-up, so here it is:
I submitted feedback to the vendor, who said that it was a known
issue fixed in the next update.)
was curious why
it takes longer for Task Manager to appear when you start it
from the Ctrl+Alt+Del dialog
compared to launching it from the taskbar.
Well, you can see the reason right there on the screen:
You're launching it the long way around.
If you launch Task Manager from the taskbar,
Explorer just launches taskmgr.exe
via the usual CreateProcess mechanism,
and Task Manager launches under the same credentials
on the same desktop.
On the other hand, when you use the secure attention sequence,
the winlogon program receives the notification,
switches to the secure desktop,
and displays the Ctrl+Alt+Del dialog.
When you select Task Manager from that dialog,
it then has to launch taskmgr.exe,
but it can't use the normal CreateProcess
because it's on the wrong desktop and it's running under
the wrong security context.
(Because winlogon runs as SYSTEM,
as Task Manager will tell you.)
Clearly, in order to get Task Manager running on your desktop
with your credentials,
winlogon needs to change its security context,
change desktops, and then launch taskmgr.exe.
The desktop switch is probably the slowest part, since it
involves the video driver,
and video drivers are not known for their blazingly fast
It's like asking why an international package takes longer to deliver
than a domestic one.
Because it's starting from further away, and it also has to go through
A customer designed a system which uses shared memory.
Specifically, for each database file, they create a corresponding
shared memory block of, say,
Multiple clients which connect to the same database file use
the same shared memory block.
Naturally, if two processes each access the same database file,
each process will map the shared memory block into their respective
The question arose regarding what happens if one process
connects to the same database file twice.
Will the two calls to MapViewOfFile
share the same address space, or will each one allocate a separate
chunk of address space?
Win32 makes no guarantees what will happen.
All that you can be sure of is that the memory will be mapped
into your address space, and you will get a pointer to it,
and when you're done, you call UnmapViewOfFile.
Whether the two calls return the same pointer is unspecified.
In fact, Windows 95 returned the same pointer,
whereas Windows NT returns a different pointer.
We saw this earlier when we intentionally
mapped the same shared memory block multiple times,
and observed somebody actually taking a dependency on this behavior
in order to effect
the strangest way of detecting Windows NT.
Don't take a dependency on this behavior;
who knows, maybe a future version of Windows NT will
consolidate multiple mappings in order to conserve address space.
If you want force this consolidation behavior, you'll have to
roll it yourself,
say with a lookup table of active mappings and a reference count.
I put together a
little pocket guide
to the Seattle Symphony
for my symphony friends to help them decide which
ticket package they want.
As before, you might find it helpful, you might not, but either way,
you're going to have to suffer through it.
Here's the at-a-glance season guide for the 2012/2013 season.
Seattle Times coverage.)
For those not familiar with the Seattle Symphony ticket package line-ups:
Most of the ticket packages are named Masterworks nX where
the number is the number of concerts in the package, and the letter
indicates which variation.
Ticket packages have been combined if they are
identical save for the day of the week.
For example, 7C and 7D are the same concerts;
the only difference is that 7C is for Thursday nights, while 7D is
for Saturday nights.
The Beyond the Score concerts focus on only one of the pieces.
The WolfGang series is available only to members of the
This chart doesn't include "one-off" concert series such
as the Mainly Mozart or Distinguished Artists series.
A "one-off" series is a concert series which shares no concerts
with any other series.
Changes from last season:
The comments column very crudely categorizes the works
to assist my less-classically-aware friends.
This is, of course, a highly subjective rating system,
but I tried to view each piece from the ears of my symphony friends.
Thus, I rated downward pieces that I personally like
but which others might not and rated up pieces that I may not
find musically satisfying but which nevertheless tend to be
These predictions have, of course, proven wrong in the past.
Here's what the comments mean.
Note that they do not indicate whether the piece is significant in
a musicological sense; they're just my guess as to whether my friends
are going to like it.
I know that my friends don't like minimalism,
and I suspect they don't like serialism,
so I rated the Adams and Berg down even though I think they're quite good.
They also don't like vocal pieces.
On the other hand, it turns out that I overcame my
so I can at least give the Bruckner a positive score this time.
Let's just hope it's
not the Hass edition.)
In many cases, I am not familiar with the piece
and am basing my evaluation on what I know about the composer
(or am just guessing).
You may have noticed a minor inconsistency between pinning a program
to the Start menu and pinning a destination to a program's
Although pinned items appear at the top of the respective lists,
and both the Start menu and Jump List let you right-click an
item and select Pin/Unpin,
the Jump List also lets you pin and unpin an item by clicking on the
Why doesn't the Start menu have a pushpin in addition to the
For a time, items on the Start menu did have a pushpin,
just like items on Jump Lists.
The design had a few problems, however.
Start menu items can also have a triangle
indicating the presence of a flyout menu,
and the presence of two indicators next to an item made the interface
look awkward and too busy.
And what do you do if an item has only one indicator?
Do you right-justify all the indicators?
Or do you place the indicators in columns and reserve blank
space for the missing ones?
Both look ugly for different reasons.
The right-justify-everything version looks ugly because the pushpin
appears to keep moving around.
The blank-space-if-no-flyout version looks ugly because you have
a pushpin hovering in the middle of nowhere.
(Imagine trying to click on one of these things: You just have
to "know" that the magic click spot for pinning an item
is 20 pixels to the left of the far right edge.)
But the real death blow to showing a pushpin for pinning items
to the Start menu was the usability testing.
Users had trouble figuring out where to click to pin an item
or to open the Jump List and frequently got the opposite of what
Since opening the Jump List is by far the more common operation,
it won the battle of the prominent UI affordance,
and the option for pinning and unpinning was left to a context
Which, as it happens, is where the pin/unpin option started
in the first place.
A while back, I
a talk by Silviu Calinoiu
the fault-tolerant heap.
But what if you don't want the fault-tolerant heap?
during program development, you probably want to disable
the fault-tolerant heap for your program:
If the program is crashing, then it should crash
so you can debug it!
disable the fault-tolerant heap globally.
While this prevents the fault-tolerant heap from auto-activating
in the future,
it does not go back and undo activations that were enabled in the past.
In other words, you have to remember to do this before
your application crashes for the first time.
Therefore, you probably want to combine Method 1 with
Method 2 on the same page,
where it gives instructions on how to
reset the list of applications for which the fault-tolerant heap
Mario Raccagni provides a third way of disabling
the fault tolerant heap, this time for one specific process
instead of globally.
His explanation is in Italian,
so you get to exercise your translation skills.
tl;dr version: Go to the
HKEY_CURRENT_USER versions of
and delete the FaultTolerantHeap entry.
As I noted when I told the story of
the computer programmer who dabbled in making change
that my colleague had a lot of money-related quirks.
For some reason my colleague felt the $2 bill deserved more attention.
Every so often, he would go to the bank and buy $100 in $2 bills,
then reintroduce the bills into circulation and enjoy people's
reactions to them.
(Most cashiers looked at it and recognized that it was legal tender,
but couldn't find a good place to put it in the till.
It usually got tossed under the drawer with all the checks.)
It was a regular occurrence that
the bank didn't have that many $2 bills on hand, but they
managed to find them and let him know when he could come pick them up.
One time, the bank called him back.
"Hi, we asked all our branches in the entire county, but all together
we can't find enough $2 bills.
If you want, we can place an order with the Federal Reserve.
The catch is, though, that the minimum order is $2000."
"Sure, go ahead and place the order."
Some time later, he went in to pick up his huge stack of $2 bills.
My colleague now found himself in a situation where something fun
turned into an ordeal,
like a smoker who is forced to smoke an entire pack of cigarettes at
Or in this case, more like 1000 cigarettes.
At the end of group meals at a restaurant,
after everybody had calculated their share
and put their money in the bill holder
(this being the days when people
actually paid cash for things),
he would raid the bill holder for change,
taking out all the notes greater than $2 and replacing them with the
appropriate number of $2 bills.
As a result, when the servers came to collect the bill holders,
they found them stuffed with $1 and $2 bills (mostly $2).
Too bad he didn't
make a pad out of them.
$1 billion that nobody wants.
Friday asks whether
OANOCACHE can be used for non-debug purposes, say
to improve stability and/or speed.
You can try, but it's not recommended.
For one thing, it probably damages stability,
because there are many applications out there which unwittingly rely
on the BSTR cache to protect them from heap corruption bugs.
The Windows team has for years wanted to tweak the BSTR cache
(even going so far as getting rid of it entirely),
but the compatibility issues always return and quash any
attempts at radical restructuring.
Identifying applications that rely on the BSTR cache and
deploying an appropriate compatibility shim would be one thing.
It's applications which support third party plug-ins that
are the sticky point.
You say, "Okay, this application is fine, we'll use the new
BSTR cache behavior" and then it loads a plug-in DLL that
requires the old BSTR cache behavior.
Now you're stuck since you don't have a time machine.
There are two flags you can pass to the
CreateFile function to provide hints regarding
your program's file access pattern.
What happens if you pass either of them, or neither?
Note that the following description is not contractual.
It's just an explanation of the current heuristics (where "current"
means "Windows 7").
These heuristics have changed at each version of Windows,
so consider this information as a tip to help you choose an appropriate
access pattern flag in your program,
not a guarantee that the cache manager will behave in a specific way
if you do a specific thing.
If you pass the
flag, then the cache manager alters its behavior in two ways:
First, the amount of prefetch is doubled compared to what it would have been
if you hadn't passed the flag.
Second, the cache manager marks as available for re-use
those cache pages which
lie entirely behind the current file pointer (assuming there are no other
applications using the file).
After all, by saying that you are accessing the file sequentially,
you're promising that the file pointer will always move forward.
At the opposite extreme is
In the random access case,
the cache manager performs no prefetching, and it does not
aggressively evict pages that lie behind the file pointer.
Those pages (as well as the pages that lie ahead of the file pointer
which you already read from or wrote to) will age out of the cache according
to the usual most-recently-used policy,
which means that heavy random reads against a file will not pollute the
cache (the new pages will replace the old ones).
In between is the case where you pass neither flag.
If you pass neither flag, then the cache manager tries to detect
your program's file access pattern.
This is where things get weird.
If you issue a read that begins where the previous read left off,
then the cache manager performs some prefetching, but not as much
as if you had passed
If sequential access is detected, then pages behind the file pointer
are also evicted from the cache.
If you issue around six reads in a row, each of which begins where the
previous one left off, then the cache manager
for your file,
but once you issue a read that no longer begins where the previous
read left off, the cache manager revokes your
If your reads are not sequential, but they still follow a pattern where
the file offset changes by the same amount between each operation
(for example, you seek to position 100,000 and read some data,
then seek to position 150,000 and read some data,
then seek to position 200,000 and read some data),
then the cache manager will use that pattern to predict the next read.
In the above example, the cache manager will predict that your next
read will begin at position 250,000.
(This prediction works for decreasing offsets, too!)
As with auto-detected sequential scans,
the prediction stops as soon as you break the pattern.
Since people like charts, here's a summary of the above
in tabular form:
There are some question marks in the above table where I'm not
sure exactly what the answer is.
These cache hints apply only if you use
ReadFile (or moral equivalents).
Memory-mapped file access does not go through the cache manager,
and consequently these cache hints have no effect.
As is common in many industries,
Microsoft customer service records employ abbreviations for
many commonly-used words.
In the travel industry, for example, pax is used as
an abbreviation for passenger.
The term appears to have spread to the
even though people who stay at a hotel aren't technically
(Well, unless you think that with the outrageous
prices charged by the hotels, the people are being
taken for a ride.)
For a time, the standard abbreviation for customer
in Microsoft's customer service records was cu.
This changed, however, when it was pointed out to the people
in charge of such things that cu is a swear word in
The standard abbreviation was therefore changed to cx.
If you're reading through old customer records and you know
Portuguese and you see the word cu, please understand
that we are not calling the customer a rude name.
The person who introduced me to this abbreviation added,
"I just spell out the word. It's not that much more work,
and it's a lot easier to read."
Some years ago, I was asked to review a technical book,
and one of the items of feedback I returned was that
the comments in the code fragments were full of
"Sgnl evt before lv cs."
I suggested that the words be spelled out or,
if you really want to use abbreviations,
at least have somewhere in the text where the abbreviations
If I had wanted to demonstrate the social skills of a thermonuclear
my feedback might have read
"unls wrtg pzl bk, avd unxplnd n unnec abbvs."