Some patches wait a long time for their moment. Initial support for Job Objects was merged into the ReactOS code base on Saturday, August twenty second, 2026, through pull request 7500, with the original work on this feature dating back nearly a decade. Job Objects are the Windows kernel primitive that lets a group of processes be managed as a single unit, which is how browsers build sandboxes and how services enforce resource limits. The implementation targets pre Windows 8 behaviour and leaves some features unimplemented, but the basic support now works.
The short answer
ReactOS merged initial support for Job Objects, the Windows kernel primitive that manages groups of processes as a single unit for resource limits, collective termination and security restrictions. Browsers depend on it for sandboxing, and various services and daemons use it for their own limits. The implementation targets pre Windows 8 functionality and leaves some features unimplemented, but the basic support is working after code that dates back nearly a decade.
Reimplementing an operating system is mostly invisible work, and the parts that take longest are rarely the parts anyone notices. This one is a good example: a kernel primitive with no user interface, no visible behaviour, and a hard dependency sitting on top of it in almost every serious Windows application.
What a Job Object does
The Windows kernel treats a job as a container for processes. You create one, assign processes into it, and from then on the job is the thing you operate on.
Three capabilities follow from that. Resource limits apply to the group as a whole, so a memory cap covers everything inside the job together instead of being enforced separately on each process. Collective termination means closing the job ends every process in it at once, which removes the classic problem of a parent dying and leaving orphaned children running. Security restrictions can be applied to the set rather than one at a time.
If you come from Linux, cgroups are the closest reference point, and the resemblance is real enough to be useful as intuition while being wrong in the details. Both exist because managing processes one at a time does not scale to how modern applications are actually built.
Why applications will not start without it
The reason this is a compatibility item rather than a nice addition is that modern Windows software does not treat Job Objects as optional.
Web browsers are the clearest case. A multi process browser puts renderer processes into jobs so that untrusted page content runs inside something the browser can constrain and tear down as a unit. That is not a performance optimisation, it is the sandbox. A browser that cannot create a job is a browser whose isolation model has quietly failed, which is worse than one that refuses to launch.
Beyond browsers, various services and daemons use jobs to enforce their own resource limits. The pattern is common enough that an operating system missing the primitive hits a wall repeatedly, in different applications, for the same underlying reason.
This is why the merge is worth reporting even though nothing user visible changes. Compatibility work of this kind does not improve software that already runs. It shortens the list of software that cannot run at all.
Initial support, and what that qualifier means
The honest framing is the one the project itself uses. This is initial support: the code targets pre Windows 8 functionality and some features are not yet implemented.
That qualifier deserves attention rather than being read past. The job features added in Windows 8 and later, including nested jobs and richer limit types, are precisely the ones contemporary software has come to expect, since applications are written against whatever the current platform offers. Covering the older functionality level establishes the primitive and gets basic cases working. It does not finish the job, in either sense.
So the correct expectation is not that a modern browser now runs under ReactOS. It is that a structural gap has been filled, and the work above it can begin.
The decade
The detail that gives this story its shape is that the original Job Objects code for ReactOS dates back nearly a decade before it merged.
It is tempting to read that as a project moving slowly, and worth resisting. Job Objects sit at the intersection of process creation, process termination and security, which is the region of a kernel where mistakes are least visible and most damaging. An implementation that is subtly wrong does not fail loudly; it produces behaviour that diverges from Windows in ways that show up much later, in unrelated software, as bugs nobody can trace back.
Merging code like that requires a reviewer who knows all three areas well and has the time to work through the whole series. In a volunteer project, that reviewer is the bottleneck, not the code. A decade in the queue is what scarcity of deep review looks like, and it is the same constraint that shapes progress across the project.
Where it sits on the road to NT6
Job Objects are one piece of the broader effort to reach Windows NT6 compatibility, the boundary between running software from the Windows XP era and running anything contemporary. Recent milestones on that path include the first NT6 system call landing and Half-Life 2 running under the system.
Those two are the visible kind of progress, the sort that produces a screenshot. Job Objects are the other kind, and they are the reason the visible ones eventually become possible.
For comparison, the other major open source project in this space takes the opposite approach: Wine, which added VA-API video decoding in version 11.16, reimplements the Windows API on top of an existing kernel. ReactOS is reimplementing the kernel itself, which is why it inherits problems like this one and Wine does not.
Nobody should switch to ReactOS on the strength of this merge, and the project remains a long term reimplementation rather than a daily driver. But the list of reasons modern Windows software cannot start on it is one item shorter than it was last week, and that list is the only metric that really counts.
Sources and further reading
- ReactOS Merges Support For Job Objects As Step To Running Modern Windows Apps, Phoronix, August 23, 2026
- ReactOS Adds First NT6 Syscall NtGetCurrentProcessorNumberEx, Windows Forum
- ReactOS Starts 2026 With Another Major Step Toward Windows NT6 Compatibility, LXer
Frequently asked questions
What is a Job Object in the Windows kernel?
It is a kernel primitive that lets a group of processes be managed and controlled as a single unit. You create a job, assign processes to it, and then act on the job rather than chasing individual process IDs. Three uses dominate. Resource limits, where a cap on memory or CPU applies to everything in the job together rather than per process. Collective termination, where closing the job kills every process inside it at once with no orphans left behind. And security restrictions, where a set of processes is constrained as a group. The nearest concept on Linux is a cgroup, though the analogy is loose and the mechanisms differ.
Why does this matter for running modern Windows applications?
Because modern applications assume it exists. Web browsers are the clearest case: multi process browsers put renderer processes into jobs so that a compromised or crashed tab is contained and can be torn down cleanly, which is the backbone of the sandbox model. Various services and daemons also rely on jobs to enforce their own limits. On an operating system without Job Objects, an application that expects to create one either fails outright or silently loses its isolation, and neither outcome is acceptable for software you actually want to run.
Is this complete? Can ReactOS run a modern browser now?
No on both counts. The merged code targets pre Windows 8 functionality and leaves some features not yet implemented, so this is initial support rather than a finished subsystem. That distinction matters, because the newer job features are exactly the ones later Windows versions added for nested jobs and richer limits, which modern software increasingly assumes. What the merge delivers is the basic support working and the primitive existing at all, which is the prerequisite for the rest. Treat it as a foundation being laid, not a compatibility milestone reached.
Why did code written nearly a decade ago only merge now?
That gap is normal for volunteer reimplementation work on a kernel, and it says more about review capacity than about the code. Job Objects touch process creation, termination and security, three of the most sensitive areas in any kernel, and a subtly wrong implementation produces bugs that surface far from their cause. Merging requires a reviewer with deep familiarity across all of it and enough time to work through the series, which is the scarcest resource an open source operating system project has. The original code existing for years is not neglect so much as a queue.
How does this fit with the rest of the ReactOS roadmap?
It is one item in a broader push toward Windows NT6 compatibility, which is the line that separates running software from the Windows XP and Server 2003 era from running anything contemporary. Recent progress on that path includes the first NT6 system call landing and Half-Life 2 running under the system. Job Objects belong to the same effort from the kernel side rather than the API surface side. None of these individually make ReactOS a daily driver, and the project remains a long term reimplementation. Each one removes a specific reason an application refuses to start.