ReXGlue recompiles Xbox 360 PowerPC code into portable C++

Recompilation instead of emulation

ReXGlue converts Xbox 360 PowerPC code into portable C++ that runs natively on modern platforms. That sentence is the whole project, and the interesting part is the negative space in it.

The conventional approach to running code written for another architecture is to interpret it or to JIT compile it at runtime. An emulator does exactly that: it fetches each PowerPC instruction, decodes it, and either performs the equivalent host operation or emits host code for it. That works, and it is what Xenia does for the Xbox 360.

ReXGlue takes a different path, and the readme says so explicitly: rather than interpreting or JIT compiling PPC instructions at runtime, it generates C++ source code ahead of time. The output is source code, not a process, which means the result compiles with your own compiler, runs at whatever speed the host CPU allows, and can be read, stepped through and profiled like any other C++ program.

That is the appeal for the target audience. A recompiled binary is not bound to an emulator's scheduling, its memory model or its GPU abstraction, so it can run on a platform the emulator does not support, and it can be linked into a larger native program rather than launched as a separate process.

The repository is the SDK and the runtime together, described as the Xbox 360 Recompilation Runtime and Toolkit, and the primary language is C. The project is not archived and the last push was on 2026-10-02.

The audience is people working with Xbox 360 software outside of the commercial channel: homebrew developers, people writing tools that need to run the console's code on a desktop CPU, and researchers interested in the architecture.

The lineage is Xenia, XenonRecomp and rexdex

The credits in the readme are unusually specific about where the work came from, and for a project like this that matters, because recompilation of a closed console's code is not something you start from a blank page.

ReXGlue is heavily rooted on the foundations of Xenia, the Xbox 360 emulator, and the project states plainly that the work of the Xenia team on Xbox 360 emulation laid the groundwork and that the project would not exist without it. The specific thanks to XenonRecomp say that a lot of the codegen analysis logic and instruction translations are based on that work, and that it pioneered the modern static recompilation approach for the Xbox 360. And rexdex's recompiler is credited as the original static recompiler for Xbox 360.

The named contributors show where the work is happening. Tom, known as crack, is the project founder. Loreaxe is the Linux contributor, Carlos Estrague, known as mrcmunir, is a Linux and ARM64 contributor, mystixor is the Windows contributor, sanjay900 is a Linux and SDL contributor, Roxxsen handles CI and CD, and Graine25 and Toby are listed for project support.

The platform coverage in the build table matches that split. The release channel has CI for win-amd64, linux-amd64 and linux-arm64, and the nightly channel has its own workflow, so the project is built on all three target platforms rather than on one.

For a reader deciding whether to follow this, the lineage is the strongest signal available. The Xbox 360 homebrew and modding communities have been doing this work for years, and the readme thanks many others in those communities whose research has contributed to the collective knowledge.

Two channels, and a nightly for every commit

The build table is small and it is the clearest operational fact about the project.

There is a Release channel, with three CI workflows behind it, one per platform, and a download link to the latest stable release. There is a Nightly channel, with its own workflow, and a download link to the latest pre-release.

The release names make the cadence visible. The three most recent are nightly-20261002-bd833a2a with the version 0.10.0.24-dev.gbd833a2, nightly-20261001-ea222e98 with 0.10.0.23-dev.gea222e9, and nightly-20260930-7f7c92ef with 0.10.0.16-dev.g7f7c92e. The pattern is a date, a commit hash, and a semantic version with a dev suffix and the abbreviated commit embedded, so a nightly artefact can be traced to an exact commit.

That is a good design for a fast moving tool, and it has an obvious cost for consumers. A nightly is not a stable artefact, and the version numbering shows that the project is on the 0.10 line with a development suffix, which by the usual conventions means the public interface is not settled.

The readme confirms that in a caution box at the top. The project is in early development, it says to expect things to not work quite right and to expect significant changes and breaking public API updates as development progresses. Contributions and feedback are welcome, but the codebase is still evolving rapidly.

So the practical advice is to decide which channel you consume. The stable release for anything you depend on, and the nightly only when you are testing a change or building something that needs a fix that has not landed in a release yet.

A CMake project with a CLI, and documentation in the wiki

The repository layout is a conventional C and C++ project with a modern build description.

There is a CMakeLists.txt at the root with CMakePresets.json beside it, and a cmake directory holding the module files, a scripts directory, a tools directory, a tests directory, a thirdparty directory for vendored dependencies, an include directory for the public headers, a src directory for the implementation, a docs directory, and a resources directory. The .gitmodules file is there because the third party dependencies are submodules rather than vendored copies, and the formatting configuration is thorough, with .clang-format for C, .clang-tidy for the static analysis, .cmake-format.yaml for the build files themselves and .editorconfig for everything else.

The readme does not contain a command to run, and it says so. For the quick start guide, the full CLI reference and the config file options, it points at the wiki.

That arrangement is a real choice about where the documentation lives. A repository README that stays short and points at a wiki keeps the front page readable, and it lets the CLI documentation grow with the tool without the front page becoming a manual. It also means the reference is not in the tree, so it is not versioned with the code and it is not diffable in a pull request, which is a genuine cost for a project whose CLI is its interface.

So the workflow for a new user is: install a build, run the tool, and read the wiki for what the flags and the config file options do. The repository tells you the tool is CMake based and that it ships a CLI with a configuration file, and the wiki is where the details live.

What the early development warning means in practice

The caution box is the most useful paragraph in the readme, and it deserves to be read as an engineering constraint rather than as a disclaimer.

A static recompiler is a compiler for a language nobody has a specification for. The tool has to know the calling conventions, the register conventions, the instruction semantics and the calling ABI of a console it does not have documentation for, and it has to infer all of that from binaries and from the work of the emulator community. When the source of truth is reverse engineered rather than published, the odds are that any given build gets some part of it subtly wrong, and that the wrongness shows up as a miscompiled function rather than an error message.

The consequence for you as a user is that the failure mode is not a crash with a stack trace, it is a program that behaves incorrectly. So the operational advice follows from the project itself: treat the output as something you validate, keep the stable release for anything you depend on, and expect to rebuild when the tool changes.

The project does not pretend otherwise. It says to expect things not to work quite right, it says the codebase is evolving rapidly, and it warns about breaking public API updates. A project that is candid about that is more usable than one that presents a stable interface it cannot honour, and the instruction to expect breakage is the one to plan around, not the one to be annoyed by.

The Discord server is the coordination point, and the readme invites you to join it for updates and to share what you have created, which is the natural way to find out whether the function you care about has been fixed yet.

The licence file and the piracy disclaimer

Two things in the readme need to be read carefully by anyone thinking about adopting this.

The first is the licence. The licence field in the repository metadata is described as a custom one that GitHub cannot classify, and the LICENSE file at the root of the repository holds the terms. The readme does not name a standard licence, so the file is the only source, and for a project of this kind that is exactly the document a legal reviewer will ask for first.

The second is the disclaimer, which is longer and more specific than the usual one. ReXGlue is not affiliated with nor endorsed by Microsoft or Xbox, and it is an independent project created for educational and development purposes, with all trademarks and copyrights belonging to their respective owners. It then states that the project is not intended to promote piracy nor unauthorized use of copyrighted material, and that any misuse of this software to endorse or enable this type of activity is strictly prohibited.

That is a meaningful position to take in a project whose whole function is to make console code run on a desktop. A recompiler is a legitimate and well established research and homebrew technique, and the same tools are used for legitimate interoperability, preservation and research work, but the same tools can also be used to run commercial games without a licence, and the project says in advance that that is not what it is for.

For an organisation, the practical reading is that you should be able to state, without hedging, what you are doing with it. If your use is research, preservation, tooling or interoperability, the disclaimer supports you. If your use is running a game you do not own, the disclaimer does not, and the licence file is where the specifics live.

Editorial conclusion

ReXGlue is worth adopting if you are working on Xbox 360 homebrew, tooling or research and you want the game's PowerPC code to run natively on a modern CPU rather than inside an emulator, because the ahead of time C++ output is portable, inspectable and debuggable in ways that a runtime translator is not. It is the wrong choice if you need a stable API today, because the project states that the public API is changing and that you should expect significant breakage. Before you build anything on it, read the wiki for the CLI reference and config file options, check the licence file rather than the badges, and note that the last push was on 2026-10-02 with the latest published build being a nightly.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. rexglue/rexglue-sdk on GitHub