Bill Todd () on 5/8/06 wrote:
---------------------------
>Understanding NT's characterization as micro-kernel-related probably requires knowing
>something about how it evolved. In the beginning, it had (at least) three distinct
>personalities: Windows, POSIX, and OS/2 (IIRC). Each personality (and much of
>the graphics system as well) was implemented as a user-space service which applications
>needing it accessed via message passing (IRPs are kernel constructs which have nothing
>to do with the message-passing facilities being referred to).
>
>Graphics support got inhaled into the kernel proper after performance became an
>issue. POSIX and OS/2 support withered and the Windows 'personality' became little
>more than a set of user-mode library stub interfaces rather than a separate protected user-mode server.
>
>Even in the beginning NT's kernel contained considerably more than a classic micro
>kernel, but it at least had *some* resemblance to one.
>

Although you are factually correct, I disagree with your interpretation. The resemblance you are refering to is not in important aspects of the design - it is like saying that a car resembles a train because they both have windows.

In my understanding, the personalities (Win32,OS/2,POSIX) are mostly user-mode libraries mapping the calls to the kernel API possibly with the support of some daemons to maintain state. Conceptually they are not different from Wine (or even glibc), including the message passing which you are referring to (LPC).

Same for running the GDI in user mode - how is it different from running a X server ?

Both of these are related to implementing user mode APIs and seem orthogonal to the whole microkernel issue. Why would they imply a microkernel-like design in one case and not in the other ?

Networking, storage, filesystems, usb, audio and everything else is in the same kernel address space, sharing data structures, etc, and has always been since the very inception of NT. That's how it was designed and AFAIK there was never any intent to implement any of that in user mode.

(This is not terribly relevant, but until a couple of years ago all Microsoft provided drivers were built as part of the kernel build instead of using the DDK).

I guess we could call it a hybrid if it was designed to support user-mode drivers, at least optionally, e.g. for USB, filesystems, and it offered at least some guarantees that a crash in such a user-mode driver would not bring down the system, but it isn't.