AnyPS5: PS5-Executables neu linken statt sie zu emulieren

Es gibt eine Kategorie von Projekten, die auf GitHub aus Gründen trenden, die niemand aufschreibt. AnyPS5 ist so eines. Es steht mit rund 16,000 neuen Sternen an der Spitze der Wochencharts, kommt auf fast 10,000 Commits, und seine Ein-Satz-Beschreibung — „Tool zum automatischen Portieren von PS5-Executables nach Linux und Windows“ — ist genau die Sorte Satz, bei der Juristen zum Stift und Entwickler zum Lesezeichen greifen.

Interessant ist nicht, dass es das Projekt gibt. Interessant ist, was es nicht sein will.

Kein Emulator, keine Runtime, keine Konsole im Fenster

Die meisten Projekte, die Konsolensoftware auf dem PC ausführen, sind Emulatoren. Sie modellieren die Hardware: die CPU, die GPU, das Speicherlayout, das Timing. Dieser Ansatz ist ein Wunder, wenn er funktioniert, und ein jahrzehntelanger Kraftakt, wenn nicht — denn jedes Spiel wird zur Verhandlung mit dem unvollständigen Modell einer Maschine, für die niemand vollständige Dokumentation besitzt.

AnyPS5 geht einen anderen Weg. Es liefert einen relinker, der ein PS5-Executable in das native Format der Zielplattform umwandelt, dazu Implementierungen der Systembibliotheken prx, gegen die das Executable zu linken erwartet. Das README benennt die Konsequenz unverblümt: keine Emulation, kein separater Runtime-Prozess. Der Spielcode läuft als nativer Code auf der eigenen Maschine und ruft nachimplementierte Systembibliotheken auf, so wie er Sonys Bibliotheken aufgerufen hätte.

Das ist ein deutlich schwerer einzulösendes Versprechen — und ein deutlich besseres, wenn es gelingt. Emulation besteuert jeden Befehl. Relinking besteuert nur die Grenze: die Aufrufe, die vom Spiel in die Systemschicht hinüberwechseln.

Der Teil, der über Erfolg entscheidet: Shader

Spiele sind im Kern Shader, die einen Spielanzug tragen. Ein PS5-Titel bringt GPU-Programme mit, die für einen bestimmten Grafik-Stack kompiliert wurden; eine Windows- oder Linux-Maschine will etwas, das ihr Treiber verdauen kann. AnyPS5 enthält einen Shader-Recompiler, der SPIR-V ausgibt, und das Repository vermerkt, dass die Ausgabe mit SPIRV-Tools validiert wird, wenn der Build ANYPS5_ENABLE_SPIRV_TOOLS aktiviert.

SPIR-V zu validieren ist nicht dasselbe, wie ein Spiel zum Laufen zu bringen. Es heißt, dass das erzeugte Modul strukturell zulässig ist — und das ist der Unterschied zwischen „das könnte funktionieren“ und „der Treiber lehnt das auf eine Art ab, die sich extrem schwer debuggen lässt“. Wer schon einmal einen Abend vor einem schwarzen Bildschirm verbracht hat, kennt den Wert dieser Prüfung.

Die Fortschrittsseite des Projekts ist vorsichtig damit, was ihre Zahlen bedeuten. Die Bibliotheksabdeckung misst den Anteil der Funktionen, die das Projekt bisher deklariert hat, nicht den Anteil aller Funktionen, die eine PS5 bereitstellt. Das ist eine ehrliche Einordnung — und heißt zugleich, dass sich der Prozentwert bewegen wird, je mehr das Team darüber lernt, was es nicht weiß.

Wie es scheitert, und zwar mit Absicht

Eine Designentscheidung verrät viel über die Reife einer Codebasis. Nicht unterstützte oder unerwartete Zustände werfen eine std::runtime_error; die Meldung geht auf stderr, der Prozess endet.

Das klingt brutal, ist aber die richtige Entscheidung. Die Alternative — raten, weitermachen, Zustand beschädigen — erzeugt einen Absturz drei Frames später, an einer Stelle, die mit dem eigentlichen Fehler nichts zu tun hat. Ein Projekt in dieser Phase braucht laute, frühe, präzise Fehlschläge. Ein Commit von Mitte Oktober behebt genau so ein Ordnungsproblem, das unter Windows einen Test hat hängen lassen: Unter Windows läuft ein Test, der aus main zurückkehrt, durch exit, und exit beendet alle anderen Threads, bevor beim DLL-Detach die statischen Destruktoren laufen. Ein Destruktor, der dann auf einen toten Logger wartet, kehrt nie zurück. Der Fix packt main unter MinGW in einen Wrapper und beendet den Prozess stattdessen über die libc. Das ist keine glamouröse Arbeit. Es ist die Arbeit, die eine Demo von einem Werkzeug trennt.

Eingaben und der Kleinkram, auf den es ankommt

Über SDL gemappte Controller funktionieren, analoge Sticks und Trigger inklusive. Tastatur und Maus werden über eine Datei anyps5-input.ini konfiguriert. Es gibt einen Web-Konverter, der Dateien lokal verarbeitet — hochgeladen wird nichts.

Die Kompatibilität pro Spiel wird nicht im README gepflegt. Sie lebt auf einer Community-Blocker-Map, die aus öffentlichen GitHub-Daten gebaut ist, mit Threads pro Titel in den Discussions des Repositories für Testberichte. Das sollte man verstehen, bevor man irgendetwas herunterlädt: Das Projekt verfolgt, wo jeder Titel hängen bleibt, nicht eine grüne Liste spielbarer Spiele.

Der juristische Satz, den man wirklich lesen sollte

Der Disclaimer besagt, dass das Projekt Interoperabilität, Forschung, Erhaltung und Kompatibilität dient. Er besagt, dass es urheberrechtlich geschützte Software, Firmware, kryptografische Schlüssel oder proprietäre Bibliotheken weder enthält noch verbreitet noch voraussetzt. Und er besagt, dass Nutzer dafür verantwortlich sind, sicherzustellen, dass alle verwendeten Binaries rechtmäßig beschafft und rechtmäßig verwendet werden.

Das ist eine sorgfältig gezogene Linie, und sie ist das ganze Spiel. Das Werkzeug selbst steht unter GPL-2.0-only und enthält keine Spieldaten. Was man ihm füttert, ist das eigene Problem — und in den meisten Rechtsordnungen ist „ich habe es selbst neu gelinkt“ keine Verteidigung, die vor Gericht erprobt wäre.

Wo die Grenze tatsächlich verläuft

Die Aufgabe eines Relinkers ist Symbolauflösung. Das Executable fragt Funktionen über ihren Namen an; das Werkzeug muss sicherstellen, dass sich jeder dieser Namen beim Laden in etwas Aufrufbares auflöst, mit der richtigen Aufrufkonvention, auf einer Maschine, die nicht die ist, für die das Binary gebaut wurde. Fehlt einer, stirbt der Prozess beim Start — meist mit einer Meldung, die eine Bibliothek nennt und sonst nichts.

Deshalb ist die Abdeckungsseite des Projekts das ehrlichste Dokument im Repository. Sie meldet den Anteil der deklarierten Funktionen, die implementiert sind — nicht den Anteil an der gesamten API-Oberfläche einer PS5. Der Unterschied ist gewaltig, und er bedeutet, dass der Prozentwert sinken wird, je mehr das Team entdeckt, was es noch nicht weiß. Die meisten Projekte verstecken diese Dynamik. Dieses setzt eine Fußnote neben die Zahl.

Dieselbe Logik erklärt die GPU-Seite. Shader-Übersetzung ist kein einzelnes Problem; sie ist ein anderes Problem pro Shader, und ein Titel, der zwanzig Minuten korrekt rendert und dann auf einen unübersetzten Befehlspfad trifft, stürzt so ab, dass es wie ein Treiberfehler aussieht. Die SPIR-V-Validierung fängt strukturelle Probleme früh ab. Semantische kann sie nicht fangen, und das Projekt behauptet das auch nicht.

Die praktische Frage lautet also nicht „läuft es“, sondern „wo bleibt mein Titel stehen“ — und die Blocker-Map beantwortet das pro Spiel, mit verlinkten offenen Issues.

Warum es gerade jetzt trendet

Erhaltung hat gerade Konjunktur. Disc Rot, aus den Stores entfernte Titel, abgeschaltete Server — das Argument, Software lauffähig zu halten, ist nicht mehr sentimental, sondern praktisch. Ein Relinker ist ein Erhaltungswerkzeug auf eine Weise, wie es ein Emulator nicht ist: Er muss keine Maschine modellieren, sondern nur die Schnittstelle erfüllen, die die Software erwartet.

Es gibt auch eine einfachere Erklärung. Das Projekt ist riesig, Commits landen zu Hunderten, und ein guter Teil davon ist erkennbar mit Coding-Agenten im Loop geschrieben — das Repository enthält sogar eine Datei AGENTS.md mit den Regeln, die Agenten gern brechen. Einem Projekt mit 10,000 Commits beim Wachsen zuzusehen, in etwa zweieinhalb Monaten, ist für sich genommen ein Spektakel — und erklärt eine Sternkurve, die wenig damit zu tun hat, wie viele Spiele tatsächlich booten.

Was man damit anfangen kann

Wer ein legal beschafftes Executable und einen freien Abend hat, sollte Folgendes erwarten: Man lernt eine Menge darüber, wie ein moderner Konsolentitel zusammengesetzt ist, und man wird ein Spiel wahrscheinlich nicht durchspielen. Lies zuerst die Blocker-Map für deinen Titel. Lies das Dokument zur technischen Schuld, bevor du ein Issue aufmachst. Und lies die Lizenz, bevor du irgendetwas veröffentlichst, das damit gebaut wurde.

Der größere Punkt bleibt bestehen, egal wie viele Titel je booten. Zwanzig Jahre lang lautete die Antwort auf „kann diese Konsolensoftware woanders laufen“ stets „nur wenn jemand die Maschine emuliert“. AnyPS5 ist ein ernsthafter Versuch einer zweiten Antwort — und dass er öffentlich geschrieben wird, in diesem Tempo, mit so viel unglamouröser Klempnerarbeit, ist der Grund, warum er auf die Trending-Seite gehört.