New version tagged for Box86 & Box64
New in those releases are a new hack for program that redirect Malloc function on box64. This allows for libcef and other chrome derivative to work now. That allows for the Full Steam client to work (including the BigPicture mode). The Heroic Launcher also works. You can connect to your GoG and/or Epic account and can install and play games, including the Windows one, and using either your system wine or downloading custom version.
The new release also has the usual new library wrapped and always more functions wrapped too.
On the bugfix side, some work has been done around Rounding and conversion for double and float. In particular, the double <-> 80bits long double conversion has been improved. This is used in some cases, especially in 64bits programs, were most math is done using SSE2 (so in 64bits precision), but some programs call long double version of math function, that then do 64bits->80bits to call the function (and box64 does 80bits->64bits to call the regular non-long double function). This fixed rendering issues in Nuclear Blaze for example.
More optimisation also end up in the Dynarec, with more parameters to finetune the performances. Some bench will come later to compare different box64 versions in a another blog entry
Last but not least, both box86 & box64 now have a parameter file. Those file contains the same parameters as the one use in command line, but specific per process name. That allows for great fine tunning of optimisation and workaround for different programs. There is a default file in /etc/box64.box64rc (for box64) and a user version in ~/.box64rc (still for box64, but box86 also has it’s own set of files). The format is simple and similar to simple .ini file, with name of the process between square brakets and the list of parameter after. If a process is in both files, the settings of the home version are the only one taken into account.
More details on https://boilingsteam.com and on github https://github.com/ptitSeb/box86 / https://github.com/ptitSeb/box64
12 replies on “New version Box86 v0.3.0 and Box64 v0.2.2”
Can’t help wondering. With this emulation present could one use it as a compatibility layer to run VirtualBox on a Rasp Pi or other ARM computer, then boot up the same guest operating systems as one has used on x86 (or 64bit x86) hosts? So you be able to run literally anything, albeit perhaps a bit slowly, on Pi hardware that would normally run on x86. Have the very same VM you made for virtualbox on a x86 host in use on an ARM host. Would be a fascinating possibility.
You can already run x86 virtual machines on ARM host using Qemu.
But not at the same speed.
[…] a host system is that it is very simple, and it is a very easy requirement to meet. the most recent launch It was March 10th, with Box86 0.3 and Box64 0.2.2. Essentially being a translation layer, it […]
[…] is that it’s little-endian, which is a fairly simple requirement to fulfill. The latest release was on March tenth, with Box86 0.3 and Box64 0.2.2. As basically a translation layer, it […]
[…] that it’s little-endian, which is a fairly straightforward requirement to satisfy. The latest release was on March tenth, with Box86 0.3 and Box64 0.2.2. As basically a translation layer, it […]
[…] system is that it is little-endian, which is a pretty easy requirement to meet. The most recent release was on March 10th, with Box86 0.3 and Box64 0.2.2. As essentially a translation layer, it does not […]
[…] for a host system is that it is small, which is a very easy requirement to meet. the most recent launch It was March 10th, with Box86 0.3 and Box64 0.2.2. Essentially being a translation layer, it […]
[…] a host system is that it is very simple, and it is a very easy requirement to meet. the most recent launch It was March 10th, with Box86 0.3 and Box64 0.2.2. Essentially being a translation layer, it […]
[…] system is that it is little-endian, which is a pretty easy requirement to meet. The most recent release was on March 10th, with Box86 0.3 and Box64 0.2.2. As essentially a translation layer, it does not […]
excuse me， syscallwrap[] in src/emu/x64syscall.c , why dose the syscall number not match macro definition from x86 system call ?
Because this is for x86_64. x86 and x86_64 have different syscall numbers.