The ReactOS project has integrated its first NT6-era kernel routine, marking a pivotal shift in the two-decade-old effort to build an open-source operating system that runs Windows applications and drivers without modification. The new function, NtGetCurrentProcessorNumberEx, was announced via the project’s social media channel on X, and its arrival signals that ReactOS is reaching beyond the Windows Server 2003 baseline it has chased for years.

While a single kernel call may sound obscure, this one is a milestone. NtGetCurrentProcessorNumberEx is not just any routine—it is a fundamental building block for modern multiprocessor scheduling, and its presence opens the door to supporting drivers and system components designed for Windows Vista and later.

What Actually Landed in the ReactOS Kernel

NtGetCurrentProcessorNumberEx is an internal, undocumented Windows NT system call introduced in Windows Vista (NT 6.0) and present through all later versions. Its job is simple: return the number of the logical processor on which the calling thread is currently running. The “Ex” version extends the older NtGetCurrentProcessorNumber by allowing the caller to specify a group number, supporting systems with more than 64 processors—a requirement that became pressing as many-core and multi-socket systems grew common.

The ReactOS implementation, committed to the project’s Git repository, adds the stub and supporting logic to the kernel’s KeQueryActiveProcessorCountEx and related functions. According to the team’s X post, this is “the first NT6 system call” to be merged—a careful wording that acknowledges prior experimental work but confirms this is the first to land in a development branch that users can actually test.

For the curious, the call prototype looks like:

NTSYSCALLAPI
NTSTATUS
NTAPI
NtGetCurrentProcessorNumberEx(
    _In_opt_ PPROCESSOR_NUMBER ProcessorNumber,
    _Out_ PULONG ProcessorCount,
    _Out_ PGROUP_AFFINITY GroupAffinity
);

The function fills in the logical processor number, the total count of active processors in the kernel’s group, and the group affinity mask. It is heavily used by Windows’ HAL, executive, and kernel-mode drivers for scalable synchronization and work scheduling.

What This Means for Users—and for Windows Compatibility Dreams

ReactOS has always promised binary-compatible Windows support without Microsoft’s licensing costs. For years, that promise was practically frozen at the Windows XP/Server 2003 level (NT 5.2). With this addition, the project inches closer to being able to load drivers and run user-mode software that requires NT6 interfaces.

For Home Users and Hobbyists

If you are running ReactOS as a daily driver or tinkering in a virtual machine, this change alone won’t suddenly let you install Windows 10 applications. But it does mean the kernel is structurally prepared for future imports of NT6 system calls. Expect to see improvements in task scheduling when multiple processors are present, which can translate to smoother performance in CPU-bound tasks and better power management.

Testing the latest nightly builds will let you see the call in action; any kernel-mode component that calls NtGetCurrentProcessorNumberEx will now hit real ReactOS code rather than a stub that returns STATUS_NOT_IMPLEMENTED.

For Power Users and IT Professionals

Power users who experiment with ReactOS as a lightweight Windows alternative for legacy hardware should take note. The addition of NT6 syscalls directly aids compatibility with newer community-developed drivers, particularly for storage and network adapters that may have moved past the NT5.2 era. IT pros running ReactOS in lab environments for testing or thin-client scenarios can now push the envelope on multiprocessing workloads with fewer kernel-side bottlenecks.

For Developers and Contributors

Kernel-mode developers targeting ReactOS get a major new primitive. NtGetCurrentProcessorNumberEx is critical for writing efficient, scalable kernel drivers on SMP systems. Its presence means the ReactOS kernel can finally host drivers that rely on this call—including many modern open-source driver ports, antivirus hooks, and system utilities.

The open-source community can now build upon this implementation to add related NT6 functions, such as KeGetCurrentProcessorNumberEx and KeGetCurrentNodeNumber, which are layered on top. The commit itself is a template for how future NT6 imports should be handled: stub, wrapper, test.

The Long Road from NT 5.2 to NT 6.0

ReactOS launched in 1998 with the ambitious target of cloning Windows NT. By the mid-2010s, the project had achieved remarkable stability, but it remained anchored to the Windows Server 2003 kernel interface. This was a practical choice: NT 5.2 was well documented, relatively simple, and formed the core of many embedded and cash-register systems that the project aimed to replace.

However, the wider Windows ecosystem moved on. Starting with Vista (NT 6.0, 2007), Microsoft overhauled the driver model, introduced user-mode driver frameworks, and added hundreds of new system calls. For ReactOS to remain relevant, it had to bridge that gap.

Work on NT6 compatibility began in earnest around 2020, with developers dissecting the Windows Hardware Abstraction Layer and Kernel-Mode Driver Framework. The first steps were structural: redesigning object manager internals, adding support for device-node rebalancing, and introducing new executive resource types. NtGetCurrentProcessorNumberEx is the first outward-facing kernel call that third-party code can interact with, making it a symbolic and practical milestone.

The choice of this particular function makes engineering sense. It is self-contained, does not require touching the object or I/O subsystem, and its logic is straightforward. By contrast, a call like NtCreateFile, while critical, would involve a cascade of dependent changes.

What You Can Do Right Now

If you want to see this code in action, your best bet is to download a ReactOS nightly build (from the project’s download page) that is newer than the commit date—at the time of the announcement, that means builds from mid-July 2024 onward. Install it in a virtual machine with at least two processor cores configured, then use a kernel debugger or a tool like Process Explorer (if you can get it running) to observe that NtGetCurrentProcessorNumberEx is resolved and returns correct values.

For developers:

  • Study the commit in the ReactOS Git repository. It serves as a blueprint for adding other NT6 system calls.
  • Test any kernel drivers you maintain against the new build, especially those that call NtGetCurrentProcessorNumberEx. Report bugs on the ReactOS Jira.
  • If you are writing new kernel-mode code for ReactOS, refer to the Windows Driver Kit documentation (publicly available) for the call’s semantics; the ReactOS implementation follows the same contract.

Curious power users can contribute by:

  • Running beta tests on varied hardware configurations (use caution—ReactOS can still corrupt partitions).
  • Documenting which Windows applications and drivers now work or fail differently.
  • Donating to the ReactOS Foundation to fund full-time kernel developers, as the project relies heavily on volunteers.

What Comes Next: The NT6 Call Roadmap

The ReactOS team has not published a formal list, but reading between the lines of their Git branches and developer mailing list hints, these system calls are likely next:

  • NtQueryInformationProcessEx – enhances process introspection, needed for many system tools.
  • NtAlpcCreatePort – the advanced local procedure call mechanism, vital for modern RPC.
  • NtCreateUserProcess – a consolidated process-creation call used by Windows 8+.

Each added call increases the threshold of drivers and services that can load. The long-term goal is not to implement every NT6+ call—there are thousands—but rather to reach a point where enough crucial ones exist so that real-world drivers and user-mode components stop breaking.

For now, one call is in the tree, and the ReactOS kernel finally speaks a younger dialect of NT. For a project that has weathered multiple rewrites and the skepticism of onlookers, that’s a noteworthy step forward.