Executive & subsystems

System architecture named the Executive as one box in the diagram: the core kernel-mode services everything above it is built on. This chapter is that box, opened up.

A collection of managers, not a monolith

The Executive (implemented inside Ntoskrnl.exe, alongside the kernel proper covered in Kernel mechanisms) is best understood as a set of separate managers, each with a distinct, narrow responsibility:

• The Object Manager — a uniform naming, handle, and lifetime model for kernel objects of every kind (files, processes, events, sections — anything the rest of the system needs to reference). Kernel objects covers this fully.
• The Process/Thread Manager — creates and tracks EPROCESS/ETHREAD structures, the kernel's representation of running work. Processes & threads picks this up.
• The Memory Manager — virtual address spaces, paging, and the working-set policy covered across Memory management and its children.
• The Security Reference Monitor — covered in the Security level, enforcing access control uniformly across every object type the Object Manager knows about.
• The I/O Manager, Cache Manager, and Configuration Manager — covered in the I/O & storage and Registry levels respectively.

None of these managers reach into each other's internal data structures directly. They interact through defined interfaces — the Memory Manager doesn't know what a "process" means to the Object Manager beyond an address space it's asked to manage; the I/O Manager doesn't know a filesystem driver's internal state, only how to hand it a request packet. This is exactly the "one-way dependencies enforced by API boundaries" idea from System architecture, applied concretely.

Subsystems: how the Executive gets presented to applications

The Executive's managers expose kernel-mode services; they don't define what an application programming interface looks like. That's the job of subsystems — user-mode environments that package Executive services into the APIs applications actually call. The dominant one on Windows today is Win32 (CSRSS, Win32k, and session UI plumbing covers its own kernel/user split); historically Windows also supported others (POSIX, OS/2) as pluggable alternatives sitting on the exact same Executive underneath.

This is worth internalizing precisely: Win32 is one particular, documented way of presenting Windows to developers — it is not Windows itself. The Executive would function, in a reduced form, even without any subsystem attached; the subsystem is a translation and API-surface layer, not the substance underneath it.

A worked example: why a file handle "feels" high-level but isn't

Calling CreateFile in an ordinary Win32 program feels like a simple, high-level operation. Underneath, that call travels through Win32-subsystem code, into Ntdll, across the user/kernel boundary, and into the I/O Manager, which builds a request packet and hands it down a device stack — with the Object Manager, Security Reference Monitor, and Process Manager all participating along the way (creating the object, checking access, attaching it to the calling process's handle table). What looks like one function call is, structurally, a coordinated sequence across several distinct Executive managers.

A common mistake

Equating "Win32" with "Windows itself" is one of the most persistent misreadings in this whole area — it's an understandable one, since almost every developer's daily experience of Windows is the Win32 (or a Win32-adjacent, like .NET) surface. But the Executive's managers are the actual substance; Win32 is the most successful, most heavily used way of presenting them, not a synonym for them.

Where this connects

• Kernel objects and Processes & threads go one level deeper into two of the managers introduced here.
• Memory management covers the Memory Manager in full, across five chapters.