When I started at Microsoft, there were two independent families of Windows. The consumer releases that were all DOS-based, and the business releases that were all NT-based.

Until I joined the Windows team in 2000, I really didn’t understand the intricacies of having these two different ways of doing everything. In particular, with Windows XP being the melding point where all Windows releases became based off of the NT codebase, a ton of effort was spent in terms of setup, migration, application and hardware compatibility, and of course trying to make the OS more approachable for consumers. (It also brought about Windows Home edition—briefly called Windows Personal—, which was created by taking Windows Professional, and paring out key business features and adding some safety belts to create a consumer variant of the OS that was both consumer-friendly, and could sell for the classic “$99” price point that consumer Windows had always sold for.)

So while Windows XP was this spackle/stopgap release, it met both consumer and enterprise needs pretty darn well.

With Windows Longhorn, we had the opportunity to “think big”. Quite a few teams were off in the wilderness, many of them creating technologies that would be thrown overboard by the time the infamous “OS reset” occurred. But for the Windows setup team, most of the initial Longhorn vision made it into the final product.

But what was that initial vision?

Windows setup was split up into a bunch of teams. The group I was in owned a bunch of the infrastructure goo. WinPE, OS imaging, Windows Deployment Services (what I renamed Remote Installation Services to when we started rethinking it), sysprep, and more. Another team owned upgrade and migration, logging (Panther), etc. Another team owned the entire setup experience, and was chartered with replacing the ancient, cumbersome setup UI that we all had inherited, much of it from much, much older versions of Windows NT.

So an entirely different team was thinking about what the setup UI should look like. But our part of the team was focused on taking out the old gore of Windows setup, and replacing it with an entirely new image-based approach.

Why image-based setup? For much of the same reasons I mentioned in my last post, imaging was how almost all OEMs deployed the OS. Imaging was how most enterprises deployed the OS. For consumers? It didn’t matter that much, although there were opportunities to both improve the speed of installing the OS (and ideally, the reliability). In addition, there was a potential to make the OS more serviceable. Making it so customers could more easily slipstream in important fixes, updates, and maybe even features, and have an OS that was what they wanted out of the gate.

It might help if I explained how Windows setup worked. There were two-phases to setup. The first, “text mode setup” was, as the name implies, a text-based phase, where the NT kernel was responsible for setting the software up on disk for the second phase. The second phase, “GUI mode setup” was what most consumers were used to seeing. Text-mode was fragile, but didn’t have to do a lot, in the grand scheme of things. GUI mode setup, on the other hand, was a phase where Windows XP and earlier were, in essence, “assembled” on your PC. I used to use the analogy that Windows setup at this time was like if Ford came to your house and built your new car in your driveway, and then did the same thing in your neighbor’s driveway… even though you bought the same car, and building it in a factory would have made way more sense.

GUI mode was always one of the most fragile parts of setup, since it was just a bunch of inf files that needed to be processed, DLLs and other ActiveX objects that needed to be registered, drivers that needed to be installed and configured, and finally executables that needed to be run in order to set the final stage for Windows to run. Just panning back over it in my mind now I’m recalling different “burps” that would break setup. It was a lot of unique work to do for every Windows install, when the end result was almost identical.

With Windows XP, Windows effectively had two ways to start setup (more, if you get picky). You could run winnt32.exe from within Windows, or even run winnt.exe from MS-DOS. By the time I left Windows in 2003, both were dead.

Winnt.exe was killed early on, since we decided we wouldn’t support any DOS-based upgrade paths.

Winnt32.exe was a little harder to kill.

Once we had build the core technologies for WIM that I discussed in my last post, we started dabbling with programmatically applying the OS from a rudimentary setup UI of some sort. Because Longhorn builds weren’t a real thing yet, we played with imaging Windows XP. One of the earliest demos I recall was a very crisp demo with a simple UI that walked you through the imaging process (pick a disk, format it, enter your product key, install) to get the OS installed, and it even used the product key you entered to determine which edition it should apply. (This was relatively easy to do since WIM could store multiple volume images in one file.)

What I distinctly recall about that demo was how small it was on CD, even with two editions of Windows XP stored on it, plus WinPE, which at that time wasn’t yet stored in a WIM file itself. It was so small, and applied the OS in a handful of minutes. The future looked so bright. (Sadly, by the time we shipped the PDC build of Windows Longhorn in 2003, it would only fit on a DVD, and we had barely gotten DVD boot working prior to PDC.)

And so it was that the journey began to create image-based setup (IBS, unfortunately). The teams working to create the setup experience for Windows Longhorn worked together and we relatively soon had IBS installs. This expanded beyond our team, as the Windows build lab had to basically internalize that process and time for building the OS on disk that had traditionally occurred during GUI mode setup.

For a time, we ran with both the existing winnt32 process and IBS-based setup, until the install process had proven itself to the point that we could make the rest of the Windows team switch to it.

In Windows, there were several email aliases that were used to address the entire team… and typically things were positive, although they could get contentious. When we began the process of drawing down winnt32, a method for installing the OS (with automation, and switches and…) that a lot of people on the Windows team had become highly reliant on, it… got contentious. Even the fact that we were, with this move, killing a lot of weird mechanisms people had for installing Windows (like two installs on the same partition), tended to bubble up in feedback we got over time.)

I’d seen some threads go sideways on these aliases before, and because I was announcing a somewhat controversial change, I cheated. I had an old “OFT” file that a friend in the Outlook team had given me. When you opened it, it just looked like a normal email window. But this one, importantly, wouldn’t allow recipients to reply all. They could reply to me, the sender, but not to anyone else. This saved my bacon.

I wrote up my email announcing the date after which winnt32 would no longer be available.

I got a few direct “attaboys”, probably five emails (futilely) bitching about the change, and a couple of excited replies from teammates. And one, incredibly kind email from a pretty well-respected architect within Windows, and long-time employee of Microsoft. This email made it all worthwhile, as it demonstrated that people who had worked on Windows for a long time saw the value in what we were doing, even if it meant changing how you do your own processes.

As I reflect on this, I’m thinking about when WinFS was integrated into releases of Windows across the entire team. It was a disaster. The release immediately following it was one of the worst setup experiences I ever recall in a build, and the OS hung as soon as it booted, while WinFS started trying to ingest data stored on disk. But that’s another story.

In contrast, the switch to IBS was almost a non-event. It created a bunch of new opportunities to improve Windows, improve the setup process, and improve how OEMs and enterprises maintain Windows over the lifecycle of each version of Windows. In fact, it set the stage for Windows to keep evolving, as the OS has largely moved from something that ships on shiny media to the world, and instead, releases “shipped” over the Internet.

I wound up leaving the Windows setup team in early 2004, as I came to the realization that Windows Longhorn was circling the drain, and that it would likely take forever to ship. But as I look back, I’m always proud of what our team helped build while I was there, as these foundational technologies made it in to Windows Vista, seemed to please customers and partners (even if the OS itself didn’t), and survive almost 20 years after I left the company.