I think the ease of use and how simple both box86 and box64 are to install is often forgotten. So let me detail a bit what is needed to have either box running:
For box86, you need the box86
binary, and a 32bits subsystem.
For box64, you need the box64
binary, and a 64bits subsystem.
And that it. Everything else is “quality of life” addons.
The installation to the system, using systemd-binfmt
integration, allows box86/box64 to be used automatically by the system when an i386/x86_64 binary is launched. But that’s not mandatory.
If it is not installed (or if systemd-binfmt
is not available), box can still be used. For example, once built (that part is covered in the COMPILE.md
doc from each repo) on the Pandora (no systemd there), world of goo can be launched using
box86 ./WorldOfGoo.bin32
The other things that come with both box and are installed are a small set of libraries. There is libstdc++
and its companion libgcc_s
. There is also libpng12
now. That last one is here because quite a lot of games are still using it, while it’s deprecated and removed from modern OS version. It’s here so games can still be run.
For the C++ library, well, box86 and box64 don’t wrap C++ library (for technical reasons). So those libs need to be the i386/x86_64 version to run C++ software (so, a lot of softwares!). Those libs are copied in a fixed path on the system so box can find and use them. But again, it’s not mandatory. C++ games can still be launched if the libraries are copied somewhere box can find them, like in the game folder itself.
For all libraries used by a game or software, box will try to load the native version if that libs is wrapped (32bits for box86 or 64bits for box64). If the lib is not loaded (not wrapped or not found), box will try to load an emulated version of that lib (in the current folder, a few subfolders, or in a folder indicated by either LD_LIBRARY_PATH or BOXxx_LD_LIBRARY_PATH environment variable). If the lib is still not loaded, an error will occur…
To use Windows software, you will need an i386 or x86_64 version of wine. It is easier to use pre-built binary. You can find some in the PlayOnLinux build machine, or in the TwisterOS FAQ page for example. Once you have a tgz of the binary, simply extract it in your home folder (so ~/wine
), then create a few shortcuts to launch it withsudo ln -s ~/wine/bin/wine /usr/local/bin/wine
sudo ln -s ~/wine/bin/wineserver
/usr/local/bin/wineserver
sudo ln -s ~/wine/bine/wineboot
/usr/local/bin/wineboot
If you grabbed an 64bits built, you also have to addsudo ln -s ~/wine/bin/wine64 /usr/local/bin/wine64
You can also install winetricks
, just follow the procedure on its GitHub page, and it should just work out-of-the-box with the latest versions of box86 and box64.
Now, just launch your Windows games with wine
, as if you were on an x86 pc…
Because the wrapping is an integral part of box, there is no specific file or configuration to define what/how libs are wrapped. And there is more than a hundred libs that are actually wrapped. That means that, in most cases, when a lib is missing, you just need to install the native one for your system.
When using box86 on an Aarch64 OS, it can be a bit tricky. For the Debian family, you can use multiarch, for a seamless system integration. Start withsudo dpkg --add-architecture armhf
sudo apt update
to add the architecture. Then, to kickstart your library collection, you can usesudo apt install libgtk2.0-0:armhf libsdl2-image-2.0-0:armhf
To install gtk2 (which also installs many X11 libs) and some SDL2 libs for armhf. That should allow a good set of 32bits program to start.
To conclude, I’ll show here the list of library wrapped by box86 and box64.
crashhandler.so => empty wrapping
d3dadapter9.so.1 => box86 only (that's gallium9)
ld-linux-x86-64.so.2 / ld-linux.so.2
libalure.so.1
libalut.so.0
libopenal.so.1 / libopenal.so.0 / libopenal.so / openal.so
libasound.so.2
libbz2.so.1
libc.so.6
libcairo.so.2
libcups.so.2
libcurl.so.3
libcurl.so.4
libcurl-gnutls.so.4
libcrypto.so.1 => emulated is prefered
libdbus-1.so.3
libcrypt.so.1
libdl.so.2
libdrm.so.2
libect-2.0.so.0
libexpat.so.1 / libexpat.so
libFAudio.so.0 => box64 only
libFLAC.so.8
libfontconfig.so.1
libform.so.5
libformw.so.5
libfreetype.so.6
libGL.so.1 / libGL.so / libOpenGL.so.0
libGLU.so.1
libgmp.so.10 => box64 only
libgnutls.so.30
libgssapi.so.3 => box64 only
libgssapi_krb5.so.2
libICE.so.6
libiconv.so.2 => box86 only
libjpeg.so.8 => box86 only
libjpeg.so.62 => box86 only
libkrb5.so.3
libldap_r-2.4.so.2
liblber-2.4.so.2
liblzma.so.5
libm.so.6
libmpg123.so.0
libncurses.so.5
libncurses.so.6
libncursesw.so.5
libncursesw.so.6
libnsl.so.1
libnspr4.so
libnss3.so
libnssutil3.so
libogg.so.0
libpanel.so.5
libpangoft2-1.0.so / libpangoft2-1.0.so.0
libpci.so.3 => box64 only
libpcre.so.3
libplc4.so
libplds4.so
libpng12.so.0 => box86 only
libpng16.so.16
libpulse-simple.so.0 => can be disable with BOXxx_NOPULSE=1
libpulse.so.0 => can be disable with BOXxx_NOPULSE=1
libpthread.so.0
libresolv.so.2
librt.so.1
libSDL-1.2.so.0
libSDL_image-1.2.so.0
libSDL_mixer-1.2.so.0
libSDL_net-1.2.so.0
libSDL_sound-1.0.so.1
libSDL_ttf-2.0.so.0
libSDL2-2.0.so.0 / libSDL2-2.0.so.1 / libSDL2.so / libsdl2-2.0.so.0
libSDL2_image-2.0.so.0 / libSDL2_image.so
libSDL2_mixer-2.0.so.0
libSDL2_net-2.0.so.0
libSDL2_ttf-2.0.so.0 / libSDL2_ttf.so
libselinux.so.1 => box64 only
libsecret-1.so.0
libSM.so.6
libsmime3.so
libsmpeg-0.4.so.0
libsmpeg2-2.0.so.0
libsndfile.so.1
libssl.so.1 => emulated is prefered
libssl3.so
libtcmalloc_minimal.so.4 => empty wrapping
libtinfo.so.5
libtinfo.so.6
libturbojpeg.so.0 => box86 only
libudev.so.0
libudev.so.1
libusb-1.0 => box86 only
libutil.so.1
libuuid.so.1
libv4l2.so.0 => box86 only
libvorbis.so.0
libvorbisfile.so.3
libvulkan.so.1 / libvulkan.so
libwayland-client.so => box86 only
libX11.so.6
libX11-xcb.so.1
libXau.so.6
libxcb.so.1
libxcb-dri2.so.0
libxcb-dri3.so.0
libxcb-glx.so.0
libxcb-image.so.0
libxcb-keysyms.so.1
libxcb-present.so => box86 only
libxcb-randr.so.0
libxcb-shape.so.0
libxcb-shm.so.0
libxcb-xtest.so.0
libxcb-xfixes.so.0
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXdmcp.so.6
libXext.so.6
libXfixes.so.3
libXft.so.2
libXi.so.6
libXinerama.so.1
libxkbcommon.so.0
libxkbcommon-x11.so.0
libxml2.so.2
libXmu.so.6
libXpm.so.4
libXrandr.so.2
libXrender.so.1
libxslt.so.1
libXss.so.1
libXt.so.6
libXtst.so.6
libXxf86vm.so.1
libz.so.1
//Those are GTK one and can be disabled with BOXxx_NOGTK=1
libappindicator.so.1 => box86 only
libatk-1.0.so.0
libatk-bridge-2.0.so.0
libatspi.so.0 => box64 only
libdbus-glib-1.so.2
libdbusmenu-glib.so => box86 only
libdbusmenu-gtk.so => box86 only
libgconf-2.so.4
libgdk-3.so => box86 only
libgdk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
libgio-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgstapp-1.0.so.0
libgstaudio-1.0.so.0
libgstbase-1.0.so.0
libgstinterfaces-0.10 => box86 only
libgstreamer-0.10 => box86 only
libgstreamer-1.0.so.0
libgsttag-1.0.so.0
libgstvideo-1.0.so.0
libgthread-2.0.so.0
libgtk-3.so => box86 only
libgtk-x11-2.0.so.0
libgudev-1.0 => box86 only
liblcms2.so.2 => box86 only
libnm.so.0 => box86 only
libnm-glib.so => box86 only
libnm-util.so => box86 only
libpango-1.0.so.0
libpango-cairo-1.0.so.0
19 replies on “Box86/Box64 are easy to use”
Small typo: “64bits sybsystem”
Another small typo (or not exactly a typo): “box86 ./WorldOfGoo.bin32” (the first letter does not have bold font)
Otherwise great blog post and a video. Thanks for your work on this amazing project!
Thank you! I fixed the 2 typos.
Another typo in:
sudo dpkd add-architecture armhf
dpkd -> dpkg
Fixed, thank you!
Actually:
sudo dpkg –add-architecture armhf
Indeed. Thanks for the mention, I have fixed it.
I am completely bewildered on how to ACTIVATE this software while using wine. I got some games working on wine but I am pretty unsure how to change the architecture on t he pi. I’ve seen someone get Unreal tournament 2004 to work on box86 pi4. Problem is I am trying to figure it out and one hurdle is probably not being able to find any information how to activate the box86 software. Hope I find a guide one day or stumble up on the solution. Anyways keep the good work.
What do you mean by activate? If you haad some games already, that means box86 already works and is “activated”. box86 is disagned to be “transparent”, you don’t really see when it’s working, but if you run x86 software, that means it runs.
can you make box86 for android π
It’s not in my short-term plan. But you can use Termux with chroot to run box86. A proot can also be used, but not everything will work, there are many limitation there.
I’ve tried it, but the performance is very slow because it only uses software rendering (LLVMpipe) π₯²
warning: wine cmd.exe /c echo ‘%AppData%’ returned empty string, error message “/usr/local/bin/winetricks: 3248: wine: Exec format error”
I need help π!
I don’t really understand what you are trying to do here. Running winetricks I guess, but I don’t know what is your system, how eveyrhting installed, what wine version this is, if you have box86 and/or box64 and if binfmt system integration is present.
Also, you may want to look at my new blog post about running bash…
Hello installed debian 10 with chroot Linux Deploy . I installed wine and box86 but i cant run 3d program . Can you show tutorial to make 3d program like visual novel to run ?
Isn’t just installing mesa in the chroot enough to get at least LLVMpipe running? It should be enough for RenPy and other VN engine stuff (even with wine)
Hi, I’m trying to follow the steps you mentioned on an arm64 Ubuntu installation (running under virtualization on a MacBook M1), but am running into a problem when issuing the command:
sudo apt install libgtk2.0-0:armhf libsdl2-image-2.0-0:armhf
All of the armhf packages pulled in by this command *appear* to install correctly at first glance, but if you look at the actual “apt” command output, three of the packages show errors while running their post-installation scripts, three during the “Setting up” phase and one also during the “Processing triggers” phase:
…
Setting up libglib2.0-0:armhf (2.72.4-0ubuntu2.2) …
/var/lib/dpkg/info/libglib2.0-0:armhf.postinst: 58: /usr/lib/arm-linux-gnueabihf/glib-2.0/glib-compile-schemas: Exec format error
/var/lib/dpkg/info/libglib2.0-0:armhf.postinst: 59: /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules: Exec format error
…
Setting up libgdk-pixbuf-2.0-0:armhf (2.42.8+dfsg-1ubuntu0.2) …
/var/lib/dpkg/info/libgdk-pixbuf-2.0-0:armhf.postinst: 30: /usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: Exec format error
…
Setting up libgtk2.0-0:armhf (2.24.33-2ubuntu2) …
/var/lib/dpkg/info/libgtk2.0-0:armhf.postinst: 19: /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: Exec format error
…
Processing triggers for libgdk-pixbuf-2.0-0:armhf (2.42.8+dfsg-1ubuntu0.2) …
/var/lib/dpkg/info/libgdk-pixbuf-2.0-0:armhf.postinst: 16: /usr/lib/arm-linux-gnueabihf/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders: Exec format error
…
I’m guessing this is because arm64 Linux – at least the version I’m running – isn’t able to read and run the armhf-format executables that perform the post-installation steps for those three packages. (For most packages this wouldn’t matter, because they don’t have complex post-installation steps like these three do.)
As a workaround, I tried *temporarily* installing qemu-user-static and executing “apt install –reinstall” on the three offending packages, hoping that qemu would perform the arm64-to-armhf translation for the post-installation steps, but it seems I was wrong: I got the same “Exec format error” messages even with qemu-user-static installed.
Do you know if there’s a workaround for this? How important are the post-installation steps for those packages, as far as running box86 is concerned?
The M1/M2 processors don’t handle 32bits arm code. Box86 cannot work there unfortunatly. I have a project called “box32” to workaround this issue but it’s not publised yet and is very early in the developepment phase anyway, so will not be ready for a long time I’m afraid (it’s a complex project, more complex than box86/box64).