(part 1 is here)
(part 2 is here)
When I joined the Windows Millennium (I usually cover my mouth and mumble when I mention this product) team I was given the opportunity to join either the development or test team. I met with both the dev and test managers and disliked the test manager much less :}, so my mind was set.I also enjoyed testing a lot – I liked figuring out how things worked (and figuring out how they didn’t work). One thing that bugged me during Win98 development was that we stopped testing on the debug version of windows. The debug build caught all kinds of errors that may not be caught until much later (or ever) (sort of a fail-fast mode) – it was a great way to make sure applications, libraries and drivers were all written and behaving well. Unfortunately, it suffered from broken windows – by the time the winme team was formed, it wouldn’t even boot without going through dozens of breakpoints in the debugger. When you got that far, a bunch of the other windows apps would hit breakpoints. The big problem was that the app breaks were mostly benign (e.g. bad NULL parameters), but because it was such a pain to run, nobody could take advantage of all of the other checks built into the debug build. The best part was that when I said I wanted to fix it, our management team told me to go for it. The initial job was just a lot of error / parameter fixing. It only took a few days until the debug OS would boot, then I fixed all of the apps I could. At this point I had to work on the “play nice with others” part of my job – I had to get a bunch of teams outside of windows to fix their application bugs. Eventually, I got most of them fixed, and you could actually “self-host” (use the os for most daily work) the debug build. We even used to play network games on the debug build on Friday afternoons! We did a lot of enhancements to the debug build – memory leaks and memory corruption were pretty easy to track down and fix, and we found a ton of other pretty bad errors (just not all of the errors customers found)
Along with debug windows, I also was asked to “maintain” the win9x debugging tools. The kernel debugger ran as a TSR that loaded at boot time. It communicated over a serial cable (although we later made it work over 1394) to a smart terminal. It turns out that “maintenance” of the debugger also included a bunch of changes and enhancements. One bit of context is that the winme team was “only” about 200 people (possibly less), but at least a thousand people around the company tested and dogfooded winme, and most of those used the kernel debugger. This meant that if I messed anything big up, that I could have a thousand people blocked. Luckily, that never happened – I made it through the product cycle relatively unscathed.
Along the way my manager tricked me into becoming a lead. He gave me more work than I could handle and when I complained he gave me “the new guy starting next week”. Turns out that guy was pretty smart and helped me look good for quite a while (we still have lunch every few months to this day). I ended up with 4 or 5 direct reports – one helping me with debug windows and the debugger, and the others working on the overnight stress infrastructure. I spent most of the day every day in the debugger and learned a lot. I’d use it to explore the operating system – setting breakpoints on unfamiliar functions so I could step through and see how they worked. I would change values (including return values) and watch what happened in untested code paths. I found a few cool bugs this way, but mostly learned.
Just before WinME shipped, our GM was promoted to VP. He was going to take over the Windows CE team and in the summer of 2000, he took 20 or so of us with him. In just over 5 years at Microsoft, I had worked on win95, win97 (the product I was working on before PST split into windows and IE teams), IE2, IE3, win98, win2k and winme (and 3 blog posts). The good and bad news is that I can probably finish the next 10 in one more post.