Projects‎ > ‎Reactos‎ > ‎

White Paper


The ReactOS architecture is based on that of Microsoft Windows 2003 Server. The ReactOS architecture, like NT, is monolithic but able to load modules. At the lowest layer is the Executive. The executive includes everything that runs in kernel mode. Above the executive are the Protected Subsystems. These subsystems provide implementations of different Operating System personalities.

The Executive

The Executive is all the code that runs in kernel mode. The executive can roughly be broken up into the following components: Hardware Abstraction Layer (HAL), Device Drivers, The Kernel, System Services (including the Win32k subsystem) These components all run in kernel mode. The HAL, Kernel, System Services and Device Drivers are collectively referred to as the Executive.

Hardware Abstraction Layer

The HAL makes it possible for the x86 ReactOS kernel and HAL to run on different x86 motherboards. The HAL abstracts motherboard specific code from the kernel, so that different motherboards do not require changes in the kernel. Examples for different hardware designs are the standard PC, the Japanese NEC PC98 or x86 SGI workstations.

Device Drivers

Device drivers are hardware specific extensions to the ReactOS Executive. They allow the Operating System to interact with certain devices and visa versa. ReactOS currently aims to implement the NT driver mode, of which the Windows Driver Model (WDM) is a subset of. WDM is a set of rules for writing portable Windows drivers. The Windows Driver Foundation (WDF) introduced in Windows Vista is also a consideration for future development.


Device drivers use packets to communicate with the kernel and with other drivers. Packets are sent via the I/O Manager (System Service) and make use of IRPs (I/O Request Packets).


The kernel design is based on that of Microsoft Windows 2003 Server. It implements kernel mode Asynchronous Procedure Calls (APCs), Deferred Procedure Calls (DPCs), processes, threading, mutexes, semaphores, spinlocks, timing code, and more.

System Services

System services include: IO Manager, Configuration Manager, Plug and Play, Power Manager, Memory Manager, Executive Support, Object Manager, security reference monitor, process structure, local procedure call, Win32 Subsystem.

Protected Subsystems

The Protected Subsystems allow different Operating System personalities to run on top of the ReactOS Executive. The initial target for ReactOS was the Win32k subsystem -- however, the Win32k subsystem runs in kernel mode as part of the Executive and is not featured here. For other graphical subsystems, there exists an Interface for Subsystems via the Win32k Subsystem. The Windows NT graphics device drivers are tightly integrated in design with the Win32k subsystem. Due to this it is impractical for a user mode subsystem to interact directly with the graphics drivers. For this reason, a subsystem should make use of the kernel mode Win32k subsystem for a graphics interface. Such a subsystem need not depend on the Win32k Window Manager, but can instead just use the graphics primitives provided by the Win32k subsystem.

Native API Architecture

The Native API Architecture calls for user mode code to call kernel mode services in a standard manner. It is the equivalent to the System Call Interface used by most UNIXes. Microsoft Windows NT/2000/XP does not document the Native API Architecture for programmers, they must use the Win32 APIs instead. Since ReactOS is Open Source, our Native API Architecture is open to the application programmer. The Native API Architecture is implemented in NTDLL.dll. Aside from containing Native API user mode entry points, NTDLL.dll also contains process startup and module loading code. These entry points call KiSystemService in kernel mode, which looks up the kernel mode service in a system table - KiSystemServiceTable.

Compatibility Targets

The original target for ReactOS, with regards to driver and application compatibility, was Microsoft Windows NT 4.0. Since then, Microsoft Windows 2000, XP, 2003 Server, and Vista have been released. All these are descendants of Windows NT. As such we can gradually shift our compatibility target without worrying about the architecture changing too much. In fact, internally, Windows 2000 reports version information as Windows 5.0, XP as Windows 5.1, 2003 Server as Windows 5.2, and Vista as Windows 6.0. The ReactOS team currently targets Windows 2003 Server as the official compatibility target. Of the current releases, 2003 Server has proven one of the most robust. This does not mean that features present in later versions of Windows NT based operating systems will not be implemented in ReactOS and work is continually done to implement newer APIs.