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

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. However, when I wanted to install Toolbag 5 while writing this article, reality unfortunately caught up with me.

During my attempts with Lutris, Marmoset Toolbag started up reliably at the end of the installation and I was able to log in without any problems, but as soon as I tried to click on something in the menu bar, it shut down immediately. Since this always happened during installation and the installer terminated with return code 512, Lutris assumed that the installation had been aborted due to an error. Therefore, I couldn’t continue experimenting with this version for the time being.

But Lutris isn’t the only option, as I described earlier, so I thought I’d give Bottles a try. No sooner said than done. The result was completely different, because Marmoset Toolbag 5 immediately displayed an error message upon startup, stating that it was unable to initialize the graphics system. But since the error message indicated that the installation had been successful overall, I was able to try out the various settings options in Bottles. Not that it did any good, because no matter what I configured, I haven’t been able to get rid of the message yet.

Since inquiring on Marmoset Discord didn’t yield any new insights and instead only reiterated that there are currently no plans to officially support Linux, and since I wanted to finish writing this article at some point, I decided to give up for now. I hope that with a little distance and calm, I will be able to get Marmoset Toolbag 5 up and running, as it is otherwise an extremely good piece of software and I would really like to explore its texturing capabilities in more depth.

I haven’t tried it with WinBoat yet. The installation should probably be possible without any problems, but since WinBoat unfortunately does not yet support GPU passthrough, Marmoset Toolbag 5 would not be able to access my GPU, so there would be no benefit.

Affinity Suite

After my experience with Marmoset Toolbag 5 on Linux, I normally wouldn’t have been interested in trying Affinity. Fortunately, I had already taken precautions and came across a good tutorial weeks ago, which I had already tried out. So I actually wanted to just refer to the guide at this point and make my life easier. Unfortunately, when checking the repository guide, I noticed that not everything in the Lutris guide works 100% as described there. So I’ve decided to write my own instructions for Lutris after all. I’m assuming that Lutris (including wine-10.16-staging) and winetricks are already installed.

1. Download the repository. To do this, click on the green button labeled “<> Code ▼” and then select “Download ZIP”. You can then unzip the ZIP archive. The reason for this is that, unfortunately, you currently (October 22, 2025) still need a customized version of Wine. ElementalWarrior, the creator of the customized Wine version, has already submitted his changes to Wine, and fortunately, some of them have already been integrated, but unfortunately, not all of the patches necessary for Affinity have been integrated yet.
2. Now copy the ElementalWarriorWine-x86_64 directory, which you will find under AffinityOnLinux-main/Auxiliary/wine-affinity/ in the unzipped ZIP archive, to the Lutris directory for runners. For local installation or when using AppImages, it is located under ~/.local/share/lutris/runners/, and for the Flatpack version of Lutris, it is located under ~/.var/app/net.lutris.Lutris/data/lutris/runners/.
3. I have now also created a customized Lutris installer script for installing the entire Affinity suite. There are two versions. The first version installs all Affinity applications within a Wine prefix. The second version only installs one Affinity application at a time and therefore always creates a separate Wine prefix on each use.
4. After installation, a few minor adjustments to the launcher are necessary. Therefore, you must configure it (right-click on the launcher -> Configure):
   1. In the “Starter Options” tab, select ElementalWarriorWine-x86_64 as the Wine Version. Unfortunately, I was unable to preconfigure this in the installer because the customized Wine version somehow hangs when installing the .NET dependencies via winetricks.
   2. In the “Game Settings” tab, select the executable file as the Executable. You can find the respective EXE
      • for Affinity Photo 2 under drive_c/Program Files/Affinity/Photo 2/Photo.exe
      • for Affinity Designer 2 under drive_c/Program Files/Affinity/Designer 2/Designer.exe
      • for Affinity Publisher 2 under drive_c/Program Files/Affinity/Publisher 2/Publisher.exe
   3. In the “Game Info” tab, you can now customize the Name and Icons. You can find suitable icons in the Assets folder within the ZIP archive of the repository, which you downloaded in step 1.
5. If you have installed all three applications directly, duplicate the launcher and repeat step 4.

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.