Last night, I was privileged to be able to go to my son's school and listen to Ben Mikaelsen speak. Ben's an author of children's books (really YA, but they're incredibly sophisticated for YA books), and he lives in Montana with his companion Buffy - an 800 pound bear.
Ben's an absolutely amazing speaker, he spoke on his childhood, the people who affected him the most as a kid, and his other life experiences working as a writer. He grew up in Guatamala, during the revolutions (he talked about using sticks to poke the dead bodies on the street)), . Eventually he moved to the US as a functionally illiterate 7th grader, where he was turned onto reading by a librararian.
Ben's had an amazing life. I loved hearing the backstory behind some of his books.
It was absolutely wild listening to him recount his experiences in Space Camp (doing research for his book Countdown). The story of how he met the only surviving German scientist of the 500 who came from Germany with Werner von Braun (unfortunately, I missed the scientist's name) was amazing. To paraphrase one part: You know how, when you go to visit people, they take out their photo albums, and show you all the pictures of their trip to Disneyland? "Look - here's me in front of Space Mountain" "Look, here's me with Mickey!" "Look, here's me with Goofy!". Well this guy opened up his snapshot album and took out the pictures. "Look, here's me with a V2 rocket. I worked on the avionics for that one. If we'd had just a couple more months to work on it, we could have changed the world" "Look, here's me with my fuhrer - he did so many bad things, I'll never sleep at night because of the thigns he did" "Look, here's me with president Kennedy. Such a shame, he died too early".
I am so utterly envious of his experiences, I wish I had done half of the things he talked about doing.
If you EVER have an opportunity to hear him speak, go to listen, you won't regret it.
As a couple of people have noticed, November's MSDN magazine just went online, and the article I wrote for it is included :) Yay!
It looks much better in print btw :)
A little known fact about me: My cousin, Jeff Pevar is actually a famous musician. Really. And he even has a sort-of blog (no RSS feed though)
He’s been touring for several years as the P in “CPR” (David Crosby (yes, the David Crosby), Jeff Pevar, and James Raymond (David’s son)), and apparently this summer Jeff and James are going to be touring as members of the new Crosby Stills and Nash concert tour this summer!
From his site:
"I'd been hoping this opportunity would come around one day. After working with David and Graham in all these various combinations for over 10 years now, to have a chance to see what the synergy will be also working with Stephen, is an amazing opportunity and admittedly, a dream come true for me. I learned so much about music and inspired guitar playing from all their records, to now have a chance to work with the 3 of them together is such an honor. I am up for the challenge and ready to bring to the table whatever I can to support their incredible art"- jp
Wow! I had heard that CSN was touring this summer, but I didn’t realize that Jeff was going to be with the band.
And they’ll be appearing in Woodinville at Chateau St. Michele on the 22nd of September!
I don't normally do “hey, he started blogging” posts, but I just noticed that Jon Wiswall has started a blog.
Jon's one of those guys who can be counted on for insightful and intellegent answers during internal discussions, I know that when I see one of his responses, his answer's going to be the right one.
Nico over in Exchange just told me that he posted my article on Exchange’s Push Notification feature, so included by reference :).
I was cleaning up the remaining bits in the Simple Control Protocol, and wondering what I'd be doing next.
SCP was a cool project to work on - it was a low bandwidth networking technology intended for home automation. On the project, I was responsible for many of the DDK components, and a bridge that alllowed you to control SCP devices using UPnP
I got nailed by a new blog-spammer yesterday, so it's my turn to follow KC and Raymond and post a comment policy.
My new comment policy can be found here. It's unlikely to change anything, except for the blog-spam, I've never had any issues with anyone commenting on my post that violated it, but...
Which can be found here.
A truely fascinating read. I just had a quick read-through this morning, but I definitely want to go back later today and read it in more detail.
From what I saw earlier, no FUD, just facts. Very nicely done.
Jeremy Kelly pointed me to this post that he made about a debugging session that the Exchange escalation guys did that discovered a rootkit running on a customers machine.
It is an awesome detective job, and it’s a great example of exactly why (a) Every Developer needs to know Assembly and (b) Why you need to reformat your machine after you’ve been infected.
The ONLY way that they discovered that this machine had been rooted was the fact that the rootkit had a bug. If it hadn’t been for the bug, the poor customer would have never known that he had a problem, until much later.
And yes, stuff like this happens a lot. We’re very fortunate that we have some really talented escalation engineers working here that can diagnose stuff like this, but it’s a part of the skill set that developers and support people need to have.
Way to Go Jeremy, a great read.
KC just told me that she posted one of my Exchange articles, this one about Bedlam DL3. Enjoy!
My favorite talk radio host has a ‘blog!
Now I need to convince him to add an RSS feed.
KC just posted another of my Exchange blog entries. This one’s on the Exchange 2000 access rights and how Exchange 5.5 access rights were represented in Exchange 2000.
I just noticed that KC posted the first of the blog entries I wrote for the Exchange team last week, check it out!
My post on “how do I explain dividing fractions” from yesterday is the #1 google hit when you search for:
what do i do to figure out fractions with different denominators
what do i do to figure out fractions with different denominators
Whenever you submit a crash report to OCA, a bug gets filed in the relevant product database and gets automatically assigned to the developer responsible for the code. I had a crashing bug in the PlaySound API assigned to me.
In this case, the call was crashing deep inside of the waveOutOpen API and it was crashing because the input WAVEFORMATEX structure was bogus. The strange thing is that the PlaySound API does some fairly thorough validation of the input WAVEFORMATEX read from the .WAV file and that validation had to have passed to get to the call to waveOutOpen.
I looked a bit deeper and came to the realization that every single one of the crashes (in maybe a dozen different applications) had specified SND_MEMORY | SND_ASYNC in their call to PlaySound.
I’ve talked about that particular combination before in my blog, but I wanted to call it out in a top level post in the hopes that people will stop making this common mistake.
When you call PlaySound with the SND_MEMORY flag, it tells the PlaySound API that instead of reading the audio data from a file, you’re passing in a pointer to memory which holds the wave contents for you. That’s not controversial, and can be quite handy if (for instance) you want to build a .WAV file in memory instead of calling the wave APIs directly.
When you call PlaySound with the SND_ASYNC flag, that flag tells PlaySound that instead of blocking until the sound has finished playing, the API should return immediately instead of blocking while the sound is played.
Neither of these flags is controversial and neither of them is particularly dangerous until you combine the two together.
The problem is that there’s really no way of knowing when the sound has finished playing and thus when the application frees the memory, it’s entirely possible that the PlaySound API is still using it. That means that if you ever call PlaySound with both of these flags, you stand a very high chance of crashing due to the combination of these behaviors.
The unfortunate thing is that this behavior has existed since the SND_MEMORY flag was added back in Windows 3.1. The only safe way of dealing with this that works on all current Windows operating systems is to call PlaySound(NULL, 0, 0) before freeing the memory – the call to PlaySound(NULL, 0, 0) will block until the currently playing sound has completed playing (or abort the playsound if it hasn’t started yet).
A number of times in the past, I’ve mentioned that the PlaySound(xxx, xxx, SND_MEMORY|SND_ASYNC) pattern is almost always a bad idea. After the last wave of crash dumps were received for this problem, our team decided to do something about it. Starting with Windows 7, if you call PlaySound with SND_MEMORY|SND_ASYNC, instead of relying on the memory passed in by the application, we allocate our own buffer for the sound file on the heap and copy the file into that buffer. We’ll only do it for WAV files that are smaller than 2M in size, and if the allocation of the buffer fails, we fall back on the original code path, but it should dramatically reduce the number of apps that crash while using this pattern.
It’s a little thing, but it should make life much easier for those applications.
The biggest event on my plate in August was that I took taken delivery of a brand spanking new Itanium machine that was intended for 64bit Exchange development :). We also shipped Exchange 2000 during mid 2000. 2000 was a time of some turmoil for the Exchange store development team – after shipping Exchange 2000, much of the store team left Exchange and moved to SQL server (where several of them still remain). I chose not to remain with the rest of the store team and instead moved onto the SCP team (I wrote about that team yesterday).
So I was working on some file path parsing logic the other day and I ran into a problem – I was converting a file name passed in on the command line to a long filename acceptable path (one starting with \\?\). As I mentioned before, the Win32 APIs that accept \\?\ filenames assume that the filename specified is a valid path to the filename. That means that filenames with \\?\ prefixes cannot have “.” or “..” characters in the filename.
The good news is that there’s a convenient API you can call that handles removing the “.” and “..” filename components – PathCchCanonicalizeEx. As the API documentation states, it “Simplifies a path by removing navigation elements such as "." and ".." to produce a direct, well-formed path.”
What the API documentation doesn’t state (which I unfortunately assumed) was that when presented with a relative pathname, the PathCchCanonicalizeEx API, the PathCchCanonicalizeEx API would convert the relative pathname to an absolute pathname.
Note to self: Always read the API documentation. And don’t make assumptions about functionality that isn’t actually there.
Fortunately it appears that contrary to documentation, the PathIsRelative API works just fine in determining if an input filename is relative or absolute. So there’s an easy solution to the problem:
fileToCanonicalize = GetCurrentDirectoryAsString();
fileToCanonicalize += L"\\";
fileToCanonicalize += inputFilename;
PathCchCanonicalizeEx(..., fileToCanonicalize.c_str(), ...);
Five years ago, I attended one of the initial security training courses as a part of the XP SP2 effort. I wrote this up in one of my very first posts entitled “Remember the giblets” and followed it up last year with “The Trouble with Giblets”. I use the term “giblets” a lot but I’d never bothered to go out and figure out where the term came from.
Well, we were talking about giblets in an email discussion today and one of my co-workers went and asked Michael Howard where the term came from. Michael forwarded the question to Steve Lipner who was the person who originally coined the term and he came back with the origin of the term.
It turns out that “giblets” is a term that was used at Digital Equipment Corporation back in the 1980s. DEC used to sell big iron machines (actually I used DEC machines exclusively until I started at Microsoft). The thing about big machines is that you usually need more than just the machine to build a complete solution – things like Ethernet repeaters and adapters and other fiddly bits. And of course DEC was more than willing to sell you all these fiddly bits. It seems that some of the DEC marketing people liked to refer to these bits and pieces as “giblets”.
Over time Steve started using the term for the pieces of software that were incidental to the product but which weren’t delivered by the main development team – things like the C runtime library, libJPG, ATL, etc.
Later on, someone else (Steve wasn’t sure who, it might have been Eric Bidstrup) pointed out that the giblets that came from a turkey didn’t necessarily come from the actual turkey that you’re eating which makes the analogy even more apt.
Thanks to Craig Gehre for the picture.