Today Microsoft formally launched Windows 7. I can’t say how proud I am of the work we did in Windows 7 – it’s been an amazing journey. This is the 4th version of Windows I’ve worked on and I have never felt this way about a release of Windows. I have to admit that I get a bit weepy with pride whenever I see a Win7 commercial (Kylie is simply too cute :)).
I thought I’d write a bit about the WIn7 experience from my point of view. I’ve written a bit of this stuff in my post on the Engineering 7 blog but that was more about the changes in engineering processes as opposed to my personal experiences in the process.
For me, the Windows 7 work basically started just after we shipped Vista. While the PMs and leads on the sound team were busy working on planning for Win7, I spent most of the time between Vista RTM and the start of the Win7 feature design cleaning up some of the Vista code I was responsible for. During the final Vista testing, I realized that there were some architectural deficiencies in some of the sound code that caused some really subtle bugs (that I don’t believe anyone outside of the sound team has ever found) so I took the opportunity to clean up those deficiencies.
I also fixed an issue that occurred when someone called the wave APIs from their DLL entry point. Yes I know that apps aren’t supposed to call any APIs from DllMain but anyone who’s read either my blog or Raymond Chen’s blog will realize that a lot of apps do stuff like that and get away with it. This fix was actually first deployed in Vista SP1 – we had identified the DllMain problem before we shipped Vista and included a workaround for the problem but we also added some telemetry so we could determine the number of customers that were affected by the bug. Based on that telemetry we decided that we had to include the fix in Vista SP1 of the number of users affected by the issue. This is a perfect example of some of the ways that the customer experience improvement program directly leads to product improvements. Before we had the CEIP, we would have had no way of knowing how much impact the bug had on customers, the CEIP gave us visibility into the severity of the problem that we wouldn’t have had before.
During this interim time, I also worked on a number of prototype projects and helped the SDL tools team work on the current version of the threat modeling tool. played around with some new (to me) development strategies – RAII and exception based programming and test driven development.
In June of 2007, we started working on actual feature planning – the planning team had come up with a set of tentative features for Win7 and we started the actual design for the features – figuring out the user experience for the features, the internal implementation details, etc. During the first milestone, I worked on the capture monitor feature – I ended up writing the feature from start to finish. This was my first time writing features using RAII and using TDD. I’ve got to say that I like it – as I remember, there were only 2 or 3 bugs found in the capture monitor that weren’t found by my unit tests and I’m not aware of any bugs that were found outside the team (which might just be an indication of how little the feature is used :)).
After the capture monitor work, I spent the next milestone working on UI features – I was on a feature crew of 2 developers working on enhancing sndvol to make it work better with multiple devices and to fix a number of accessibility issues with the UI. This was the first time in my almost 25 years at Microsoft where I had an opportunity to do “real” UI development. I know that there’s a lot of controversy about the UI choices we made but I’m pretty happy with the UI changes.
The third milestone for Win7 I worked on the “Ducking” feature. Of all the features I worked on for WIn7, the ducking feature is the closest to a “DWIM” feature in Windows – the system automatically decreases the volume for applications when you start a communicating with other people (this feature requires some application changes to work correctly though which is why you don’t see it in use right now (although it has shown up in at least one application by accident)).
The remarkable thing about Win7 development was that it was almost friction free. During the Vista development process (and in every other product I’ve worked on) development was marked by a constant stream of new issues which were a constant drain on time an energy. It felt like we moved from one crisis to another crisis. For Win7 it was different. I think it was some time during the second milestone that I realized that Win7 was “special”. The newer development process that was deployed for Win7 was clearly paying off and my life was far less stressed. In fact I don’t think I worked late or came in on weekends once during the entire 3 years that Win7 was under development – this was a HUGE change. Every other product I’ve ever worked on has required late nights and weekends (sometime it required all-nighters). But for Win7 it just didn’t happen. Instead we set a set of goals that were reasonable with achievable schedules and we executed on those goals and delivered the features we promised.
I’m so happy that customers are now going to be able to play with the stuff we’ve all worked so hard to deliver to you. Enjoy :).
 I started writing this on the 22nd but didn’t finish it until today.
"RAII is actually things like CComPtr, tr1::shared_ptr, std::auto_ptr etc - it's not just classes which destroy their state on destruction but templates which ensure that arbitrary objects get destroyed when they're no longer in use."
Oh it's much more than that! Chapter 3, "Resource Encapsulation", of Matthew Wilson's book Imperfect C++ covers RAII as a memory managment mechanism in detail. But it is also the cleanest (and more importantly the safest) way to manage thread locks, database transactions, ad-hoc handles, reverting impersonation, the list is endless. It is IMHO *the* most important idiom in C++.