It always annoys me how woefully misinformed people are about the architecture of Windows. Love it or hate it (or merely tolerate it), it's the most widely deployed OS in history... you'd think more technical folks would get the story straight.
Here it is, so that you guys can argue over real facts for a change.
A Brief History of Windows Architecture
Windows 1, 2, 3.0: Real-mode. These could accurately be called shells on top of DOS.
Windows 3.1 (and some editions of 2 and 3): 16-bit protected mode. This was when Win16 applications first appeared. DOS was used for file I/O and whatnot, but I believe it was run in V8086 mode (was this available on the 286? I'm not sure), so there was a rudimentary 16-bit "kernel" of sorts. MS called this "standard mode".
Windows 3.11 (and some editions of 3.1, 3, and maybe 2): 32-bit protected mode. This was when Win32S (the stopgap between Win16 and Win32) first appeared. This had a true protected-mode kernel (called the Virtual Machine Manager), but still ran 16-bit protected mode applications and ran DOS apps and drivers in V8086 mode. MS called this "386 enhanced mode".
Windows 95, 98, and ME: These all have the same 32-bit protected mode VMM kernel, but starting with Windows 95 protected-mode drivers (VXDs) were used wherever possible. Win32 became the dominant API, although Win16 was still supported by these OSes natively. The wacky address-space requirements of Win16 apps is what led to the instability of these Windows versions -- because parts of each address space (the part containing Win16 code) shared the same memory. Ick.
Windows NT, 2000, XP, Vista: These all run on the NT kernel, the design of which is influenced very heavily by VMS (both were designed by Dave Cutler). Win32 was first introduced here as a layer on top of the "native" NT system call API. Win16 apps were run via emulation in a host process called wowexec (Windows On Windows), while DOS apps were run via emulation by NTVDM.EXE. V8086 mode was not used at all.
When things moved in and out of user space in NT:
- The GUI was entirely in user-space in NT 3.1, 3.5, and 3.51, but the graphics drivers were in kernel-space (as were pretty much all the drivers).
- The GUI was moved into the kernel in NT 4.0 for performance reasons (it is a "special" kernel-mode driver called win32k.sys).
- Parts of the graphics drivers, USB drivers, and other classes of drivers (excluding storage and networking) have been moved out into user-space in Vista via "I/O redirection". Basically, DeviceIoControl() calls get redirected by the kernel to services (Windows equivalent of daemons) running in user-space. I believe (but am not 100% sure) that the GUI itself still runs in kernel-mode, but I could be wrong. It's not clear to me where the boundary between GDI and USER was as of NT4, and now with Vista's new 3D UI, I'm not sure how these APIs work anymore.
Vista is arguably becoming more like a microkernel, if only in the sense that more and more drivers are running in user-space. However, this was hacked on, not designed into the system from day one. The NT kernel is still a very large and complex beast.
I would consider NT and Linux to both be hybrids in the sense that they allow for "kernel modules" or their equivalent, but NT still sort of has the notion of user-space "environment subsystem servers" that, in theory at least, can put different API "personalities" on top of the NT system call API (e.g. -- the OS/2 and POSIX sub-systems of yore, as well as legacy support for Win16 and DOS, and legacy support for Win32 on 64-bit systems).
On another note, Mac OS X is not a microkernel-based OS. Mach was a microkernel, but slowly accrued stuff over the years. The Mac OS X kernel, xnu, is actually Mach plus its BSD subsystem server plus its driver framework all running in kernel-mode. It's sort of a hybrid as well.
Really, most mainstream OS architectures are very similar (and therefore very boring, at least from a research perspective). Also, I would argue that they are all fundamentally equally insecure by design.
The difference comes in implementation. MS made a lot of bad decisions about how to organize things in user-space that have led to security problems over the years (not making executables read-only by default, letting users run as administrator by default, ActiveX, etc.). So, Brynet, I'm wondering why you think it's the NT architecture, as opposed to the steaming pile called "Windows" put on top of NT, that is the source of the security problems.