The First Checkpoint: One Native Execution Model

The first four stages of AnyPS5 can look like separate utilities: an ELF relinker, a NID patcher, a guest-module converter, and a runtime directory layout. Taken together, they describe one native execution model. This checkpoint connects those pieces so the reader can judge what has happened when a title converts and loads—and what has not yet been proved about system services, memory, graphics, or playability.

One loader-facing system, not five independent features

Start with ownership. The main executable and the bundled modules remain title-owned code. They contain the game's logic, its engines, and any libraries the title itself ships. AnyPS5 does not replace that code with a generic host implementation simply because it is difficult to load. It adapts the code's file and dependency relationships so the host loader can treat it as part of one process.

NID metadata is the bridge between that title-owned code and native system behavior. A relocation in the title names the symbol identity that the host-facing loader contract expects. A patched PRX publishes the corresponding NID export. The host loader joins the relocation to the native address. That sequence does not make the PRX part of the title; it makes the PRX the provider for a console-facing service that the title expects to call.

The relinker sits between these ownership domains. It understands enough of the main ELF's program and dynamic metadata to rebuild a host-facing representation. It converts title modules into artifacts that can participate in the same loader graph. It does not execute the game while doing so, and it does not decide that a missing semantic implementation is harmless merely because an import name can be written into a table. Its output is a prepared relationship among title code, native libraries, and the host operating system.

classDiagram class TitleExecutable { game logic dynamic imports } class GuestModule { title-owned code guest dependencies } class NIDMetadata { import/export identity relocation records } class NativePRX { system behavior host implementation } class HostLoader { one native process } TitleExecutable --> NIDMetadata : imports GuestModule --> NIDMetadata : imports and exports NativePRX --> NIDMetadata : exports HostLoader --> TitleExecutable : loads HostLoader --> GuestModule : loads HostLoader --> NativePRX : binds

This model also explains why the runtime layout is not an incidental packaging detail. app0/ holds the title's resources and converted guest modules. libs/ holds AnyPS5's native system PRX files. The host loader needs both categories, but it must treat them as different kinds of dependency. If the wrong artifact is put in the wrong location, the failure can occur before a system-library implementation is even involved.

The “native” part of the model is equally specific. The repository says the converted executable runs as a normal Linux or Windows process and calls native system-library implementations rather than running inside a separate emulation process. That does not mean the title is untouched. The executable's dynamic metadata is rebuilt, NID names are patched into libraries, selected machine instructions can be lowered for Intel hosts, and later graphics and memory paths must translate console assumptions. Native describes where the final work runs and which host interfaces perform it; it does not erase the transformations required to reach that state.

A single imported call makes the ownership boundaries easier to follow. The title's code creates or reaches a call site. The executable's relocation says which NID identity must be bound. The relinker has already placed that reference in host-readable dynamic metadata. A patched native PRX publishes the matching export, and the host loader writes or supplies the resolved address according to the target format. When the title finally invokes the address, the code now crosses from title-owned logic into a native implementation.