AnyPS5 Workbench: direct launch, source runtimes and the two conversion alternatives
ItsOOGWAY · PC guides & recorded tests
AnyPS5 Workbench: direct launch, source runtimes and the two conversion alternatives
Run supported PS5 game builds on Windows with AnyPS5 Workbench. This step-by-step guide shows direct launch with libraries or source, Prince of Persia, Minecraft and Silksong gameplay, plus separate browser and BAT conversion methods.
The key checkpoint: Clear Source when testing downloaded libraries. Direct launch, browser conversion and the local relinker are different routes with different outputs and failure modes.
Before you start
- Use the recorded versions and the supported inputs listed in the original notes below.
- Compare the last successful checkpoint before choosing a fix.
- Keep original files, relevant logs and a known working setup when testing changes.
Resources from this video
Links, downloads & documentation
Every original URL from the video description is collected here, including recorded releases, setup discussions and related videos. Use the version-specific notes when following a recorded build.
Watch the complete video
Open this video on YouTube ↗. Screenshots below link to their exact recorded moments.
Walkthrough 01
Prepare the app, game and writable workspace
You need your own extracted, decrypted game files. These tools do not include games, and the ELF extractor cannot decrypt an encrypted executable. Keep the complete game folder, including its assets and bundled modules. Selecting only the main executable does not replace those files. There are four downloads in the tool package: Workbench, the custom libraries, the Port Game BAT tool, and the standalone ELF Creator. You do not need to run all four. Workbench is the main route we will use first.
The other tools are alternatives for specific tasks. Extract the entire Workbench ZIP into a normal writable folder. Open Any PS Five Workbench, and keep the other files that came with it beside the launcher. Do not pull the executable out on its own.
Walkthrough 02
Select the game and runtime libraries
The library screen has three things to set: your game folder, the runtime you want to use, and a workspace for the files Workbench prepares. Click Add game folder. Select the extracted folder for one game. You can also scan a collection folder, but starting with one title makes it easier to check that you selected the right files. The game should appear in the list. Select it and check its title, game ID, and folder path.
A title appearing here means Workbench found it. It does not mean that game is confirmed playable. Next, choose the workspace. This is where prepared ELF files, saves, and session logs are stored. Use a writable folder outside the original game folder, preferably on an NTFS drive with free space. Keep that workspace if you want to keep the saves from these runs. Now choose the runtime. This is the part that matters most. The quickest setup uses already compiled Windows libraries.
Click Locate libs and select the actual libs folder. Select the folder containing the libraries, rather than a ZIP or the parent folder around it. Keep the supplied PRX files and companion DLLs together as one matching set.
Walkthrough 03
Clear Source to test local libraries
Here is the setting I mentioned earlier. If the Source field contains a source ZIP, a source folder, or the latest-source selection, that source takes priority over the libs folder. So, to test your downloaded libraries, clear the Source field first. Then check that the libs path is correct. Otherwise, you can change the libraries and still end up launching with a source-built runtime. In my first direct demonstration, I selected the local library set and launched Prince of Persia.
Workbench prepared the game, opened its window, and I reached gameplay. The initial preparation and loading took several minutes in this recording. I am shortening that wait here, but showing the result at normal speed. Do not expect every first launch to be instant. This is the result from that library set on this machine. It demonstrates the route working; it is not a full-game stability test. Minecraft also reached a world through direct launch.
You can see movement and interaction here, rather than just a running process or a title screen. Again, that is a demonstration of this particular game build and runtime, not a promise that every version behaves the same way. What is Workbench actually doing when we press Run directly? It prepares a clean ELF from a supported decrypted container when necessary, finds the game's modules, and loads the game code through Direct Host. The selected Windows libraries provide the system functions that code needs.
It does not create a separate Windows game EXE in this mode. There is still preparation, and there are still runtime files, caches, and a workspace. The practical benefit is that we can manage the games from one library and try a different runtime without creating another complete converted game folder each time. You also have a Check direct loader button. That checks loading, imports, and relocations without starting the game's entry point. It is useful for finding a preparation problem, but a passed check is not a gameplay test.
To actually launch, select the game and click Run directly. Watch the status messages while it prepares the files. When the game window opens, give it focus before using the controller or keyboard. If startup fails, keep the messages from that session rather than guessing which file to copy next.
Walkthrough 04
Switch to a source-built runtime
Now let us use source instead of a downloaded library set. This is useful when you want to try changes that have not reached a packaged Windows release yet. In the Source row, choose Source ZIP and select your official Any PS Five source archive. If you already extracted the source, use Source folder instead. Workbench builds the matching runtime libraries from that snapshot and uses them for the direct launch. You do not need to write the compiler commands yourself.
Workbench handles the build process and downloads the build tools and dependencies it needs. But the first build can take time and considerable disk space, so keep an internet connection and allow it to finish. Source code is not being interpreted live while you play. It is compiled into Windows runtime libraries first. An unchanged build can then be reused, which avoids rebuilding everything on every launch. In this recording, I select the source ZIP, add Silksong, and press Run directly.
The status shows the prepared runtime being reused. That means the runtime was already available from an earlier build; this is not a demonstration of the entire first build finishing in a few seconds. The game then opens, reaches its opening sequence, and enters gameplay. Hornet is controllable here. This is the source-based direct-launch result from my recording. There is also a Latest source button. That route checks the official source revision when launching and builds a new runtime when needed.
Use a fixed source ZIP when you want a repeatable snapshot. Use Latest source when you deliberately want to test newer upstream changes. A newer source revision can change compatibility, but newer does not automatically mean better for every game. The direct loader also has its own compatibility limits. A supported converted game is not automatically guaranteed to behave identically through this experimental loader. That is why keeping a known working runtime is useful. In this session, Prince of Persia reached gameplay with the selected custom libraries, while a later run using the source snapshot exited during startup.
Hollow Knight also failed with that source snapshot. Those are the results I observed here, rather than proof that either game can never work with official source. The separate development tests helped us assemble a matching library set and fix a trophy-library failure for Hollow Knight. That history is useful, but do not take one working set as a universal fix for every title. If you want to try the custom library package, extract it separately, clear Source, and select its libs folder.
Keep your previous working set available so you can switch back. Avoid combining random individual modules from unrelated builds; the surrounding libraries and their DLL dependencies need to be compatible too.
Walkthrough 05
Understand the browser ELF check
Now that the main Workbench route is clear, here are the two conversion alternatives and the errors they address. The first is the official browser converter, linked from the Any PS Five project. The page says conversion happens locally and your files stay on your device. Choose your game folder, or a supported ZIP, and select Windows as the output. In my first attempt, the page rejects eboot.bin because it is a SELF container rather than the clean ELF it expects.
That message does not necessarily mean the game is unsupported. It means the converter has not accepted the executable format yet. Renaming the file to dot ELF will not change the format. For a supported, already decrypted container, use the standalone ELF Creator. Extract its complete ZIP and open Create ELF. Select the game's eboot.bin, then choose where to save the extracted ELF. Leave the original executable in place. Wait for the completion message and check that the new ELF file exists.
This tool prepares the executable; it does not create a Windows game EXE, and it does not make an unsupported game compatible. Select the game folder again in the browser converter. In the Silksong example, it now recognizes the input and enables the conversion controls. Review the detected game, confirm the acknowledgement, and choose the Windows output and save location. If conversion succeeds, extract the complete result before launching it.
Walkthrough 06
Move size-limited conversion to the local relinker
There is a second, different browser error in my recording: the executable and modules exceed the two hundred and fifty-six mebibyte conversion limit. That limit is about the conversion input, not the total size of every game asset. The page also has a separate memory budget for saving downloads, so changing the save method is not a fix for every size error. For the executable-and-module limit shown here, the page directs us to the native relinker.
That is where the Port Game BAT tool helps. It automates the local relinker workflow without making you type the commands yourself. Extract the tool and keep its BAT, PowerShell script, and support files together. If you are supplying your own release, place the tool beside the matching relinker executable and libs folder. Otherwise, the tool can download its default release dependencies. It is not automatically using the newest source just because it is running locally.
Open Port Game. Select eboot.bin or a clean ELF, then choose an output location outside the original game folder. Read the confirmation: it shows the game resources, relinker, libraries, and destination it plans to use. This conversion route copies the game resources, so allow space for another copy. Confirm the correct paths, then let the scan and conversion finish. It also prepares the supported bundled modules rather than expecting you to move them manually afterward.
When conversion completes successfully, open the generated output folder and run Game dot EXE. Keep the executable with its app zero folder and libraries. Moving only the EXE breaks the layout it needs. In my converted Silksong test, the game reaches the title menu. The later Workbench demonstration goes further into gameplay. I am keeping those results separate because successful conversion and full playability are different things. Workbench also includes the extra tools. Extract ELF lets you select an executable and save a clean ELF independently.
Source build and conversion tools opens the separate conversion interface. Use that when you specifically want Windows executable output; use Run directly for the library-and-loader workflow we followed earlier. If something fails, open workspace and logs and keep the session that matches the failed attempt. Note the game ID and version, whether you selected libs or source, the runtime revision if available, and what happened on screen. A clear report is much more useful than saying the game does not work.
So your choice is straightforward. Use Workbench for the game library and experimental direct launch. Use compiled libraries for a quicker runtime setup, or source when you want to build and test a particular revision. Use the browser converter for supported inputs, and the BAT workflow when you want local Windows conversion without typing the relinker commands. The links to the project and the separate tool packages will be in the description. I am also building a Discord community where we can compare results and help each other troubleshoot.
Share the exact game and runtime you tested, and whether you reached a menu or actual gameplay.
If your result differs
| Situation | Next useful check |
|---|---|
| The process stops at a different checkpoint | Record the exact message, current build and last successful stage. Compare that stage with the matching video section. |
| A setting is selected but the result differs | Repeat the same scene and change one option at a time. A menu target does not establish measured performance. |
| A newer release changes the interface | Check the linked release notes and instructions. This companion preserves the recorded route and its limitations. |
Comments
Post a Comment