Holy cow, I wrote a book!
When I was visiting my brother earlier this year,
in my sister-in-law's collection.
Oy vey's mir!
There's just something fundamentally wacked out about the whole idea.
(Maybe that's why I liked it.
Here's what other people think.)
the Image File Execution Options key
Its power can be used for evil as well as for good.
Its intended use is to force a program to run under a debugger
regardless of how it is launched (and secondarily to alter how
the system treats the program).
It's handy if you need to debug a program "in the wild"
rather than under the controlled environment of your favorite IDE.
For example, you can use it if you want to debug how a program
runs when it is launched by some other program you can't debug.
Two things people often forget:
Evil can be done with
the Image File Execution Options key.
Malware can install themselves as the "debugger" for a
frequently-run program (such as Explorer)
and thereby inject themselves into the execution sequence.
Note that the ability to use the Image File Execution Options key
for evil purposes is not a security hole.
To modify the key in the first place requires administrator permissions.
Consequently, anybody who can exploit this feature
already owns your machine.
Coming to the
Pacific Science Center
in September 2006
Dead Sea Scrolls,
"considered by many experts to be
the most significant archaeological find
of the twentieth century".
Tickets went on sale yesterday.
A common problem when answering technical questions is
that people sometimes ask a question that can't or shouldn't
be answered because it is based upon a misunderstanding.
What's particularly frustrating is when they insist
that you answer their question as posed,
even when you try to explain to them that their question is itself
It's as if somebody asked you the question,
"Do I have to use the remote control to lock my kangaroo?"
You could answer the question literally ("No"),
but the person asking the question would walk away with the wrong
conclusion ("Wow, kangaroos are self-locking!").
a similar analogy I made with balsa wood and nails.
Here's an example of a question that betrays misunderstanding.
I just enabled hyperthreading on my dual-Xenon machine,
and Task Manager now shows four processors instead of two.
Which of them are the physical processors and which
are the virtual ones?
When you turn on hyperthreading,
each individual physical processor acts as if it were two virtual processors.
From Task Manager's point of view, the computer has four virtual
The two virtual processors associated with each physical processor
are completely equivalent.
It's not like one is physical and one is virtual.
They are both virtual and compete equally for a share of the one
When you set processor affinities,
you set them to virtual processors.
To find out which virtual processors are associated with the same
you can call
the GetLogicalProcessorInformation function.
If you're going to try to recruit me, you might want to check
that the links in your email actually work.
I'm going to mock you regardless, but you should at least make me
have to work for it.
You probably wouldn't want to run Windows or applications
directly off your USB memory drive,
even if you could.
The reason is that the solid-state memory used by these drives
support only a limited number of write cycles per block.
(Originally measured in the thousands, though I'm led to believe
that it's gone up since then.)
Most software assume that a disk's lifetime is essentially
infinite and have no qualms about writing to a file multiple times.
For example, your program might decide to group its data in chunks.
To modify a byte of the file, you would load a chunk, modify the byte,
then write the chunk out.
You've "spent" a write cycle for an entire chunk
of data even though you really
might have been able to get away with updating a single sector.
What's more, if that one byte gets modified three times in a row,
you just paid for three writes when you could have gotten away with just one
if you had just done a little more caching.
Operating systems often update a file's metadata with high frequency.
The last-modified time on a directory entry gets rewritten each time
the file is updated.
The free block bitmap is updated each time disk space is allocated
The page file gets updated constantly.
A database application will update its database index very frequently.
Even a simple application will probably update its history and
settings files often.
These "hot spots" are most likely to wear out first
on a drive.
Unfortunately, these hot spots also tend to coincide with nonrelocatable
critical file system metadata;
as a result,
once the sector responsible for, say, the free cluster table goes bad,
the drive is useless (in the absence of hardware sector remapping).
I know some people who wrote a so-called
"Flash File System" specifically designed for this class of devices.
It spread the writes out across the disk so that it wore uniformly,
avoiding the "hot spot" problem.
The file system came out in the early 1990's and promptly died because
the hardware hadn't yet caught up to the software.
It was a solution ahead of its time.
Note that my information about the number of write cycles of
flash memory is pretty old.
Can modern USB drives handle millions of writes before wearing out?
hand-cranked radios and other electronica
a while ago.
an old-model Freeplay flashlight
in the trunk of my car.
It sort of fits the whole energy-counter-culture ethos,
since I drive an early-model Toyota Prius.
Freeplay is a South African company, and one of my
South African colleagues pointed out that the Freeplay devices
sold in South Africa are heavier than the ones sold in the
Not for any technical reason, mind you.
It's psychological, I'm told.
Apparently, in South Africa,
you want your equipment to be good and heavy,
since that makes it seem solid and dependable.
When I was in London a few years ago,
I joined a friend in a day trip to the
Victoria and Albert Museum.
The museum is far too large for you even to pretend to see it all
so we created for ourselves a one-day tour on the theme
"The history of British furniture from 1500 to the present".
Yeah, it sounds stupid on paper, but it was actually quite fun.
(We saw how the British were fond of Japanese teacups but couldn't
get over the fact that they don't have handles.
They solved this problem by building a metal cage with a handle;
into the cage was placed the teacup. Now you can drink your tea
out of the lovely Japanese teacup with the added civility of a proper
Yet for some reason, this didn't catch on in Japan.)
When we got to the late twentieth century, one of the items
on display was... a Freeplay radio.
MSDN documentation for
[T]he implementation of GetHashCode provided by the String class
returns unique hash codes for unique string values.
This is another case of ambiguous use of the word "unique".
The intended meaning is
"for each string value, the same hash code is returned".
Even though "unique" means "one and only one",
the domain in which the term applies is often left unsaid,
as here, where the domain of comparison is
"all the hash codes returned for a specific string value".
If you instead misinterpreted the domain as "all the hash
codes returned for all string values", then you end up erroneously
concluding that no two strings hash to the same value.
Another conflicting sense of "unique" is
"you get the same one each time"
as opposed to "you get a different one each time".
In the original C standard,
malloc(0) is permitted to return NULL
or "a unique pointer".
What does "unique" mean here?
Does it mean that the non-NULL return value is always the same?
Can I assert(malloc(0) == malloc(0))?
Or does it mean that the non-NULL return value
is a value distinct from any other return value from malloc()?
assert(malloc(0) == malloc(0))
In Technical Corrigendum 1,
this ambiguity was resolved by removing the word "unique".
Instead, the specification says "as if the size were some nonzero value"
which makes it clear that it is the second interpretation that is intended.
My suggestion: Don't use the word "unique". It's too ambiguous.
Every so often,
somebody will spam all the Microsoft blogs with a survey
or a plea for a job or some other boilerplate message.
Don't think you're fooling anyone.
It's not like each blogger lives in a separate world and
never talks to anyone else.
In reality, we exchange information quite freely
and even occasionally get together—usually under the aegis of our
overworked leader Betsy—for an
lubricated with beer).
Which reminds me: That April get-together was held at
and at some point during the evening, I excused myself
and went into the main part of the pub.
I headed for what appeared to be a promising hallway,
but which instead was merely a large wall covered in
I scanned the wall for a few seconds,
then someone walking past said to me,
"It's over there, through that room, on your left."
I found it intriguing that the gentleman knew exactly what
I was looking for based on the fact that I was staring
at a wall at the edge of a bar near the kitchen entrance.
Here are some airline-related web logs that I follow.
a web site for all your planespotting needs.