Holy cow, I wrote a book!
is a family affair at Microsoft.
It typically starts at around 3 or 4 o'clock,
with costumed kids roaming the hallways collecting treats from offices.
One year, one of my colleagues
decided that the kids deserved more than the
usual candy bars and chocolates.
Even though he is Caucasian,
he went to
the local Asian foods market
and stocked up on all sorts of Asian candies.
spiced watermelon seeds,
you name it.
It's a holiday and a cultural learning experience.
He dumped all the candies into a big bowl and set them out for the kids.
The kids didn't quite know what to make of it.
They'd knock on the door, say Trick or Treat,
reach for the bowl and... freeze, or possibly even recoil.
"It's okay, Johnny. Just take one,"
Johnny's parents cajoled.
Little Johnny remained unconvinced.
Many kids would hesitantly pick out a candy.
Some would back away slowly and move to the next office.
One reaction came from some teenage girls who said
(probably in reaction to the rice crackers),
"You cheapskate! You just went to the cafeteria and took some
He was unable to convince them that, no, these aren't soup crackers;
they're Asian candy.
The day wound down, and my friend still had a lot of candy left over.
I wandered over to check on him and brought another Caucasian colleague
(let's call him Bob)
so we could marvel at what those wacky Asians consider candy.
We sifted through the bowl, and Bob shouted out,
"Hey, I remember these!"
My friend and I were kind of surprised that Bob recognized an obscure
"Yeah, I had a Chinese roommate in college,
and he would sometimes eat these."
Bob cracked open the package and popped one into his mouth.
"Yup, it's the same stuff. I wonder what it is."
We looked at the package. It identified itself as
What are haw flakes?
We didn't know.
Maybe the ingredients panel will give us a clue.
"Ingredients: Haw, sugar."
Okay, that didn't help much.
From then on, my friend bought the normal candy to give out on Hallowe'en.
Public Service Announcement:
Daylight Saving Time ends in most parts of the United States
I pointed out
some time ago
that Win32 and .NET deal with daylight saving time differently.
Specifically, Win32 always deals with the time zone you are currently in
(even if it's not the time zone that corresponds to the timestamp
you are manipulating),
whereas .NET deals with the time zone that was in effect at the time
the timestamp was generated.
For more details on the latter, I refer you to
Josh Free from
the BCL Team Blog,
who some time ago
how to work with ambiguous and invalid points in time
in managed code.
Short stories from the 2008 PDC:
Bonus chatter added 9am:
I spend a good amount of my time doing source code archaeology,
and one thing that really muddles the historical record is
people who start with a small source code change which turns
into large-scale source code reformatting.
I don't care how you format your source code.
It's your source code.
And your team might decide to change styles at some point.
For example, your original style guide may have been designed
for the classic version of the C language,
and you want to switch to a style guide
designed for C++ and its new // single-line comments.
Your new style guide may choose to use spaces instead of tabs
or it may dictate that opening braces go on the next line
rather than hanging out at the end of the previous line,
or you may have a new convention for names of member variables.
Maybe your XML style guidelines changed from using
<element attribute1="value1" attribute2="value2" />
Whatever your changes are, go nuts.
All I ask is that you restrict them to
In other words, if you want to do some source code reformatting
and change some code,
please split it up into two check-ins,
one that does the reformatting and the other that changes the code.
Otherwise, I end up staring at a diff of 1500 changed lines of source code,
1498 of which are just reformatting,
and 2 of which actually changed something.
Finding those two lines is not fun.
And the next time somebody is asked to do some code archaeology,
say to determine exactly when a particular change in behavior occurred,
or to give an assessment of how risky it would be to port a change,
the person who is invited to undertake the investigation may not be me.
It may very well be you.
Today is the day of
I'm always a bit nervous before these things,
because I'm never sure if what I'm going to present matches up with
what people are expecting.
Most people who come to my PDC talk don't know who I am,
so they aren't expecting me to toss out a few catch phrases,
use my psychic powers,
and tell stories about how a bug in a 16-bit scanner driver written in 1993
is the reason why TCP/IP is so complicated.
(That last part was
"I don't know what happened, but now when I open the Run dialog
on my Windows Vista machine by typing Windows+R,
there is a shield under the edit box that says
This task will be created with administrative privileges.
What's going on?"
One my colleagues used psychic powers to solve this problem:
"I imagine that you manually killed Explorer,
and then you used an elevated command prompt or an elevated
Task Manager to launch a new one.
An elevated Explorer shows this message.
To fix it, exit your elevated Explorer, and exit your running
elevated copy of Task Manager (if any).
Then type Ctrl+Alt+Esc to launch a normal (non-elevated) Task Manager
and use File, New Task to run a new un-elevated Explorer."
My colleague's psychic powers were right on target.
"Your psychic powers are better than my memory.
I now recall that I did kill and restart Explorer when debugging
my shell extension, and I did so from a command line,
which—given the evidence—must have been an elevated
Typo patrol got off to a very quick start.
One of the flyers in the attendee goodie bag
is from a company which offers two free months of service
to PDC attendees.
The first step in obtaining the service is
"Just signup and mention the PDC by January 31, 2008."
Okay, just hang on while I fire up my time machine.
Bonus grammar typo: signup is a noun;
sign up is a verb.
The second typo is kind of important.
In all the PDC documents
the voucher to pick up your attendee goodie bag),
it says to go to Kentia Hall.
This is incorrect.
If you try, you'll find a locked door.
The goodie bags (and all other Kentia-related services)
are actually in Parking B,
which is next to the south entrance to Kentia Hall.
Other PDC 2008 notes:
told me about
a trick she learned to get an area expert to respond to her email,
I cautioned her that the trick might backfire:
A friend of mine (let's call him Bob)
happens also to work in the technology industry,
and the manager for the part of the project he worked on
was, to put it nicely,
"in the wrong line of work."
No matter how many times Bob would explain how the system worked
on the whiteboard, his manager never really understood it.
And the misunderstandings weren't just of the
"oh I missed a little detail" variety;
rather, they tended to elicit a "What planet are you from?" sort of reaction.
Bob spent many impromptu meetings
patiently trying to clear up various degrees
of confusion or explaining why some clever new idea won't work because
violates the laws of physics as we currently understand them.
One day, the manager sent out a plan to a large group of people,
including some senior managers,
and included in the email one of those "Huh?" questions,
something akin to
"... and it'll connect to the server wirelessly through the
parallel port, and—hey Bob, inkjet printers can run off
the parallel port, right?"
Bob decided that he'd had enough.
He replied to the mail thread with a simple,
"Yes, inkjet printers can run off the parallel port."
Somebody else in the group gave Bob a phone call.
"Um, Bob, what do inkjet printers have to do with anything?"
Bob answered, "Just making sure there's enough rope."
Bob's colleague replied, "Gotcha."
The manager's tenure ended a few months later.
Sitting in my hotel room the night before the 2008 PDC,
I'm watching the Los Angeles local news, and the field reporter
"The police say this is an isolated incident,
but it could happen anywhere."
When I wrote about
understanding the consequences of WAIT_ABANDONED,
I mentioned that one of the possible responses was to try to repair
but some people are
suspicious of this approach.
Mind you, I'm suspicious of it, too.
Repairing corruption is hard.
You have to anticipate the possibility,
create enough of a trail to be able to reconstruct the original data
once the corruption is recognized,
and then be able to restore the data to some semblance of consistency.
I didn't say that this was mandatory;
I didn't even say that it was recommended.
I just listed it as one of the options,
an option for the over-achievers out there.
For most cases, attempting repair is overkill.
But you still have to know that something went wrong;
otherwise, one crashed program will lead to more crashed programs
as they try to operate on inconsistent data.
The purpose of the article was to raise awareness of the issue,
based on my observation that most people blindly ignore the
possibility that the mutex was abandoned.