Slashdot Mirror

> NT is an interesting design, but I'm not sure I'd call it a "microkernel" - more of a hybrid.

Right. The technical term is, I believe, "modified microkernel". Since the NT kernel system services share the same process (ntoskrnl.exe), their intercommunication is in-process, obviating the need for the message protocol-type cross-process communication used by typical microkernel designs. Apparently this was done for ease and performance:

• A disadvantage to pure microkernel design is slow performance. Every interaction between operating system components in microkernel design requires an interprocess message. For example, if the Process Manager requires the Virtual Memory Manager to create an address map for a new process, it must send a message to the Virtual Memory Manager. In addition to the overhead costs of creating and sending messages, the interprocess message requirement results in two context switches: the first from the Process Manager to the Virtual Memory Manager, and the second back to the Process Manager after the Virtual Memory Manager carries out the request.

  NT takes a unique approach, known as modified microkernel, that falls between pure microkernel and monolithic design. In NT's modified microkernel design, operating system environments execute in user mode as discrete processes, including DOS, Win16, Win32, OS/2, and POSIX (DOS and Win16 are not shown in Figure 1). The basic operating system subsystems, including the Process Manager and the Virtual Memory Manager, execute in kernel mode, and they are compiled into one file image. These kernel-mode subsystems are not separate processes, and they can communicate with one another by using function calls for maximum performance. NT's user-mode operating system environments implement separate operating system APIs. The degree of NT support for each environment varies, however. Support for DOS is limited to the DOS programs that do not attempt to access the computer's hardware directly. OS/2 and POSIX support stops short of user-interface functions and the advanced features of the APIs. Win32 is really the official language of NT, and it's the only API Microsoft has expanded since NT was first released.

  NT's operating system environments rely on services that the kernel mode exports to carry out tasks that they can't carry out in user mode. The services invoked in kernel mode are known as NT's native API. This API is made up of about 250 functions that NT's operating systems access through software-exception system calls. A software-exception system call is a hardware-assisted way to change execution modes from user mode to kernel mode; it gives NT control over the data that passes between the two modes.

(from Inside NT Architecture, Mark Russinovich, Windows NT Magazine, March-April 1998).

See http://www.sysinternals.com/ntdll.htm and Mark Russinovich' other publications here: http://www.sysinternals.com/publ.htm (Note: Unfortunately this page simply points to Windows NT Magazine's article database, which requires a valid subscription to view. If you can overlook the often ignorant, opinionated, partial, pro-NT, pro-Microsoft editorial content -- it's nowhere near the Nazi attitude of the amateurish "Dr. Dobbs"-wannabe Windows NT Systems Journal -- the subscription is almost worth the price, I think).

> NT is an interesting design, but I'm not sure I'd call it a "microkernel" - more of a hybrid.

Right. The technical term is, I believe, "modified microkernel". Since the NT kernel system services share the same process (ntoskrnl.exe), their intercommunication is in-process, obviating the need for the message protocol-type cross-process communication used by typical microkernel designs. Apparently this was done for ease and performance:

• A disadvantage to pure microkernel design is slow performance. Every interaction between operating system components in microkernel design requires an interprocess message. For example, if the Process Manager requires the Virtual Memory Manager to create an address map for a new process, it must send a message to the Virtual Memory Manager. In addition to the overhead costs of creating and sending messages, the interprocess message requirement results in two context switches: the first from the Process Manager to the Virtual Memory Manager, and the second back to the Process Manager after the Virtual Memory Manager carries out the request.

  NT takes a unique approach, known as modified microkernel, that falls between pure microkernel and monolithic design. In NT's modified microkernel design, operating system environments execute in user mode as discrete processes, including DOS, Win16, Win32, OS/2, and POSIX (DOS and Win16 are not shown in Figure 1). The basic operating system subsystems, including the Process Manager and the Virtual Memory Manager, execute in kernel mode, and they are compiled into one file image. These kernel-mode subsystems are not separate processes, and they can communicate with one another by using function calls for maximum performance. NT's user-mode operating system environments implement separate operating system APIs. The degree of NT support for each environment varies, however. Support for DOS is limited to the DOS programs that do not attempt to access the computer's hardware directly. OS/2 and POSIX support stops short of user-interface functions and the advanced features of the APIs. Win32 is really the official language of NT, and it's the only API Microsoft has expanded since NT was first released.

  NT's operating system environments rely on services that the kernel mode exports to carry out tasks that they can't carry out in user mode. The services invoked in kernel mode are known as NT's native API. This API is made up of about 250 functions that NT's operating systems access through software-exception system calls. A software-exception system call is a hardware-assisted way to change execution modes from user mode to kernel mode; it gives NT control over the data that passes between the two modes.

(from Inside NT Architecture, Mark Russinovich, Windows NT Magazine, March-April 1998).

See http://www.sysinternals.com/ntdll.htm and Mark Russinovich' other publications here: http://www.sysinternals.com/publ.htm (Note: Unfortunately this page simply points to Windows NT Magazine's article database, which requires a valid subscription to view. If you can overlook the often ignorant, opinionated, partial, pro-NT, pro-Microsoft editorial content -- it's nowhere near the Nazi attitude of the amateurish "Dr. Dobbs"-wannabe Windows NT Systems Journal -- the subscription is almost worth the price, I think).

I've bluescreened my NT4SP5 box twice today by running the DOS version of XaoS. This is a consistent, reproducible way to bluescreen NT (it worked on another machine with SP3, too.)

XaoS is an excellent realtime fractal zoomer, BTW. But don't run it on NT (even with the 'Windows-friendly' -i_love_bill switch) unless you have synced your disks first.

For those interested, a couple of articles on the native NT API by Mark Russinovich:

Inside the Native API

Inside Native Applications

Just out of curiosity, I took a look at native.exe (from the applications article) - the only dependency is on NTDLL.DLL, which weighs in at 347kb on my NT4 SP4 machine. Keep in mind that ntdetect.com, ntldr, hal.dll Though I have to admit the exports for it look a little weird... it looks like it implements a good chunk of the standard C library, and I want to know who thought exporting functions like "PropertyLengthAsVariant" were absolutely vital to the kernel...

For those interested, a couple of articles on the native NT API by Mark Russinovich:

Inside the Native API

Inside Native Applications

Just out of curiosity, I took a look at native.exe (from the applications article) - the only dependency is on NTDLL.DLL, which weighs in at 347kb on my NT4 SP4 machine. Keep in mind that ntdetect.com, ntldr, hal.dll Though I have to admit the exports for it look a little weird... it looks like it implements a good chunk of the standard C library, and I want to know who thought exporting functions like "PropertyLengthAsVariant" were absolutely vital to the kernel...

Actually, it is possible to tune performance under NT... you just have to know what to look for. Most of the tuning takes place under settings in the registry. You can do nifty things like processor affinity under SMP (where you can lock a service/application to a single processor), network performance tuning for various services and drivers, etc.

The following site has some excellent information on taming the Beast that is NT:

Click here for NT registry hacks

There are other sites that go into this as well, such as System Internals, which also provide handy utilities for things like monitoring open files etc.

That's all the pimping I'm going to do for NT today. Back to Linux Mandrake on my laptop :-).

Just look how the figures are wrong, even if the text seems correct.

• Figure 1 : There are more layers on UNIX ! [(Application|XServer)-(libc|xlib|libs)]-system calls-kernel-hardware. This implies you can have many instances of the GUI. Doing the same on NT need severe tweaking of the Win32 layer.
  
• Figure 2 : there is no documented link between application and system services. Most system calls on NT are undocumented (details). And the HAL is a joke, hardware accesses are hard-wired in the ntkernel like in Unix.