When I joined the Windows setup team in Oct. of 2001, Windows Whistler (what would become Windows XP) was already at beta 2. A rapid release tucked in after Windows 2000, which was well-received by business customers but was nowhere near customer ready, the goal of Windows XP would be creating the first Windows NT-based OS for consumers. VP Jim Allchin’s mantra was “It just works,” which we sometimes jokingly said as “It juuuust works.”

Humor aside, Windows XP would be a mash-up of Windows 2000 with key improvements that would make the OS consumer ready. This included things like:

• A new Windows setup user experience with eye candy (lipstick on a pig, my group program manager called it during my first interview), that could upgrade from both NT and 9x-based OSs
• As much application compatibility as possible, to allow customers to run their old consumer-centric Windows applications on NT
• A revised user interface (including the much loved and hated theme, which we didn’t even get to see until weeks before it shipped).

In short, it was a quick release, and one that wouldn’t let us do anything massively revolutionary. That would be reserved for Windows Blackcomb, the milestone where Whistler bugs went to die, which would eventually be nixed for another “quick” release, Longhorn, fittingly codenamed for the sketchy pub located between the Whistler and Blackcomb mountains at the ski resort in BC.

The point of this is to say that while the Windows setup team had ideas about how to make setup work better and faster for OEMs (the companies that build PCs) and enterprises, those ideas would have to wait until after XP shipped, and so they did. Instead, we spent time focusing on improving setup overall, improving migration (something Windows still struggles with), finally “finishing” RIS so it could install most any OS, and of course a ton of time spent on WinPE and sysprep, to make image-based OEM deployment faster and more efficient.

The Windows setup team had focused on Sysprep for a while, but it was still an afterthought. Sysprep, for the uninitiated, is the tool that runs through a Windows install when the OS is deployed via imaging tools—predominantly Symantec Ghost at that point—and makes each install of the OS unique, from the machine name, relationship with Active Directory, and any other identifiers that need to be “uniquified” as we would sometimes say.

Before I had joined, several team members had done visits to the key OEMs, who were all deploying the OS using Sysprep and Ghost, while the Windows setup team’s focus was primarily on the old inf-based setup infrastructure that Windows had used forever.

So the main way OEMs were deploying the OS wasn’t fully tested until the OS was nearing release, and the amount of time that was spent spackling together the legacy setup infrastructure was increasing over time. It was fragile and a ton of wasted time for OEMs and enterprises. The team had a saying that “We’re doing 95% of our testing on the 5% case.”

And so while XP stayed with the old setup infrastructure (which would be the source of one of the last bugs found literally days before XP was released to manufacturing), but the long-term focus of the team would be on building a setup that was image-based at it’s core, with migration wrapped around it from the old install to the new install.

I will preface what follows with, “I was the program manager for WIM.” I didn’t build it, I didn’t design it, heck, I didn’t even write specs for it. But that’s another conversation for another time. I raise this because it’s important that you understand that there was one person who was behind WIM—one pretty amazing developer—who accommodated my weird-ass approach to program management, and let me help define what became a much-loved tool and technology.

When the idea of Windows imaging first popped up, it was clear that while all of the popular imaging tools were sector-based (copies of the disk itself), ours needed to be file-based.

A file-based image format would allow us to deploy the OS very rapidly, while also minimizing the size of the OS in transit, so we could fit the image on a CD. (Sector-based formats tended to be chonky due to the way they had to represent an entire disk within the image – I’m trivializing this a little bit.)

We wanted the format to be non-destructive, since we’d need to apply the data out of it to migrate the original system to it, and the original vision included the idea of single-instancing of files (only store each unique file once, regardless of the times it is needed), and multiple volume images within a single file. This latter feature would enable a single WIM to efficiently store images of multiple systems, copies of different editions of the OS, etc. without doubling the storage space required. Over time, we’d add multiple types of compression, all derived from compression algorithms built into Windows already, and used for Microsoft .cab (cabinet) files, which we liberated after sitting down and talking to the dev who had built the CAB file format originally.

In addition, the imaging process began with a command-line based tool, which I early on chose to call “XImage”, which was intended to be an homage to the ancient Windows xcopy utility. (Unfortunately it was renamed to ImageX after I left Microsoft in 2004, due to a naming conflict with a tool used by one of the OEMs already.) The tool would be tweaked over time to enable multiple volume images to be easily captured, deleted, modified, updated, exported, and more. Many of the early features for the command-line tool came not just from our scenarios, but numerous teams across Microsoft that grabbed ahold of the WIM format and tools for their own scenarios, even though we weren’t done! Even the icon that XImage used early on was a gift created by a Microsoft employee who was a big fan of the format and tools.

In fact, we had a feature, “/volsnap” that would take a snapshot of the disk and let you pick up an image from the snapshot. Cool, but the filesystem team wasn’t elated with us picking up an OS install that wasn’t properly shut down… so we had to remove the feature. I think we were getting a little too close to backup territory without that kind of testing. This happened as Halloween approached (in 2002, I believe) and I marked this sad occasion by acquiring a plastic “tombstone” from a party store and writing “R.I.P. /volsnap” on it.

The format itself would evolve over time. Initially defined with XML-based metadata, the developer found that the amount of redundancy and the performance hit weren’t worth it, so he switched it to a binary format just after we shipped the Windows Longhorn beta build for the 2003 Professional Developer’s Conference, which would also be the first time we’d release an OS that installed from a properly formatted DVD. Amusingly I remember some conspiracy theories that said we were trying to hide the infrastructure of the WIM file for some reason, when the reality was we were just trying to make the whole thing faster and less wasteful.

Most of the features I helped define for the format, tools, and even the name itself, all happened via conversations with the developer either in one or the other of our offices, on our whiteboards, or over email. In fact, the name “WIM” was one I came up with on a weekend over email, when the dev asked what we should call the file format itself. I couldn’t come up with anything for the “M” to stand for, but it was very important to me that we call it WIM, as this was the name used for team events that were regularly held in the Windows division at that time, Windows Informational Meetings.

I sometimes have regrets that I didn’t adopt a more formal approach to specs, to help define the tools and format, but I’m not sure it would have worked as well as it did, or that we would have been able to accomplish what we did, as fast as we did. We were a scrappy, skunkworks kind of team, and we did what it took to solve OEM and enterprise problems. In the end, it was one of the most fun projects I ever got to contribute to, and it’s still used by people today, more than 20 years later.

In my next post, I’ll talk about how we began the switch away from legacy Windows setup to a new image-based setup, and the challenges that brought.