Ah, MinWin. The elusive project in the Windows team that has been misunderstood more times than I can count. Once again, Mark Russinovich, more or less the Linus of the Windows world (I win stupidest comparison of the year award), has explained what MinWin is all about, while also touching upon a number of other changes to the core of Windows. Before we start: thanks to BetaNews for once again detailing these technical talks regarding the core of Windows so well.
We’ve talked about MinWin, and the core of Windows in general, quite a few times already here on OSNews. There’s a reason for that: I’m an obsessive compulsive cleaner and organiser. I not only clean a lot and keep everything tidy – I actually like doing it. Consequently, I like MinWin and what is currently going on in the core of Windows.
This should give you a hint as to what MinWin is, and as to what the Windows team is currently trying to achieve: exactly, it’s all about cleaning, structuring, and reordering. Over time, the dependencies inside the core of Windows have become a tangled incomprehensible mess that not even Microsoft itself – not even Russinovich – really understand. To make matters worse, countless spaghetti strands extend outwards from the core of Windows to the layers higher up in Windows. This is bad.
“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.”
They’re taking a different approach now, one geared towards the future. “What we do [instead] is take full Windows, and start pulling pieces off of it,” Russinovich said, “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.”
The first breakthrough in the cleaning of Windows was Server Core, the minimal server installation option for Windows Server 2008. However, even services in this “minimal” installation called the graphical layer of Windows repeatedly, even though they don’t need it. Logically, the next step is to produce a minimal version of Windows that doesn’t make any of these calls upwards.
“We want to get more rigorous about this, because every time we evolve Windows, we end up breaking those versions that we’ve sliced-and-diced,” Russinovich said, “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.”
MinWin is the first result. In Windows 7, MinWin consists of 161 files, with a disk footprint of about 28MB. It contains the kernel, basic system services, and the IP stack – it doesn’t even have a command line. You need to prod it using external processes.
Part of the ever ongoing MinWin project is transforming the APIs in Windows – collectively called Win32 – from vertical layering into horizontal layering. “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,” Scott M. Fulton explains at BetaNews, “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.”
And this needed to change. To get there, MinWin more or less fools API calls into thinking the traditional, vertical layering still exists. In MinWin, KERNELBASE.DLL handles essential system services. Calls made to APIs outside of this realm are “forwarded” to libraries that do not reside within this core. And it is here that MinWin makes a rather radical shift away from what Windows used to do.
Russinovich explained that in the days of yore, APIs in Windows were thrown together not based on any sensible logic, but to reduce the length of the boothpath. “Bigger API collections meant fewer references to their filenames,” Fulton explains. As said, this is where MinWin makes a radical break with the past.
“We want to get away from that [random grouping], 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,” Russinovich explains, “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.”
Clever, but there are downsides, such as performance costs. There also needs to be a map on disk that links virtual DLLs to the logical ones, and the virtual DLLs do need to exist on disk, even though they are more less “dummies”.
“But the benefits outweigh the costs, including expediting API requests through virtual, dynamic placement,” Fulton explains, “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.”
The future benefits are clear. For instance, as recent as Windows Vista, the command prompt called a higher-level process related to graphical functions, even though it didn’t need any of that stuff. MinWin’s new architecture provides each process with access to CONHOST, a command subsystem closer to the core.
Heck, you could take all this a step further: MinWin managing basic hardware access and system service, with a virtual layer on top also built on MinWin that provides the user environment.
As I’ve said before, I have a lot of respect and admiration for the people working on the core of Windows. They are evolving the world’s most popular desktop operating system, and despite the rigid constraints of don’t-break-stuff, they still manage to not just untangle the mess, but also to improve performance and add in new features. Say what you want about Windows, but the guys in the trenches are doing some impressive work.