Robert McLaws: Windows Edition

Blogging about Windows since before Vista became a bad word

Mark Russinovich Explains MinWin Once and For All

A lot of people assume that MinWin is a Microsoft effort to completely rewrite the Windows Kernel from scratch. That may be based on earlier (limited) explanations about what it does, or it may have a lot to do with people assuming, due to people’s efforts with open source software, that rewriting the kernel will solve all of Windows problems. Well, Mark Russinovich, Microsoft Technical Fellow and guru of all things NT Kernel, attempts to set the record straight in this 45 minute video from Channel 9. Now, the whole talk is about advancements in Windows 7, and has great info about the new event-based model for Windows Services (dunno what took so long on that one, but I’m glad its there now), and other things. but for the purposes of this discussion, you want to jump in at 28:20, which is where MinWin first comes up.

I’m going to attempt to use my Geek-to-Layman Translator to break down what Mark said:

It turns out that Windows Server Core is not a clean separation of the true core of Windows. When Microsoft first set out to make Server Core, they discovered that lower-level systems were dependent on some higher-level calls, which is a no-no in systems design. When they looked deeper, they found out this was happening all over the place. They realized it was going to take too much effort to make a clean break for Server Core, so they literally ripped out anything that wasn’t necessary for the Server Roles they wanted to support. That’s why you’re not supposed to run any other apps on Server Core (or WinPE, as it turns out) because it might make a call to something that doesn’t exist, and it will fail. If it fails low enough, well, that could be bad for the OS.

That system is not scalable or testable in any way, and makes it very difficult to innovatively deliver future iterations of Server Core. So Microsoft started to chart out the entire Windows dependency graph. And as they saw things that started calling up the stack when they weren’t supposed to, they rearranged the APIs to create a clean separation in the OS.

MinWin is the result of that work. It is not a complete rewrite of the kernel, but a reorganization of the APIs, so that components only call down the stack, and not up it. It is isolated in the build tree from the rest of Windows, so it can be innovated on by itself. It is fully bootable, 25-40MB of disk space, and contains the executive systems, memory management, networking, and optional file system drivers. It’s fully testable, and Microsoft is working on a large suite of test cases to run against it. And it *is* indeed in Windows 7.

Mark also said that, though MinWin is finished, their work in this process is not. Now they’ve gone up in the stack, and are looking at where the next boundary needs to be drawn. Apparently, it is part of a much larger effort to reorganize all of the Windows codebase, and keep things clean and separate.

As an aside, for those of you wondering, a lot of the MinWin magic happens in KernelBase.dll. It contains a lot of the functionality that was refactored from Kernel32.dll, so for compatibility with older programs, they left “forwarders” in there that pass the calls down to KernelBase.dll as necessary.

So rejoice, armchair kernel enthusiasts! Microsoft is tidying house inside “Cutler’s NT”, and Windows 7 is the next step (the first being the componentization work from Windows Vista) in the massive decade-long operation to optimize and refactor the Windows codebase.



  • Larry Smith said:

    Yes, Mark did talk about "rearranging the APIs". But the way he phrased it, and the way you've (accurately) reported it, seems to me to be confusing. I'm concerned about what people might expect by the phrase "rearranging the APIs". It may sound like they changed the APIs themselves. Undoubtedly what Mark meant was that they rearranged *where* the (unmodified) APIs were *called from*.

    For a simplistic example (and nothing to do with kernels, minimum or otherwise), suppose you have a C (C++, C#, Java, etc) program that has a subroutine (in this context, an API) "OpenLoggingFile" that's called 10 levels deep in one place, and 3 levels deep in another place (and maybe many other places at arbitrary depths). One approach to simplifying this is to call OpenLoggingFile from the mainline.

    Now I admit, this intra-module example really doesn't map well to the inter-module layering that Minwin addresses. But maybe the idea gets across that by changing the code so that an API called *here* can/should now be called from *there* might be a more rational invocation of it. Alternatively, if a call must be made upwards, maybe the right thing to do is to cut that particular segment of code from, say, Level12.dll, and paste it into the source for Level10.dll. (Of course this assumes that the code you've cut is self-contained, and makes no references to other routines in Leve12.dll (or even Level11.dll).

    October 30, 2008 10:10 PM
  • Dunya Info said:

    Rumor about Windows 8 and Windows Phone Code

    December 15, 2011 3:50 AM