This is a huge milestone, following the last piece of news in Q4 2022 when better compatibility was achieved. PtitSeb, the developer behind Box86 and Box64, has just managed to fix the issues that previously prevented Box64/Box86 to support the Full Steam client - while it was still possible to use the mini mode. Most of the issues were related to the embedded Chromium browsing engine within Steam that is used to display dynamic content using HTML/CSS styling.

First, let me show you the proof in video, courtesy of PtitSeb:

The same video is available on Peertube.

The demonstration was done on the Phytium D2000 Mini-computer (ARM-based) manufactured in China.

Just how PtitSeb managed to find a fix, is explained below by PtitSeb himself:

PtitSeb: Main issue with all chrome based programs with box64 is that malloc/free are redirected. Google uses its own malloc operator to make all libs use the same heap. This cannot work with box64 because when it loads the emulated program and all the dependent libraries - and many objects are already allocated with the current malloc function before the new one can be active. So box64 now overrides the malloc operator, and doesn’t allow Chromium (or any other program) to set a custom malloc/free operator. But in the case of Chromium, this is not enough, because even with the malloc operator redirected, some memory was still allocated with the new malloc (some function calls are probably inline within the compiler, for speed of execution, and so does not call “malloc” but just executes its code directly), and were then “free” or “realloc” using regular function. And this doesn’t work. So I have a hack in place to detect if a pointer given to free or realloc is a pointer allocated with the new malloc function, and act accordingly. It is still very hacky for now, and I need to improve its behavior, but the core principle will stay like this. And that allows Chrome / libcef to actually load and run.

The Full Steam client brings a lot more options to manage the games in your library, as well as interacting with the community… and purchasing games, too! This provides a path for a powerful ARM-based device (think something like the M1/M2 class of chips for the new Macs) to be able to run Steam games in the future.

Will that be sufficient to provide a replacement for the Steam Deck or its derivatives, and make away with the hard dependency on X86 architecture?