One-Core-API: a ReactOS derived compatibility layer for Windows XP and Server 2003
A complete layer to get compatibility on XP/2003 for newer applications
At a glance
- What is it?
- One-Core-API is a C project that takes the ReactOS source tree and adds the newer Windows APIs, DLLs, drivers and API sets that XP and Server 2003 lack, so that software written for Vista and later can run on the older systems. It is built with the ReactOS build environment, it is a one-developer project, and it requires a specific RosBE version and an old Visual Studio.
- Who is it for?
- One-Core-API is worth knowing about if you maintain a machine that cannot be upgraded, because it is the most complete attempt to give XP and Server 2003 the API surface that current applications expect, and the list of software it runs is a useful catalogue of what has to be shimmed.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 53 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
ReactOS as the base, with the Vista API surface added on top
One-Core-API is a project that provides a complete layer to get compatibility on XP and 2003 for newer applications. The README says the source code is based on ReactOS source and uses ReactOS's build environment, and that it is compatible with Windows Server 2003 SP2, Windows XP SP3 and Windows XP x64 SP2.
The framing matters more than it might look. This is not a set of stub DLLs dropped into a system, it is a large body of operating system source, which is why the top-level directory listing looks like an operating system rather than like a shim library. There is ntoskrnl/ for the kernel, base/ for the base libraries, dll/ for the user mode libraries, drivers/, hal/ for the hardware abstraction layer, subsystems/, win32ss/ for the windowing subsystem, sdk/ for the headers and libraries, boot/, modules/, media/ and apistatus.lst, which is the file listing the API set contents.
The project description says it contains all ReactOS code plus additions of wrappers, new DLLs present in Windows Vista, drivers and API-SETs. The API sets are the mechanism that makes this work, since they are how modern Windows resolves a family of function versions, and a system that predates them has no way to answer that lookup.
The oca/ directory is visible at the root as well, and the configure scripts, configure.cmd and configure.sh, are the entry points for generating a build tree. The toolchain files make the supported compilers explicit, with separate files for clang, gcc and msvc, plus overrides-msvc.cmake and overrides-gcc.cmake.
All the code related to One-Core-API itself is in the wrappers folder, and the project is licensed under GPL-2.0 with the COPYING files at the root.
The list of applications that run is the real specification
The most informative part of the README is the list of programs the project says you can run with One-Core-API, and it is a specification of what has to be shimmed rather than a feature list.
On the development side, Web Storm 2018, Intelliji 2018 with the note that maybe other versions work, Visual Studio Code 1.81, and PyCharm-adjacent tooling are named. On the browser side, Chrome up to version 123, Opera up to version 106, and Firefox up to version 122, which is a striking set of versions to get running on an operating system from 2001.
The runtime side covers JDK 1.8, Python 3.6, the .Net Framework up to 4.8, Maxthon 5.1, and K-Lite Codec 15 plus. There is also Geekbench 4.2, a Performance Test entry, Adobe Reader DC from 2021, Windows 7 games, Vista Applications, Filezilla at the latest version, and a final line for several other applications.
Two things stand out. First, the list is dominated by things with a Java or .Net runtime, and a modern Java runtime or .Net Framework is exactly the kind of software that hard-codes a large set of newer Windows API calls. Second, the Adobe Reader and Windows 7 games entries show the project is not only about developer tools.
The Adobe Reader entry and the Chrome entry together define the problem. Both are applications that ship their own browser engine or use system APIs that changed substantially after XP, and both are mainstream enough that a business still running them on old hardware would care.
The README is careful to say you can do amazing things installing binaries, which is the project's own phrasing and also its warning, since the same mechanism that runs an application is what can break a system.
The project asks for patience because it has one developer
The second paragraph of the README is unusual and worth reading as a project document rather than skipping.
It states that this is software that uses modified files from the respective systems, contains other files still in the testing or experimental phase and has only one developer. In other words, it is impossible to predict all possible scenarios on all possible types of computers or virtual machines.
The reason given for the difficulty is structural rather than a matter of effort. Between XP and 2003 and Vista there was the biggest leap in new APIs, new technologies and modifications to existing APIs, so it is very difficult to have the same level of compatibility in NT5 as in NT6.
That is the honest technical framing of the whole project. The leap from NT5 to NT6 is not one missing function, it is a change in the platform's design, and closing that gap in the other direction means reimplementing behaviours that the newer system simply assumed.
The README then asks readers to be calm and prudent, to report defects in the issues rather than dismissing the software, and it says that complaining or defaming does not do anyone any good. That is a defensive posture, and it tells you something about the expectations: this is a single-maintainer project where each bug report has to be reproduced, analysed and corrected by one person, and the terminology in the report matters more than usual.
The maintenance picture is consistent with that. The release history shows 4.6.0 and 4.5.0 both dated 2026-08-31 and 4.4.0 from 2026-07-13, and the last push was on 2026-08-31. The repository is not archived.
Building it means RosBE 2.1.6 and Visual Studio 2010 or 2012
The build requirements are narrow and specific, and the project is explicit that newer versions do not work.
Only the Visual Studio Solution is supported for compiling the code, and you must use ROSBE version 2.1.6. If you try 2.2.0 or later you will get an error. A download link for that exact RosBE build is given, pointing at the ReactOS files on SourceForge:
https://sourceforge.net/projects/reactos/files/RosBE-Windows/i386/2.1.6/Only Visual Studio 2010 and 2012 are supported. The configuration steps are laid out as a numbered list, and they are specific about the output folder layout, because the ReactOS build expects one output directory per architecture. The recommendation is to create an Output-MSVC-i386 folder for x86 and an Output-MSVC-amd64 for x64.
You then open the Visual Studio Command Prompt for your target architecture, which the README describes as living under All Programs in the Visual Studio Tools folder, with separate x86 Native Tools and x64 Cross Tools prompts. From that prompt you navigate to the output folder and run the configure VSSOlution command with the path to the One-Core-API code folder, and a configuration screenshot is included.
When configuration finishes, you open Reactos.sln from the output folder in Explorer, and you build the components you want by right-clicking them and choosing Build. The binaries land in the folder corresponding to the component.
One bug is called out specifically. The x64 target has a problem on the first build, where winnt.h from the Windows Kits, installed by Visual Studio, generates an error when compiling, and the fix is to comment out a line as shown in the screenshot. The project is upfront that the x64 first build needs a manual edit, and that if you apply the fix and the x86 build goes through, you should see the successful build screen.
What the repository contains beyond the One-Core-API additions
Because the project is a fork of an operating system, the repository is a great deal larger than the wrappers, and the top-level listing shows the full ReactOS tree carried along with the additions.
The build system files are the first thing to note. There is a CMakeLists.txt at the root with PreLoad.cmake, the toolchain files and the overrides files, and alongside it are the configure scripts for both Windows and Unix-like shells. The Doxyfile suggests the source is documented with Doxygen, and the .clang-format and .editorconfig files cover formatting.
The CI and environment configuration is spread across several files. There is appveyor.yml, .travis.yml, a .gitpod.Dockerfile with a .gitpod.yml, and a .theia/ directory, which together mean the project builds in several hosted environments. The CODEOWNERS file and CODE_OF_CONDUCT.md sit alongside CONTRIBUTING.md and PULL_REQUEST_MANAGEMENT.md, and a CREDITS file and .gitmessage are present as well.
The licence files are worth a note because there are several. COPYING is the main one, with COPYING.ARM, COPYING.LIB, COPYING3 and COPYING3.LIB, which is the pattern a project with several differently licensed components uses, and the project as a whole is recorded as GPL-2.0.
The INSTALL file is at the root as well, and the .github/ directory holds the workflows. So the repository is, in effect, the whole ReactOS tree plus a wrappers layer, and a developer who wants to understand what One-Core-API actually adds starts in the wrappers folder and works outwards from there.
Editorial conclusion
One-Core-API is worth knowing about if you maintain a machine that cannot be upgraded, because it is the most complete attempt to give XP and Server 2003 the API surface that current applications expect, and the list of software it runs is a useful catalogue of what has to be shimmed. It is the wrong tool for anything that can be reinstalled, since the project says plainly that the gap between NT5 and NT6 in APIs, technologies and modifications to existing APIs is very difficult to close to the same level of compatibility. Before you build it, verify three things yourself: that you have RosBE 2.1.6 rather than 2.2.0 or later, since the project states that a newer version gives an error, that you have Visual Studio 2010 or 2012, since those are the only supported versions, and that you are prepared for the x64 first-build issue, where a line in the Windows Kits winnt.h has to be commented out by hand.
Frequently asked questions
What is One-Core-API?
It is a complete layer that gives Windows XP and Server 2003 compatibility with newer applications. The source is based on ReactOS and uses the ReactOS build environment, adding wrappers, new DLLs present in Windows Vista, drivers and API-SETs on top of the ReactOS code.
Which applications can run with One-Core-API?
The README lists Visual Studio Code 1.81, Chrome up to version 123, Firefox up to version 122, Opera up to version 106, Web Storm 2018, Intelliji 2018, JDK 1.8, Python 3.6, .Net Framework up to 4.8, Maxthon 5.1, K-Lite Codec 15+, Geekbench 4.2, Adobe Reader DC from 2021, Windows 7 games and Vista applications.
What are the build requirements for One-Core-API?
Only the Visual Studio Solution is supported, you must use ROSBE version 2.1.6 because 2.2.0 or later gives an error, and only Visual Studio 2010 and 2012 are supported. The x64 target also needs a line in the Windows Kits winnt.h commented out to get past the first build.
Why does One-Core-API not achieve full compatibility?
The project explains that between XP and 2003 and Vista there was the biggest leap in new APIs, new technologies and modifications to existing APIs, so it is very difficult to have the same level of compatibility in NT5 as in NT6. It also states that it has only one developer and that some files are still in the testing or experimental phase.
What licence is One-Core-API released under?
The project is licensed under the GPL-2.0, with the licence files at the repository root including COPYING, COPYING.ARM, COPYING.LIB, COPYING3 and COPYING3.LIB for the differently licensed components. The last push was on 2026-08-31, with versions 4.6.0 and 4.5.0 released the same day.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/shorthorn-project-one-core-api-source)Was this useful?