Mark Russinovich on MinWin, the new core of Windows

Since the first public news of Windows 7's development back on October 2007, we've heard about a component of the operating system called MinWin -- a tantalizingly titled element that sounds like some kind of portable Windows kernel. Now Windows 7 is actually residing on paying consumers' desktops, and inside of it -- and inside of Windows Server 2008 R2 -- is the MinWin kernel architecture...and yet few have been made clear as to what it actually is.

A few weeks ago in Los Angeles, Microsoft technical fellow Mark Russinovich -- absolutely the world's leading authority on Windows performance and architecture -- took time to explain to developers attending PDC 2009 in Los Angeles exactly what this is. In summary, it's a way to graft onto Windows some semblance of the architectural layering it should have had, if its architects in the 1980s had any foresight into how Windows would be used thirty years later. It enables current and future Microsoft developers to evolve new configurations of the operating system, without having to rewrite core services or worry about breaking dependencies between those services and upper-level APIs.

"If you look back at the evolution of Windows, it's evolved very organically, where components are added to the system and features are added to the system without, in the past, any real focus on architecture or layering," Russinovich explained. "And that's led us to do some hacks with Windows, when we want to make small footprint versions of Windows like Server Core, or Embedded Windows, or Windows PE -- the pre-installation environment. What we do [instead] is take full Windows, and start pulling pieces off of it. The problem with that is, the pieces that are left sometimes have dependencies out to the pieces that we've removed. And we don't really understand those dependencies."

Perhaps "Windows" is a poorly fitting name for what the operating system should be at its core. The breakthrough with Server Core, introduced back in Windows Server 2008, is that it minimized the number of running services to just those that enabled the operating system to be self-sustaining, and perform its roles as a server to the outside world. But even those services contain dependencies to libraries that involve graphical functionality, even if none of those services use that functionality. Conceivably, a breakthrough above and beyond Server Core itself would be a completely minimalistic kernel, upon which those roles could be added modularly, without having to involve libraries that presume the computer operator needs graphics, a mouse, and sound.

MinWin is the first critical step in that direction. "We want to get more rigorous about this," said Russinovich, "because every time we evolve Windows, we end up breaking those versions that we've sliced-and-diced. We'd like to have a Server Core that we understand, that totally depends on itself and not things outside of itself, so that we can evolve things outside it while we evolve Server Core, and not be worried about breaking Server Core, or having to redefine it with every release."

The basic MinWin in Windows 7 is comprised of about 161 files, whose total footprint on disk is about 28 MB. Before you go thinking you could carry that around in the cheapest thumb drive you've got, realize that MinWin doesn't even issue a command prompt. It runs the kernel, basic system services, and the TCP/IP stack, and that's it.

Operating system functions are implemented through APIs; and since Windows 3.1, those APIs form the collective library of libraries known as Win32. The principal division of labor in Win32 has historically been vertical, not horizontal, dividing core system kernel functions from "user" input and interactive functions, from graphics and display functions. Even though Windows architecture has evolved to the point where the whole graphics part is essentially deprecated for modern apps, GDI32.DLL is presumed to be present.

For Microsoft's engineers to implement a more horizontal layering, they needed to create a scheme whereby API functions operate as though the typical division of labor still existed, even when it doesn't. Here is where that most blessed word "virtual" enters the picture. Under the new MinWin architecture, the handful of core functions in the new KERNELCORE.DLL KERNELBASE.DLL handle essential system services. Any other calls to APIs outside that realm are "forwarded," like unresolved DNS addresses in the Internet naming scheme, to libraries outside the core.

But whereas APIs used to "resolve" to the same core sets of libraries that existed since the '80s, under the new MinWin architecture, all that's changed. Revealing the gulf between the mindsets of what constituted efficiency 25 years ago and efficiency today, Russinovich explained something incredible: In the old days of Windows, APIs were bunched together in groups that may not have had any logical bearing with one another, simply to reduce the length of the boot path. Bigger API collections meant fewer references to their filenames.

"We want to get away from that, and really make the definition of the logical DLLs, these files on disk, separate from the API sets that they implement, so that we can compose them dynamically," said Russinovich. "In other words, we want people to call virtual DLLs that implement APIs, and then what happens on the system is that those virtual DLLs are mapped to logical DLLs that actually implement this functionality. So it doesn't matter from a programmer's perspective if a virtual DLL's implementation is in this logical DLL or that one, it's up to us behind the scenes to figure out how to best combine virtual DLL implementations into logical DLLs."

There are performance costs to the implementation of logical DLLs, one of which being the creation of "artifacts" in the dependency trails that tools such as Russinovich's own Dependency Walker can trace. Also, processes now have to be endowed with a map that associates virtual DLLs with logical DLLs. And the files for the virtual DLLs have to physically exist on disk, even though their instructions are comprised completely of no-ops.

But the benefits outweigh the costs, including expediting API requests through virtual, dynamic placement. And now Microsoft's own developers, mindful of what Russinovich calls the three-year "cadence" between major product release cycles, are freer to innovate different form factors and implementations of Windows for new classes of hardware and new configurations.

MinWin can boot as a separate operating system process unto itself, but it doesn't actually have any console of its own. In this PDC 2009 demonstration, an outside process actually has to test the waters to see that MinWin has a heartbeat.

One potential payoff down the road for MinWin may yet come from an improved Server Core. As Russinovich demonstrated, even the command prompt up until Vista relied upon a high-level process associated (for no important reason) with graphical functions, the Client/Server Runtime Subsystem (CSRSS). The new MinWin architecture now enables each running process to have access to a command subsystem called CONHOST that is closer to the core, without messing around with libraries they won't even use. A future Windows release ("Server 2011?") could substitute the existing Server Core with a horizontally-layered architecture based on a MinWin foundation.

And another possible permutation for the client edition -- one which Russinovich did not mention, but which is foreseeable nonetheless -- involves a foundation layer built on MinWin whose basic purpose is to manage the hardware and run system services, topped by a virtual layer also built on MinWin that runs applications and provides the user environment. Such a scheme would be worlds more secure than the system we use today.