AnyPS5 Relinks Console Executables Instead of Emulating the Machine

There is a category of project that trends on GitHub for reasons nobody writes down. AnyPS5 is one of them. It sits at the top of the weekly chart with roughly 16,000 new stars, it has close to 10,000 commits, and its one-line description — "Tool for automatic PS5 executables porting to Linux and Windows" — is the kind of sentence that makes lawyers reach for a pen and engineers reach for a bookmark.

The interesting part is not that it exists. The interesting part is what it refuses to be.

No emulator, no runtime, no console in a window

Most projects that run console software on a PC are emulators. They model the hardware: the CPU, the GPU, the memory layout, the timing. That approach is a marvel when it works and a decade-long grind when it does not, because every game becomes a negotiation with an incomplete model of a machine nobody has full documentation for.

AnyPS5 takes a different route. It ships a relinker that converts a PS5 executable into the target platform's native format, plus implementations of the system prx libraries that the executable expects to link against. The README states the consequence plainly: no emulation, no separate runtime process. The game's code runs as native code on your machine, calling into reimplemented system libraries the way it would have called into Sony's.

That is a much harder promise to make good on, and a much better one if you can. Emulation taxes every instruction. Relinking taxes only the boundary — the calls that cross from the game into the system layer.

The part that decides whether it works: shaders

Games are mostly shaders wearing a game-shaped hat. A PS5 title ships GPU programs compiled for a specific graphics stack; a Windows or Linux machine wants something its driver can consume. AnyPS5 includes a shader recompiler that emits SPIR-V, and the repository notes that the output is validated with SPIRV-Tools when the build enables ANYPS5_ENABLE_SPIRV_TOOLS.

Validating SPIR-V is not the same as running a game. It means the generated module is structurally legal, which is the difference between "this might work" and "this will be rejected by the driver in a way that is very hard to debug." Anyone who has spent an evening staring at a black screen will recognise the value of that check.

The project's own progress page is careful about what its numbers mean. Library coverage is measured as the share of functions the project has declared so far, not the share of every function a PS5 exposes. That is an honest framing, and it also means the percentage will move as the project learns how much it does not know.

How it fails, on purpose

One design decision tells you a lot about the maturity of the codebase. Unsupported or unexpected states throw std::runtime_error; the message goes to stderr and the process terminates.

That sounds brutal, and it is the right call. The alternative — guess, continue, corrupt state — produces crashes three frames later in a place that has nothing to do with the actual bug. A project at this stage needs loud, early, specific failures. There is a commit from mid-October that fixes a Windows test hang caused by exactly this kind of ordering problem: on Windows, a test returning from main runs through exit, which kills every other thread before static destructors run at DLL detach, and a destructor that then waits on a dead logger never returns. The fix wraps main on MinGW and terminates the process through libc instead. That is not glamorous work. It is the work that separates a demo from a tool.

Input, and the small stuff that matters

SDL-mapped controllers work, analog sticks and triggers included. Keyboard and mouse are configured through an anyps5-input.ini file. There is a web converter that processes files locally, so nothing gets uploaded.

Per-game compatibility is not maintained in the README. It lives on a community blocker map built from public GitHub data, with per-title threads in the repository's discussions for test reports. This is worth understanding before you download anything: the project tracks where each title gets stuck, not a green list of games that work.

The legal sentence you should actually read

The disclaimer says the project is for interoperability, research, preservation, and compatibility. It says it does not include, distribute, or require copyrighted software, firmware, cryptographic keys, or proprietary libraries. And it says users are responsible for making sure any binaries they use are obtained and used lawfully.

That is a carefully drawn line, and it is the whole ballgame. The tool itself is GPL-2.0-only and contains no game data. What you feed it is your problem, and in most jurisdictions "I relinked it myself" is not a defence that has been tested in court.

Where the boundary actually sits

A relinker's job is symbol resolution. The executable asks for functions by name; the tool has to make sure every one of those names resolves to something callable at load time, in the right calling convention, on a machine that is not the machine the binary was built for. Miss one and the process dies at startup, usually with a message that names a library and nothing else.

That is why the project's coverage page is the most honest document in the repository. It reports the share of functions the project has declared that are implemented — not the share of a PS5's total API surface. The difference is enormous, and it means the percentage will fall as the team discovers more of what it does not know. Most projects hide that dynamic. This one puts a note next to the number.

The same logic explains the GPU side. Shader translation is not one problem; it is a different problem per shader, and a title that renders correctly for twenty minutes and then hits an untranslated instruction path will crash in a way that looks like a driver bug. The SPIR-V validation step catches structural problems early. It cannot catch semantic ones, and the project does not claim it does.

So the practical question is not "does it work." It is "where does my title stop," and the blocker map answers that per game, with open issues attached.

Why this trended now

Preservation has been having a moment. Disc rot, delisted storefronts, servers switched off — the case for keeping software runnable has stopped being sentimental and become practical. A relinker is a preservation tool in a way an emulator is not: it does not need to model a machine, only to satisfy the interface that the software expects.

There is also a simpler explanation. The project is enormous, commits land by the hundred, and a chunk of them are obviously written with coding agents in the loop — the repository even includes an AGENTS.md file listing the rules agents tend to break. Watching a 10,000-commit project get built in roughly two and a half months is its own kind of spectacle, and it explains a star curve that has little to do with how many games boot.

What to do with it

If you have a legally obtained executable and a spare evening, the honest expectation is: you will learn a great deal about how a modern console title is put together, and you will probably not finish a game. Read the blocker map for your title first. Read the technical debt document before you file an issue. And read the license before you ship anything built with it.

The larger point stands regardless of how many titles ever boot. For twenty years the answer to "can this console software run elsewhere" has been "only if someone emulates the machine." AnyPS5 is a serious attempt at a second answer, and the fact that it is being written in public, at this speed, with this much unglamorous plumbing, is the reason it belongs on the trending page.