Beginning with Windows NT Embedded, an effort was started to refactor the Windows operating system in such a way that embedded device manufacturers could tweak the operating system to only include the parts that they needed to run their application or workload. Though it wasn’t completely decomposed/recomposable, it was a huge step in the right direction. By removing components not necessary to run a certain workload (say a point of sale terminal or a control system for manufacturing), the security footprint, as well as the overall footprint of the OS (sometimes CPU, but more often HDD/RAM and video) could be constrained, resulting in a device that was better at what it was supposed to do, while minimizing security and cost risks. Take a look at the claims on that Windows NT Embedded page – 9MB for a standalone OS runtime that didn’t include the Windows shell or networking.

This effort kept progressing throughout Windows, and the next major release, Windows XP Embedded, took the effort, referred to as componentization, even further. This effort required the XP Embedded (XPE) team to go out across Windows and evangelize componentization, and convince teams to help them break down their dependencies up and down the stack. You would be shocked to learn about how intertwined pieces of Windows were with each other. Nobody had, for the life of NT, ensured that components at the top levels of Windows had logically defined or clarified their dependencies down the stack. As a result, if you added one component of the Windows shell, you could wind up bringing in a gigantic stack of components. Add a certain runtime, and you needed to add a control panel (.cpl) file, because… well, it made sense at the time to put that library inside the cpl file instead of another DLL.

At that same time during Windows XP (Windows Whistler) development, I was on the setup and deployment team, which was separate from Windows Embedded (but would later merge). I was the second program manager (I  took the specs from the customers to the developers) for WinPE, also known as Windows Preinstallation Environment. If you’ve never heard of Windows PE, imagine a tiny OS runtime, about 120MB, that could run in 96MB or less of RAM. It featured TCP/IP networking, NTFS and FAT disk access, and cmd.exe as it’s shell. Most importantly, WinPE booted from CD, and was intended to replace MS-DOS for the pre-installation needs of Windows, whether you needed to kick off a scripted install of setup, or throw down an image to disk. WinPE was created primarily because the new Itanium platform had no deployment OS to help OEMs deploy Windows to their hardware. While Windows on Itanium died, WinPE became the underpinning of effectively every deployment and recovery tool in Windows.

I mention WinPE for one reason – I explicitly lived the XPE team’s pain trying to understand dependencies. Not long after we revealed WinPE to OEMs, they came back with wish lists of things they wanted added – including a Web browser. Eventually, I was able to talk them down from a Web browser, because they really wanted HTML Applications (HTA). I also hacked together Windows Script Host support and ADO connectivity to SQL Server. You cannot imagine the work I did to find the dependencies for those three components – which had not been defined individually in a way I could just grab and reuse. Finding someone who knew IE internals to the level I needed was almost impossible.

So what does this have to do with MinWin? Not long after Windows XP wrapped, there was a goal to come up with a minimal version of Windows (MinWin) that could serve as the centerpiece of every version of Windows. Whether you were building Windows Server or a Windows client release, or even WinPE, MinWin was the idea of a bootable version of Windows that featured the core components of the OS. I guess you could perhaps think of it as the quark of Windows. A common misstatement I’ve heard is that “MinWin is the minimal Windows kernel” or anything relating just to the kernel. It is more than just the kernel. MinWin, like the development of Windows on ARM that also occurred while I was at Microsoft, was never officially discussed outside, other than a few leaks. As a result, there was always much confusion about it. Most importantly, MinWin was never “a thing”. You never would be able to buy MinWin by itself, it was always intended to be a core of every version of Windows. In essence, it wasn’t about making a thing, it was about refactoring what we already had, to make it more nimble, both for continuing and growing embedded scenarios for Windows, but also to create products like Windows Server Core is today, as well as the current version of WinPE.

I encourage you to keep that in mind as you read this piece on MinKernel and BaseFS. While I have not talked with anyone inside Microsoft about either of these projects, I can only assume that they are the continuation of the refactoring of Windows. The Windows kernel was, for a long time, much more regulated than most of Windows. However, it still grew “big-boned” over time as things like Win32, networking, video,  .NET, WinSxS, and now WinRT required the kernel to be constantly updated – in a completely monolithic form. That would be fine, if every device required everything that was in the kernel. But it doesn’t. Windows Phone 8 likely includes at least some aspects of Win32, even though it will never run a full legacy Win32 application. So here again, my assumption is that the MinKernel project isn’t anything new per se, rather it is a modular, rather than monolithic, approach to building the Windows kernel. The result would be a layer of native-mode pieces that can be combined as needed for numerous platforms (Windows Phone 8+, Windows 8+, Windows RT+, Windows Azure, and even potentially the next generation Xbox and other hardware we aren’t aware of yet). The same could exist in the BaseFS realm. NTFS includes a ton of baggage, much of which is used by a small number of customers. Many of the NTFS features I’m alluding to as baggage didn’t even make it into the first public iteration of ReFS, which attempts to replicate much – but not all – of the functionality of NTFS. So what could BaseFS be? Likely the minimal NTFS, ReFS, or perhaps a shared driver for both, that implements a minimal set of filesystem functionality.

One can imagine this kind of refactoring of both to result in not only a well-factored and malleable kernel and filesystem driver, but also the kind of thin working set that might be ideal for, perhaps, running Windows Azure or Windows Hyper-V Server on, where the role of the server is solely as a host. I’m guessing here, and time will tell if I’m right or if I’ve missed some greater scenario. But by and large, much as MinWin was never a tangible thing, I’m not clear at this point that BaseFS or MinKernel will be much that even power users will ever get to see, directly.