WinDurango: an Xbox One translation layer for running UWP games on Windows

What a translation layer actually is here

WinDurango is an Xbox One Translation Layer which allows you to play various era based games on Windows via UWP. The repository description calls it the world's first Xbox One compatibility layer for Windows.

The About section gives the scope more precisely. WinDurango has implemented most of the essential Xbox WinRT interfaces, KernelX and D3D11.X. Kinect support is completely experimental and has not been tested, and the README says to expect issues.

That is the whole mechanism, and it is worth being clear about what it implies. An Xbox One game is a UWP application that talks to the console operating system through a set of WinRT interfaces, some of which are Xbox specific. A translation layer implements those Xbox specific interfaces on top of Windows, so the game believes it is running on a console and the underlying calls land on the PC. KernelX is the kernel-mode counterpart, and D3D11.X is the Xbox variant of the Direct3D 11 graphics interface, so a translation layer has to stand in for the graphics API too, not just the system calls.

The repository layout matches that. There is an `idl/` directory for the interface definitions, which is where the reverse engineered signatures live, and a `projects/` directory for the implementations, alongside the `assets/` directory and the CMake build files, with `vcpkg.json` and `vcpkg-configuration.json` for the dependency set.

The primary language in the metadata is C++, the licence is LGPL-3.0 with a `LICENSE` file at the root, the default branch is main, and the last push was on 2026-10-02. There are no GitHub releases.

Playable versus boots, and why the distinction matters

The Playable Games list is short, and it uses two states that are worth understanding before you try anything.

The list names Sonic Mania as playable, Minecraft: Xbox One Edition version 1.2.0.0 as playable, and LIMBO as playable. Then it names Minecraft: Xbox One Edition versions 1.61.X.X as boots, Forza Horizon 2 and its variants as boots, Forza Motorsport 5 as boots, and Peggle 2 as boots.

So the project distinguishes a game that runs correctly from a game that starts and then fails. A game that boots gets past the start-up, the process launches and the title screen appears, and then something in the graphics path or the system services is missing, so the game does not get further. The screenshots show both kinds of result, with Minecraft and Forza Motorsport 6 among the images, which suggests the differences are visible rather than theoretical.

The roadmap then makes the same point in a list of four unchecked items. Get Minecraft: Xbox One Edition versions 1.61.X.X to a playable state, get Forza Horizon 2 and its variants to a playable state, get Forza Motorsport 5 to a playable state, and get Peggle 2 to a playable state.

That is an honest statement of where the project is, and it is much more useful than a list of supported titles. The titles that boot are the ones where the compatibility work is partially done, and the roadmap is the list of things that need the next piece of reverse engineering.

For a user, the practical reading is that this is a demonstration layer with a handful of working games, and the first-ever claim in the repository description should be read as a statement about the category rather than about the playability of the catalogue.

Building it, which needs Visual Studio 2026 and vcpkg

The prerequisites are Visual Studio 2026 with the C++ extension, vcpkg and cmake.

The build steps are given as a numbered list, and the first two are the clone and the dependency install:

git clone https://github.com/WinDurango/WinDurango

vcpkg install

Then a build directory and a cmake configure:

mkdir build && cd build
cmake ..

And the configure that points cmake at the vcpkg toolchain:

cmake .. -DCMAKE_TOOLCHAIN_FILE="$env:VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake"

The instructions say to open the VS 2026 Powershell Prompt before starting, which matters because the vcpkg toolchain path in that last command is an environment variable and a PowerShell session started from Visual Studio has it set.

The build files are a modern CMake layout, with `CMakeLists.txt`, `CMakePresets.json` and `CMakeSettings.json`, the last of which is what Visual Studio reads to configure the project for you.

The dependency manifest is `vcpkg.json` with a separate `vcpkg-configuration.json`, so the package set is declared in the repository rather than being whatever happens to be installed on a machine, which is the right arrangement for a project with native dependencies and several build configurations.

Installing it means hand-placing DLLs into a game folder

The installation is the part that tells you what kind of project this is.

You get the DLLs from GitHub Actions, so there is no published release to download. You copy the DLLs into the mount directory in your game. You enable Developer Mode. You install the game by opening PowerShell in the folder that contains `AppxManifest.xml` and running:

Add-AppXPackage -Register .\AppxManifest.xml

Then you add the `EmbeddedXvd` folder to the folder that has the game executable, which is usually `Mount`, and pick certain DLLs from EmbeddedXvd and drop them in the same folder as the executable: `xg_x.dll`, `xg.dll` if present, `AcpHal.dll`, `xaudio2_9.dll`, `D3DCompiler46.dll` if present, and `sc_dll.dll` if present.

Two details in that list are informative. The three marked if present are the ones the translation layer does not always implement, and the README asks you to get in touch if a game complains about a missing DLL that is neither on the list nor implemented.

So the flow is: obtain a legitimately purchased UWP game package, unpack it, register it with Windows as an unsigned application, and drop a set of compatibility DLLs next to the executable. Developer Mode is required because the package is registered without a store signature.

That is a legitimate and well-understood way to run a store application you own outside the store, and it is the same category of activity as the classic side-loading of Windows Store apps. It does mean the installation is manual, per game, and depends on the state of the build in the Actions tab rather than on a version you can pin.

Requirements, and the honesty about not knowing them

The minimum requirements section is unusually candid, and the honesty is the useful part.

WinDurango does not have a fixed and correct minimum requirements list, because some games are more demanding than others, with Minecraft using far less system resources than Forza. The README then offers a speculated set that should supply the needs of most games.

The speculation is a CPU with at least four cores, for example an Intel Core i5 4690K, a GPU with at least 2GB of VRAM, for example an NVIDIA GeForce GTX 960, 12GB of RAM, DDR3 or newer, and Windows 10 or newer.

Those numbers are modest for a modern machine, and the examples named are from around 2015. That is consistent with the era of the software being emulated rather than with the era of the host hardware, and it is a reasonable expectation for the games on the list.

The one requirement that is not negotiable is the operating system, since the whole approach depends on the UWP application model and on the Windows graphics stack that D3D11.X is translated onto. There is no path to running this on macOS or Linux, which follows from the project being a Windows translation layer rather than an emulator of the hardware.

The disclaimer, and the licence

The disclaimer is short and it is the section to read before anything else.

The goal of the project is to experiment, research and educate on the topic of emulation of modern devices and operating systems, and it is not for enabling illegal activity. All information is obtained via reverse engineering of legally purchased devices and games, and information made public on the internet. The project is in no way affiliated with Microsoft.

That framing is consistent with how the project works. The translation layer is not a crack and it does not generate or unlock content. It requires the game to be present on disk, it registers the UWP package from its own manifest, and the reverse engineering applies to the operating system interfaces rather than to the game. The one thing it does require is Developer Mode, because the package is registered unsigned.

The licence is LGPL-3.0, which is a reasonable choice for a project that is meant to be studied and extended, and it is a different licence from the permissive ones a commercial project would usually reach for, so an organisation with a licence policy should read `LICENSE` before using it.

The project is also explicitly not affiliated with Microsoft, and that sentence is in the disclaimer because the name and the subject matter make the association obvious and the disclaimer exists to say it is not real.

The rest of the README is a standard contribution guide, with a fork and pull request flow and a feature branch named `feature/AmazingFeature`, a Discord for contact, and a Code of Conduct file at the root.

Where WinDurango is the wrong tool

The first wrong case is a user who does not own the game. The project explicitly does not enable illegal activity, and the installation flow assumes a UWP package that you own. There is no catalogue of games the layer can unlock, and if you are looking for that, this is not it and will not become it.

The second is a project that needs a stable, pinned dependency. There are no GitHub releases, the DLLs come from the Actions tab, and the state of the build changes with every commit to the branch. A deployment that pins a version of this is pinning a set of binaries that was produced by a specific CI run and cannot be reproduced from a tag.

The third is anyone who wants a game to work rather than a game to start. Three titles are playable and four more boot without being playable, and the roadmap is a list of the four that need work. If a game is on the boot list, the layer gets you past the start-up and no further, and the difference between a start-up and a working title is where the real reverse engineering effort lives.

The fourth is a Mac or Linux user. The project is a Windows translation layer over UWP applications, and the D3D11.X translation in particular is tied to the Direct3D stack on Windows.

The fifth is a production or commercial deployment. This is a research project, the licence is LGPL-3.0, and the maintainers describe it as an experiment. The Kinect support is described as completely experimental and untested, which is a fair signal for the rest of the codebase too.

For the case it was built for, which is learning how a console operating system is reimplemented on a desktop one, the repository is unusually good, because the interface definitions in `idl/` are the actual artefact of the reverse engineering and they are published rather than hidden.

Editorial conclusion

WinDurango suits someone who owns an Xbox One era game on disk and wants to run it on Windows, and who is prepared to install unsigned packages, enable Developer Mode and hand-place DLLs into a game folder, and it suits a student of how a console operating system is reimplemented on top of a host one. It does not suit anyone without the game already, and it does not suit a project that needs a maintained dependency, since there are no releases, the build requires Visual Studio 2026 and vcpkg, and the roadmap is four unchecked items. Before trying it, read the disclaimer, which states that the goal is to experiment, research and educate on emulation, that the information is obtained by reverse engineering legally purchased devices and games, and that the project is not affiliated with Microsoft.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. Project website
4. README
5. WinDurango/WinDurango on GitHub