As already announced at the end of the last article, in this article I would like to show you some ways of trying to get Windows software to run under Linux. Unfortunately, I have to phrase it this way, as not all Windows software runs on Linux. The reasons for this vary greatly, but at least I feel that things have improved in recent years. Even if software manufacturers do not specifically create their own Linux versions, I have seen on occasion that they are at least making an effort to ensure compatibility with Wine.

In addition to highlighting the general possibilities for running Windows software on Linux, I would also like to demonstrate this using practical examples from Marmoset Toolbag 5 and the Affinity Suite. However, in this article, I will limit myself to “normal” software, so anyone hoping for games will unfortunately have to wait a little longer.

Before we really get started, here is the usual overview of all the articles in this series published so far:

1. Linux? What the penguin!?
2. Basic installation of the Linux distribution
3. Installation of native Linux software
4. Installing Windows software on Linux
5. Gaming on Linux
6. Unreal Engine on Linux
7. Feasible backup solutions under Linux

A first overview

Wine 🍷

The desire to run Windows software on Linux is almost as old as Linux itself. The central project here is Wine 🍷. Wine stands for “WINE is not an emulator”, and the name says it all. Wine does not emulate Windows; instead, it acts more like an interpreter between Windows and Linux. Technically, this works in a simplified way by Wine providing the implementation of the Windows API to the Windows program to be executed. Calls to the Windows API are then converted into “Linux commands” and forwarded to Linux. Since this “interpreting” is usually very efficient, Windows software can in many cases be executed without any noticeable difference in speed compared to “real” Windows.

In general, Wine attempts to provide the Windows API from Windows 3.1 to Windows 11. The older the Windows API, the more completely it is usually implemented by Wine. But since applications never use the complete Windows API, it is often possible to use current programs to their full extent even with the incomplete implementation.

Forks

Since Wine is an open source project, anyone can make changes as long as they comply with the license terms. That’s why you’ll encounter forks in various places from time to time. Let’s take a quick look at the two best-known ones that are still actively being developed.

CrossOver

In this context, we should also mention CrossOver. This is a commercial version of Wine from CodeWeavers. If you are willing to spend the money on CrossOver, you are entitled to support and a certain guarantee that specific software will run. Of course, changes to the Wine source code itself (through the LGPL) is contributed back to the Wine project, and CodeWeavers also employs some of the Wine developers directly, so by purchasing CrossOver, you are also supporting the Wine project to some extent. The big difference between using CrossOver and “pure” Wine is that CrossOver offers a graphical user interface and you don’t have to do everything via the command line. Also, if my memory serves me correctly, there are ready-made installers for some software.

Proton

I would like to briefly mention Proton here, as it is much more than a fork of Wine and is sure to come up again in our article on gaming under Linux. Proton is a Wine-based compatibility layer with a focus on gaming. Behind Proton is none other than Valve, although they also pay some CodeWeavers developers for development. At first glance, the biggest difference between Proton and “pure” Wine is that Proton has DXVK directly integrated. Put simply, DXVK is Wine in the graphics API environment and “translates” Direct3D commands into Vulkan commands.

Frontends

Wine offers a wide range of configuration options, but also requires setting environment variables, executing from the appropriate directories, and a few other things to keep in mind when using it directly from the command line. Fortunately, there are various front ends that attempt to simplify this issue and, ideally, make it possible for even novices to use. As is often the case, I will only discuss a small selection of the available options here. My selection is generally based on popularity and personal preference.

Lutris

Lutris is one such front end. Although its focus is primarily on games, other software can also be installed and configured using it. Lutris is not limited to Wine; for example, ScummVM games can also be configured using it. In addition, various accounts (GOG, Steam, etc.) can be stored, providing direct access to the respective game library.

In addition to the software itself, Lutris also offers the installer database. There you will find a large number of ready-made installer scripts that can be easily used in Lutris. This way, Lutris knows exactly which steps to take to get the desired application up and running. The scripts are created by community members and enable even less tech-savvy people to install the respective software. The scripts are based on YAML and the format is also documented.

Bottles

Bottles is another front end for Wine. In general, it seems much more minimalistic to me than Lutris, which is also due to the fact that it specializes in Wine. The name comes from the fact that Bottles creates “bottles” in which individual configurations and dependencies for different applications can be managed. Technically, this involves different Wine prefixes, a well-known technique that is also used by Lutris, of course. There are also some pre-built setups for applications, but the selection is still significantly smaller than with Lutris. I would say that Bottles is particularly suitable for users who want to use Wine without having to deal with complex manual settings.

WinBoat

WinBoat is still relatively new and therefore only available as a beta version so far. It is based on Dockur, which provides a very slimmed-down version of Windows 11 as a Docker container. Because Windows runs in a Docker container and the application image is accessed using RDP, the overhead is significantly lower than with a “normal” virtual machine and the image is much more pleasant and smoother than with VNC.

Unfortunately, there is currently no option for GPU passthrough, which means that applications launched via WinBoat are currently unable to access the GPU. As a result, some features may not be available, or performance may be worse than expected.

In practice

So, enough of the gray theory and background information. Let’s finally put what we’ve learned so far into practice.

Marmoset Toolbag 5

Before I bought Marmoset Toolbag 5, I already knew that I would be switching to Linux. So before purchasing it, I asked on the official Discord server about its Linux compatibility:

That statement was enough for me, and I was therefore hopeful when I purchased the software. Unfortunately, my initial attempts, which I also wrote about here, all failed. But luckily, I received a message today explaining how to reliably launch Marmoset Toolbag 5 with Lutris.

The installation with Lutris usually runs smoothly. However, before the installation can start, the current installer must first be downloaded from the Marmoset website. Then, click on the “+” in the upper left corner in Lutris and select “Install a Windows game from an executable” to follow the setup steps.

After successful installation, here’s the trick: To ensure that Marmoset Toolbag 5 runs stably with Lutris or Wine, you need to set the version of VKD3D to the older version v2.11.1. To do this, right-click on the corresponding tile in the library to open the configuration settings of the newly installed program. Then navigate to the “Runner Options” tab and change the “VKD3D version” to v2.11.1. Now you can start Marmoset Toolbag 5 and use it as you would on Windows or MacOS.

The only limitation I am currently aware of is that, despite NVIDIA RTX GPUs, there is unfortunately no GPU-based denoising for ray tracing at the moment. But who knows, maybe someone will find a suitable workaround for this at some point.

Installer terminates with error

If, after installation, Lutris believes that the installation was not successful because the installer terminated with Error 314, for example, you should make sure that you do not delete the installation files when canceling the Lutris installer. This allows you to save the installation in a second step by adding a locally installed application—or, in Lutris parlance, a “game.” The actual installation should have been successful.

To do this, click on the “+” in the upper left corner again and select “Add locally installed game.” You can choose any name you like, and of course, select Wine as the launcher. Then switch to the “Game Options” tab and select the previously installed Toolbag as the “Executable”. The appropriate executable file can be found under <INSTALLATION FOLDER>/drive_c/Program Files/Marmoset/Toolbag 5/toolbag.exe, where <INSTALLATION FOLDER> corresponds to the folder you specified during the original installation. Select <INSTALLATION FOLDER> as the “Wine prefix”. The next step is, of course, the trick to get Marmoset Toolbag 5 running on Linux: Switch to the “Runner Options” tab and change the “VKD3D version” to v2.11.1. Now you can start Marmoset Toolbag 5 and use it as you would on Windows or macOS.

Affinity Suite

There is now the Linux Affinity Installer, an unofficial project designed to make the Affinity suite as easy as possible to run on Linux. It supports both the “old” v2 version of Affinity and the “new” affinity by Canva. This project is not error-free either, so unfortunately it is not yet possible to save program settings in the v2 version, but as you can see from the related issue, the fix is actually available and just needs to be rolled out with the next release.

An AppImage is provided as a download, which must be made executable in order to run it. This can be done either graphically via the file manager or, of course, in the terminal:

~> chmod u+x Downloads/Affinity-3.0.2-x86_64.AppImage
~> Downloads/Affinity-3.0.2-x86_64.AppImage

In File Manager, this is usually done by right-clicking -> Properties -> Permissions, and then it can be started by right-clicking -> Run in console.

After starting, the installer should be self-explanatory, but if not, you can find instructions here. Usually, it should be sufficient to click on One-Click Full Setup and then wait for everything to be installed.

Conclusion & Outlook

I actually thought I would be able to write this article relatively quickly. But then reality caught up with me once again. On the plus side, you should now be able to see that I really do try out the things I write about. I still think it’s a shame that I can’t get Marmoset Toolbag 5 to work at the moment, but I have some hope for the future. Fortunately, I was able to find a solution for Affinity after all. It took more effort than I expected, but at least it works.

After all the work and “productivity” so far, I’ll devote the next article to the more enjoyable side of things: gaming. One article probably won’t be enough, but let’s wait and see.