The open source advantage was evident from the beginning with the Raspberry Pi: Since free software usually runs on many different platforms, almost all Debian packages could be ported to the new system in a very short time. In addition, there was software that exploited the Rasp Pi's special hardware features.

But for proprietary programs, including most Windows applications, the path to the Raspberry Pi is much less assured. Unless the developers want to port their code to the Rasp Pi, users are out in the cold – unless they know about ExaGear.

ExaGear is a tool that provides a special translation layer that converts x86 commands to ARM equivalents. You can use ExaGear to run software written for x86 systems on the ARM-based Raspberry Pi. Support for the Wine integration layer means you can even run old Windows programs directly on the Rasp Pi.

Installation

For a proprietary program, the download and installation is extremely easy [1]: ExaGear can be found in the Raspbian package sources. You can thus install it conveniently via the package manager and then start the emulator (Listing 1).

$ sudo apt update
$ sudo apt install exagear-desktop
$ exagear
Starting /bin/bash in the guest image /opt/exagear/images/debian-8

The last command in Listing 1 switches to the x86 environment. The first time you call it, a form appears, prompting you for your name and email address (Figure 1). The trial version can then be used in full for 72 hours. The license is tied to the CPU's serial number, which prevents users from simply reinstalling.

Figure 1: As a trial version, ExaGear can be used in full for three days without a paid license.

With a full license, the procedure is somewhat different (see the "Versions" box). Download a tarball specific to the Rasp Pi model used and unpack it in the same directory as the license file. Then start the installation command (Listing 2). (Eltechs kindly provided us with a license for this article.)

exagear-desktop-v-2-2/exagear-desktop-rpi3.tar.gz
$ tar -xvzpf exagear-desktop-v-2-2/exagear-desktop-rpi3.tar.gz
$ sudo ./install-exagear.sh

The tarball essentially contains a number of deb packages with guest systems, from which the installation script then selects the most suitable alternative for the installation. It also checks the license and activates the program.

First Steps

After starting the ExaGear environment with the command exagear, nothing happens except a welcome message. The output of the commands uname -a and cat /etc/os-release (Figure 2) show that the system now runs – with identical kernel versions – under an x86 architecture instead of an armv7l architecture. With the command exit, you leave the x86 environment again.

Figure 2: The system will identify itself as an x86 environment after you start ExaGear.

Later on, you can avoid the detour via the exagear command for installed x86 programs, because the kernel identifies the binary format and launches the wrapper automatically. Of course, this is not automatically the case, but needs to be configured using the ExaGear installer.

Installing ExaGear puts a minimal Debian "Jessie" distribution on your system. Unlike real emulators or virtual machines, the x86 environment makes use of the host system environment – ExaGear is thus explicitly unsuitable for clean program isolation.

The Jessie filesystem is located below /opt/exagear/images/debian-8/. From the normal Raspbian system, you can access the data stored there without any problems. Conversely, you can access the home directories of the host system: ExaGear integrates both /home/ and /dev/.

If you need access to the complete host system, simply remount the original root partition completely (Listing 3). After that, the guest system sees the complete host filesystem below /host – whether or not this makes sense is up to you to decide.

$ sudo mkdir /opt/exagear/images/debian-8/host
$ sudo mount /dev/mmcblk0p2 /opt/exagear/images/debian-8/wirt

The dpkg -l command shows the few installed packages of the frugal ExaGear Debian. However, the retroactive installation of further software works without problems and – in the usual Raspbian style – relies on the command:

sudo apt-get install <package>

The guest system also relies on the host for services and udev rules. It would thus be pointless to reinstall services like cron inside the emulator. It only makes sense that the software prevents this.

Architecture

ExaGear Desktop is not a classic emulator that provides a complete operating system environment – in particular, it lacks its own kernel. In principle, the software works in a similar way to Wine, which provides a Windows environment under Linux. The run-time environment intercepts x86 commands and translates them into corresponding ARM commands. For graphics output, ExaGear uses the host's X server; the Linux desktop's architecture helps the emulator here (see the "X Architecture on Linux" box).

The advantage of the lean emulation layer is that it automatically supports multithreading; however, you still experience a loss of performance. Eltechs promises up to 80 percent of native performance, with the loss depending on the specific commands an application uses. In extreme cases, up to two-thirds of the Rasp Pi performance is lost.

On the Raspbian side, you should definitely take some precautions to ensure optimal conditions. This includes at least a newer generation RPi2 (the same processor as the RPi3) or higher. A fast hard disk (SSD) for the system also helps. You should also give the GPU enough memory, at least 256MB, which you can set with the parameter gpu_mem in the /boot/config.txt file.

Graphic-intensive applications also benefit from enabling hardware-supported graphics acceleration. You can do this in raspi-config, where you will find the setting GL Driver below Advanced Options. Select GL (Full KMS) OpenGL desktop driver with full KMS. Applications such as Skype (32-bit Linux version) have a problem with this. When Skype accesses the video camera, whether it's a Pi or USB camera, the X server crashes.

On the network side, emulation is less of a performance brake. Cloning a 260MB GitHub project took 140 seconds natively and 231 seconds in the emulator. The download rate in the emulator was only seven percent lower, the rest of the loss was attributable to the CPU for encryption and processing the Git metadata. With NFS or Samba transfers, on the other hand, the loss is in the range of measurement uncertainty.