In October 2007, Microsoft distinguished engineer Eric Traut appeared in an online presentation and described something called MinWin, a component of Windows 7, the next desktop version of Windows. This revelation received massive news coverage in the tech world as it was the first time anyone from Microsoft had provided concrete details about Windows 7. But MinWin itself was interesting as well: According to Traut, MinWin was part of an effort to make Windows smaller by isolating the central binaries of the operating system into a bootable, usable core that, today, occupies just 25 MB of disk space. That's pretty impressive when you consider that the Windows Vista install image is over 4 GB in size, while the Windows Server 2008 Server Core image is about 1.25 GB.
While I was as intrigued as anyone else about MinWin/7, as I now refer to this technology, I also recognized the term: Microsoft had used the word MinWin over four years earlier in a public discussion about Longhorn (which became Vista and Windows Server 2008), noting that it was "the base OS component" of the system and part of the company's efforts to componentize Windows. In Windows Server 2008, MinWin was used to create something called Server Foundation, which went on to become Server Core. In each case, MinWin was used to describe a (relatively) small, central part of the OS, a building block on which all other versions of the OS would be built.
As described in October, MinWin/7 sounded like an evolution of the same work, and I assume that's obvious to virtually anyone. This isn't just a matter of these technologies coincidentally having exactly the same name. At a high level, they also appear to perform the same function. So I wrote up an article, Windows 7: Microsoft's New MinWin Kernel Not So New, about this coincidence, which I didn't really see as coincidence, updating it from time to time as Microsoft Fellow Mark Russinovich appeared to explain that MinWin/7 was, in fact, something completely different.
As I've said repeatedly, he would know: There isn't anyone on earth who understands the internals of Windows more intimately than Mark, and that was true even before he signed on with Microsoft. Easily one of the smartest people in the tech industry, Mark made a name for himself with his Winternals Software and Sysinternals work, and he's coauthoered several editions of Inside Windows/Windows Internals, the definitive public dissertations of how Windows actually works at a very deep level.
I have no such expertise, of course. As an outsider to Microsoft's plans and technologies, I simply observe what the company is doing and write about it. And as one of the only people who seemed to even notice Microsoft's original 2003 revelation about a technology called MinWin, I was struck by a sense of d?j? vu when Eric Traut hit the spotlight a few months ago.
But here's the thing. Mark says that the MinWin Microsoft described back in 2003 and implemented in Windows Vista and 2008 is not really the same work, though the two projects are clearly spiritually related. Here's how he described MinWin/7 to me.
"One of the ways in which you can make Windows smaller is to simply take out binaries, remove things" he told me in a recent conversation. "But that's an ad-hoc approach. Just because you've removed binaries, doesn't mean that some of the remaining binaries aren't still capable of calling that missing functionality." Server Core, he told me, was such an approach. The reason such a thing was practical with Server Core is that Microsoft can ensure that the workloads or roles that Server Core enables don't exercise those missing dependencies. "It's less sophisticated [than MinWin/7]," he said. But that's OK, because no code in Server Core will ever call a missing dependency.
MinWin/7 is a more sophisticated approach to carving off a bottom chunk of Windows. Here, Microsoft identified that bottom chunk, called MinWin, by performing an automated analysis of all of Windows and figuring out what the dependencies were between the binaries. Any binaries that were considered part of MinWin, were refactored (or split) to remove those upward dependencies. So while Server Core has cyclic dependencies--i.e. connections to pieces of unused components from the rest of Windows--MinWin/7 is self-contained. That is, no code in MinWin depends on anything outside of MinWin.
The rationales behind MinWin/Vista/Server Core and MinWin/7 are also somewhat different. In Vista and Windows Server 2008, the componentization effort was undertaken solely for servicing. In Vista's predecessor, Windows XP, servicing was particularly inefficient: Updates come down to the PC, poke around to see what's there, and then update accordingly. Thanks to Vista's component-based design, there is now a catalog on each system that provides component definitions and dependencies: Only those updates that are actually needed are downloaded.
Server Core, meanwhile, was about security and virtual machine densities. And while Server Core does indeed lowering the Windows footprint from 4+ GB to about 1.25 GB, and thus reduce the system's attack surface as a result, Microsoft can't actually build Server Core by itself: To get Server Core, it has to build the entire Windows Server 2008 product. With MinWin7, that's not the case: It can be built and run independently of Windows 7. While this won't result in any end user benefits, per se, it does allow Microsoft to test the lowest-level layers of the system more efficiently.
Also, while Microsoft likes to point out that Server Core doesn't include much in the way of GUI, win32k.sys and GDI, which are responsible for the graphics display, are still present in Server Core. What's really missing isn't the windowing system, per se, but rather the shell, or what we think of as Explorer. By comparison, MinWin/7 has no USER or GDI components at all. There is literally no windowing subsystem in MinWin.
Some questions arise out of this discussion. The first, and most obvious, is why would Microsoft undertake such a project? What is MinWin for? Mark told me that was still a secret and would need to wait for a later date. "Obviously, there's a certain architectural goodness there," he added.
How did Microsoft decide what went into MinWin and what remained outside? Mark told me that networking functionality was the delineator: Standalone MinWin is accessible from the network.
If MinWin has no windowing subsystem, how would one interact with it locally, on a PC? Mark says that Microsoft created a full-screen command line interface for MinWin "like DOS." (And before the "DOS is back" jokes start, he means that from an interactive perspective only.)
Obviously, it's still early in the Windows 7 release cycle and much could change between now and that product's eventual release. I suppose I can take heart in the fact that MinWin/7 is at least spiritually related to the previous MinWin work about which I've written. But it's clear that Microsoft is doing much more with MinWin/7 than was possible in Windows Vista or Windows Server 2008 Server Core. I can't wait to find out more.