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).
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.