RSSMark Russinovich on MinWin, the new core of Windows
By Scott M. Fulton, III | Published December 2, 2009, 5:27 PM
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.
Interesting that the original architecture put the GUI in the kernal, (MS recoginising that for their users, if the GUI wasn't working, the OS wasn't working), and the new architecture puts in the Network instead: I guess for users now, if the network isn't working, the OS isn't working.
Score: 0
|I've used library-based pre-emptive micro-kernel systems capable of running a full GUI on a single 880 kB disk.
Score: 5
|Like WinCE? Or several OSes from the 80s? Not sure what you are trying to say here.
Score: 1
|That there 16bit version of windows 3.1 had the win32 API did it?
Anyway, I'm sure getting tired of Microsoft refusing to admit there is an IT industry outside Windows.
Score: 1
|I think the article meant to say Win32 has existed since either Windows *NT* 3.1 (the first version of Windows NT).
Of course, there was an addon, Win32s, for Windows 3.11 that added a subset (hence "s," I assume) of the Win32 API to this OS and thus allowed some 32-bit-calling applications to run, but I'd have a hard time imagining that is what this article is talking about...
Score: 0
|"That there 16bit version of windows 3.1 had the win32 API did it?"
Well yes there were, but I think the point that was being made is that Win32 was designed based Win16, as many of the APIs are the same or extentions of the Win16 API set.
PS NT's kernel layer 'cleanup' and the restructuring of Win32 are two different subjects, even though they are both going through the same process. NT does not equal Win32 - instead Win32 sits on NT as a subsystem with its own Win32 Kernel.
Score: 0
|http://en.wikipedia.org/wiki/Windows_3.1x#Win32s
Score: 1
|Reminds me of your feature on powershell and how the lead developer was "telling" on its blog how it came to him, as in a vacuum, how great it would be to chain together commands and build administrative task and automate windows from independent but interacting tools ...
I was thinking : "this guy MUST take us for fools because no one can pretend to be such a fool himself" .. really ? He was "discovering" the unix philosophy itself based on years or architectural work in computer sciences that were done DECADES ago ?
And now they "discover" the same with kernel / user space and os architecture ? They even "discover" basic principles of software design ? And are AMAZED by having a 28MB dumb kernel ? 28MB ?????
And of course, it is as IF the whole world was not pointing for YEARS at this basic design flaws in windows that explains, for a huge part, its instability and and poor security track record.
What's next ? dynamic kernel module loading ? Or self contained apps ? (ok they tried that with .net).
Maybe they will patent the idea too ?
I am a bit amazed the article does not put a bit more of perspective on the topic and could let an unsuspecting reader believe that Microsoft did some kind of "revolutionary" breakthrough ... into the past....
Somehow this kind of stunt pisses me off ...
Don't know why, I suppose I hate people never acknowledging their mistakes and rewriting the past ...
Grumpy mood I admit :)
Score: 8
|I couldn't have said it better. Yet more proof of the time-space distortion around the Redmond campus. Or aluminum in the water.
Score: -3
|What MS is trying to do is to implement Andrew Tanenbaums OS design philosophy into a commercial product.
Nothing exciting. See MINIX3 for yourself...
Score: 4
|Sounds like the philosophy behind the original Amiga OS. Anyone still around who is familiar with that design? It was truly remarkable.
Score: 0
|Aye, I still remember the AmigaOS. Microsoft could have learned a great deal about how an OS SHOULD be coded. If you think about how the Amiga implemented the issue of library versioning; Windows could have been so much smaller in size. It was such a simple but highly effective idea, just specify, in the code, the minimum library version for the functionality that was required and back out gracefully if it wasn't available. So much better than having multiple versions of the same dll on the hard-disk. Just think of the Windows SxS directory!!
Score: 0
|Yeah how stupid of MS for not learning "how an OS SHOULD be coded." They really screwed themselves in the market during the Amiga days...
Score: -2
|So it's like making OS sets by role where the smallest subset doing only the most essential-to-the-core functions would be MinWin. Does this also clarify that current releases aren't actually based on MinWin (not even Server Core)? MinWin is currently only used for specialized SKUs that have pulled functionality like WinPE, Fundamentals for Legacy PCs?
Score: 0
|I suppose MinWin could also form the basis of a replacement for the Windows CE (aka Mobile) line too.
I quite like the idea of a multi processor machine where MinWin runs as a "server" on a CPU connected to the online storage (HDD, Flash), anther "client" runs on a CPU attached directly to the GPU cluster doing the UI and each programme runs on it's own CPU or CPUs with a MinWin looking after them.
I would expect in a decade for a desktop machine to have 100-200 CPUs, and clusters of GPUs and we're all going be running little clusters ... even in our "mobile phones".
Score: 1
|MinWin could form the basis for the next XBox platform, too.
Score: 2
|I'm not sure where the 'could' comes from...
MinWin is Windows. PERIOD.
It is just the restructured lower layers, and exists in Win7 in this form to some extent already.
NT even in Win2k or XP or Vista are VERY TINY kernel designs at the heart of the OS, and when SPLIT OUT, as MinWIn is a demonstration of, are under 30mb in design.
Essentially, everyone is already running MinWin, get it?
MinWin is just a more polished version of the kernel API layering being properly applied, so it is easier to pull out the core to demonstrate.
NT is a multi layered API kernel design. Over the years some of these layers have been mixed for performance or not logcially allocated into their structure peer libraries.
MinWin is basically un-mixing the API layer sets, and also putting the API set layers into libraries based on there roles and peer APIs instead of dropping them in various NT kernel DLLs that are not related or would even break to other layers.
Even mentioning Win32 in this article is dangerous, as Win32 is not MinWin, as Win32 runs in a subsystem ON TOP of NT. They have also taken Win32 and tried to 'layer' its sets as well, but these are two different subjects.
Score: 1
|30MB kernel? MinWin? Are you kidding me?
ls -l /boot/bzImage-2.6.32
-rw-r--r-- 1 root root 1915440 2009-12-15 01:14 /boot/bzImage-2.6.32
Linux kernel weighs just 2MB, or 5MB uncompressed. Add busybox (~1MB) to the mix and you've got a functional system.
Score: -2
|I wonder what would happen to Linux if MS released WinMin as say slackware kernel....and people started to build GPL based components around it offer as much or as less functionality one needed...that should pretty much be a direct threat to *uix ?
Score: 0
|Windows would be committing suicide. Am i right?
Score: 0
|if Micro$oft does this, i'm pretty sure that i'm going to be The President of The USA.
Score: -1
|Fairly certain the DLL's name is KERNELBASE.DLL not KERNELCORE.dll, simply because there is no file named KERNELCORE.dll on my box.
Score: 0
|You are quite right; my apologies, and I'll make the correction.
-SF3
Score: 0
|Sounds like Linux - a kernel with modules added on, with minimal (if any) dependencies. It's a sensible approach, whichever way you look at it. The difference seems to be that Linux is a much larger, integrated kernel (it has a lot of built-in drivers, for example, although other drivers can be added modularly). MinWin, as the article states, offers very little functionality in and of itself.
Which is better? No idea. :p
Score: 2
|Check out RedScissor's Live Executable Explorer (www.redscissor.com), it reveals the internals of a process and could help finding the tricky "virtual DLLs" for you.
Score: -1
|I really don't think this is the way to go with application design. To me one of the biggest problems with software is that it usually depends on files outside itself, usually shared with other programs. If one program needs a newer version of the dll then it updates it and can break other applications that once used it.
What I would like to see is programs following the portable application format of being able to run totally from its own directory. No registry settings just store the information in a .cfg file in the programs directory. We wouldn't have to reinstall programs or worry about where did the program put the data it saved or where are things like registration keys for purchased software.
I can understand the need for shared system files when hard drive storage was expensive but now see no need for it. Most DLL files if included and run from the programs directory wouldn't add much at all to the size of the program on disk.
Ship windows with its required dll and then let programmers put whatever they require inside their own directories with their programs.
Check out http://portableapps.com/ to see what I am referring to
I see the idea of virtual dll as adding an unnecessary layer of complexity and making the current situation worse.
Score: -1
|"Ship windows with its required dll and then let programmers put whatever they require inside their own directories with their programs."
You mean like MacOS has it for years? I'm windows fan for one thing to get out.. but i did sell and work on MacOS .. and i can say its miles ahead in some things then windows...
Windows system can get pretty fast bloated if you try diffrent apps and so on... but on mac os, you simply delete the app and its gone from your system... to install and app you simly drag and drop it to app folder or folder of your choice...
but i can i say i love windows 7 .. and mac os .. so now i have a hackintosh and dual boot :) for both :) and i have best of the both worlds :D
Score: 0
|