This section does not cite any sources. (May 2016) (Learn how and when to remove this template message)
The traditional kernel categories are monolithic kernels and microkernels (with nanokernels and exokernels seen as more extreme versions of microkernels). The "hybrid" category is controversial, due to the similarity of hybrid kernels and ordinary monolithic kernels; the term has been dismissed by Linus Torvalds as simple marketing.
The idea behind a hybrid kernel is to have a kernel structure similar to that of a microkernel, but to implement that structure in the manner of a monolithic kernel. In contrast to a microkernel, all (or nearly all) operating system services in a hybrid kernel are still in kernel space. So there are none of the reliability benefits of having services in user space, as with a microkernel. However, just as with an ordinary monolithic kernel, there is none of the performance overhead for message passing and context switching between kernel and user mode that normally comes with a microkernel.
One prominent example of a hybrid kernel is the Microsoft Windows NT kernel that powers all operating systems in the Windows NT family, up to and including Windows 10 and Windows Server 2016, and powers Windows Phone 8, Windows Phone 8.1, and Xbox One. NT-based Windows is classified as a hybrid kernel (or a macrokernel) rather than a monolithic kernel because the emulation subsystems run in user-mode server processes, rather than in kernel mode as on a monolithic kernel, and further because of the large number of design goals which resemble design goals of Mach (in particular the separation of OS personalities from a general kernel design). Conversely, the reason NT is not a microkernel system is because most of the system components run in the same address space as the kernel, as would be the case with a monolithic design (in a traditional monolithic design, there would not be a microkernel per se, but the kernel would implement broadly similar functionality to NT's microkernel and kernel-mode subsystems).
This article may contain an excessive amount of intricate detail that may only interest a specific audience. (February 2016) (Learn how and when to remove this template message)
The Windows NT design includes many of the same objectives as Mach, the archetypal microkernel system, one of the most important being its structure as a collection of modules that communicate via well-known interfaces, with a small microkernel limited to core functions such as first-level interrupt handling, thread scheduling and synchronization primitives. This allows for the possibility of using either direct procedure calls or interprocess communication (IPC) to communicate between modules, and hence for the potential location of modules in different address spaces (for example in either kernel space or server processes). Other design goals shared with Mach included support for diverse architectures, a kernel with abstractions general enough to allow multiple operating system personalities to be implemented on top of it and an object-oriented organisation.
The reason NT is not a microkernel system is that nearly all of the subsystems providing system services, including the entire Executive, run in kernel mode, in the same address space as the microkernel itself, rather than in user-mode server processes, as would be the case with a microkernel design. This is an attribute NT shares with early versions of Mach, as well as all commercial systems based on Mach, and stems from the superior performance offered by using direct procedure calls in a single memory space, rather than IPC, for communication amongst subsystems. The user-mode subsystems on NT include one or more emulation subsystems, each of which provides an operating system personality to applications, the Session Manager Subsystem (smss.exe), which starts the emulation subsystems during system startup and the Local Security Authority Subsystem Service (lsass.exe), which enforces security on the system. The subsystems are not written to a particular OS personality, but rather to the native NT API (or Native API).
The primary operating system personality on Windows is the Windows API, which is always present. The emulation subsystem which implements the Windows personality is called the Client/Server Runtime Subsystem (csrss.exe). On versions of NT prior to 4.0, this subsystem process also contained the window manager, graphics device interface and graphics device drivers. For performance reasons, however, in version 4.0 and later, these modules (which are often implemented in user mode even on monolithic systems, especially those designed without internal graphics support) run as a kernel-mode subsystem.
As of 2007, one other operating system personality, UNIX, is offered as an optionally installed system component on certain versions of Windows Vista and Windows Server 2003 R2. The associated subsystem process is the Subsystem for UNIX-Based Applications (psxss.exe), which was formerly part of a Windows add-on called Windows Services for UNIX. An OS/2 subsystem (os2ss.exe) was supported in older versions of Windows NT, as was a very limited POSIX subsystem (psxss.exe). The POSIX subsystem was supplanted by the UNIX subsystem, hence the identical executable name.
In August 2016, Microsoft unveiled the latest Windows subsystem called the Windows Subsystem for Linux. This subsystem, available only on 64-bit Windows 10 version 1607 (Anniversary Update, codenamed Redstone), runs a slimmed down version of Ubuntu 14.04 LTS natively within the operating system without emulation to achieve this. It was marketed as "Bash on Windows", because it ran bash, a popular command line interface used on many Linux distributions and macOS, and allows binaries compiled for amd64 to run unmodified within the subsystem. This was intended so that developers could run their tools on Windows without having to emulate them, and thus requires developer mode to be enabled in Windows Settings. It is designed only to run command-line applications, although a reddit user has discovered a way to run GUI applications or even an entire desktop environment with it. Certain applications that strictly rely on the Linux kernel itself will not be able to run because it does not include the Linux kernel.
Applications that run on NT are written to one of the OS personalities (usually the Windows API), and not to the native NT API for which documentation is not publicly available (with the exception of routines used in device driver development). An OS personality is implemented via a set of user-mode DLLs (see Dynamic-link library), which are mapped into application processes' address spaces as required, together with an emulation subsystem server process (as described previously). Applications access system services by calling into the OS personality DLLs mapped into their address spaces, which in turn call into the NT run-time library (ntdll.dll), also mapped into the process address space. The NT run-time library services these requests by trapping into kernel mode to either call kernel-mode Executive routines or make Local Procedure Calls (LPCs) to the appropriate user-mode subsystem server processes, which in turn use the NT API to communicate with application processes, the kernel-mode subsystems and each other.
XNU is the kernel that Apple Inc. acquired and developed for use in the macOS, iOS, watchOS, and tvOS operating systems and released as free and open source software as part of the Darwin operating system. XNU is an acronym for X is Not Unix.
Originally developed by NeXT for the NeXTSTEP operating system, XNU was a hybrid kernel combining version 2.5 of the Mach kernel developed at Carnegie Mellon University with components from 4.3BSD and an object-oriented API for writing drivers called Driver Kit.
After Apple acquired NeXT, the Mach component was upgraded to OSFMK 7.3, which is a microkernel. Apple uses a heavily modified OSFMK 7.3 functioning as a hybrid kernel with parts of FreeBSD included. (OSFMK 7.3 includes applicable code from the University of Utah Mach 4 kernel and applicable code from the many Mach 3.0 variants that sprouted off from the original Carnegie Mellon University Mach 3.0 kernel.) The BSD components were upgraded with code from the FreeBSD project and the Driver Kit was replaced with a C++ API for writing drivers called I/O Kit.
Like some other modern kernels, XNU is a hybrid, containing features of both monolithic and microkernels, attempting to make the best use of both technologies, such as the message passing capability of microkernels enabling greater modularity and larger portions of the OS to benefit from protected memory, as well as retaining the speed of monolithic kernels for certain critical tasks.
As to the whole "hybrid kernel" thing - it's just marketing. It's "Oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has.
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your Digital Marketing and Technology knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.