Lately Slashdot has been discussing Windows 7 and MinWin, but its coverage sucks. I don't know if people don't understand the architecture of Windows NT, or they don't understand operating systems in general, or they just don't care so long as it's Microsoft bashing.

The first thing that bugs me is all this talk about the "MinWin" project. Ever since this posting ran on Slashdot, there's been all kinds of discussion about MinWin, what it means for Windows 7, and so on. The thing is, lots of people seem to think that MinWin represents a completely different kernel. It's not: it's still NT. MinWin is just a stripped-down Windows NT installation - the essential components for booting up an NT system. The suggestion that MinWin should be "added" to Windows 7 doesn't make any sense; what people really mean is that they want all of Windows' "features" to be removed.

This just leads into the next misconception, which is this idea that the Windows "kernel" is big, bloated, ancient, monolithic, and filled with compatibility hacks. This is perpetuated by an error-filled article in the New York Times, no less.

Let's take a breather and take a step back. First of all, is the Windows NT kernel monolithic? Most references refer to it as a "hybrid" kernel. My opinion is that this is more an issue of nomenclature than of implementation. While the kernel might be compartmentalized, as long as its components and device drivers share address space and full supervisor privileges, they are effectively dealing with the same issues that a monolithic kernel might have. The primary result is the fact that a crash in one component of the kernel (or in a device driver) can take down the entire kernel as a whole.

The bigger question though: Is a monolithic NT kernel at all relevant to the notion that Windows is bloated? The correct answer here is, "No." It is not fair to imply that a monolithic kernel consists of "bloated layers we don't use." As stated above, that's not really what it means to be monolithic; the issues outlined above, not bloat, are among the main drawbacks of a monolithic kernel. Unfortunately Slashdot and the Times seem to believe otherwise. I think that I know why, and the reason is historical.

Back in the day, Windows consisted of three core modules: USER.EXE, GDI.EXE, and KERNEL.EXE (or KRNL[23]86.EXE depending on the operating mode that the hardware could support). USER was the window manager, GDI was the graphics library, and KERNEL handled, well, the kernel-ish functionality. I say "kernel-ish" because the 16-bit Windows kernel would sometimes "suck the brains out of DOS" and implement its own system calls, and other times it would just end up issuing DOS syscalls itself. When NT came along it was designed to support multiple subsystems in user-mode, so that the NT kernel could run OS/2 programs or POSIX programs (recall that NT was originally supposed to be a portable, "new technology" implementation of OS/2). Once the decision was made to make NT a Windows product, the OS/2 subsystem was replaced by another subsystem for 32-bit Windows programs that we now know as Win32.

Win32 consists of USER32.DLL, KERNEL32.DLL, and GDI32.DLL (of course there are now other components, but those are extraneous to my argument). These DLLs have similar names to the old core modules of Windows 3.x, and many of the APIs that these DLLs export are 32-bit counterparts to the old 16-bit APIs. Note, however, that just because one of the Win32 DLLs is still named KERNEL32, it doesn't mean that that library implements the kernel of a NT system!

I think that what these writers are really getting at is that they are fed up with the Win32 subsystem. They keep whining about the kernel because they've seen a core module named KERNEL since Windows 1.0 came out in 1985. The NT kernel itself is no older than Linux or Mach, the very kernels that NT is being compared to!

I think that the most absurd part of that Times coverage was that they proceed to compare the Win32 subsystem to microkernels. We're talking apples versus oranges here. The article then claims that because OS X was written on Mach that it became portable enough to run on the iPhone. This is probably true in comparison to the classic Mac OS, but for NT portability was an original design goal. IA-32 was not the first architecture that NT was written for; the Intel i860, a RISC chip, was the original platform. Further note that there were several RISC versions of NT that were available for many years. Itanium and AMD64 versions of NT sprung up rather quickly as well because of this portability. There are many more important factors that affect portability than the type of kernel that is involved; both NT and Linux are testaments to that.

The article also ignores the separate evolution of the DOS-based and NT-based code bases prior to Windows XP. In another instance of ignoring the fact that NT uses subsystems, the article suggests that the NT architecture isn't compartmentalized enough to change. If NT could switch from an OS/2 API to Win32, why couldn't it be switched to something else? I'm not saying that Microsoft would do this, but it certainly isn't a technical limitation.

I'm not defending monolithic kernels, and I'm not defending Microsoft either. As a matter of fact, I've personally been involved with writing two microkernels. I also just happen to have done lots of Windows programming over the past dozen years. What I am arguing for is some correctness in this armchair discussion of both the design and the future of Windows.