Wie bereits am Ende des letzten Artikels angekündigt, möchte ich in diesem Artikel Möglichkeiten aufzeigen, wie man versuchen kann, Windows-Software unter Linux zum Laufen zu bringen. Ich muss es an dieser Stelle leider so formulieren, da nicht jede Windows-Software unter Linux läuft. Die Gründe dafür sind sehr unterschiedlich, aber zumindest habe ich das Gefühl, dass es in den letzten Jahren besser wurde. Denn auch wenn Softwarehersteller nicht extra eigene Linux-Versionen erstellen, so habe ich es das ein oder andere Mal erlebt, dass sie zumindest um die Kompatibilität mit Wine bemüht sind.

Neben dem Aufzeigen der generellen Möglichkeiten, um Windows Software unter Linux laufen zu lassen, möchte ich dies auch anhand von Marmoset Toolbag 5 und der Affinity-Suite an praktischen Beispielen zeigen. In diesem Artikel beschränke ich mich aber auf “normale” Software, also müssen alle, die auf Spiele gehofft haben, leider weiter ausharren.

Bevor es wirklich losgeht, hier wie gewohnt die Übersicht über alle bislang erschienen Artikel dieser Serie:

1. Linux? Was zum Pinguin!?
2. Grundlegende Installation der Linux Distribution
3. Installation von nativer Linux-Software
4. Installation von Windows-Software unter Linux

Ein erster Überblick

Wine 🍷

Der Wunsch, Windows-Software unter Linux laufen lassen zu können, ist fast genauso alt wie Linux selbst. Das zentrale Projekt dabei ist Wine 🍷. Wine steht für “WINE is not an emulator” und der Name ist auch Programm. Wine emuliert kein Windows, stattdessen übernimmt es eher die Rolle eines Dolmetschers zwischen Windows und Linux. Technisch funktioniert das vereinfacht, indem Wine die Implementierung der Windows-API dem auszuführenden Windows-Programm zur Verfügung stellt. Aufrufe auf die Windows-API werden dann in “Linux-Befehle” umgewandelt und an Linux weiterleitet. Da dieses “Dolmetschen” meist sehr effizient geschieht, kann Windows-Software so in vielen Fällen ohne merkliche Geschwindigkeitsunterschiede zu einem “richtigen” Windows ausgeführt werden.

Generell versucht Wine, die Windows-API von Windows 3.1 bis Windows 11 bereitzustellen. Je älter die Windows-API, desto vollständiger ist sie in der Regel von Wine implementiert. Aber da Anwendungen nie die vollständige Windows-API benutzen, ist es oft auch mit der unvollständigen Implementierung möglich, aktuelle Programme vollumfänglich zu nutzen.

Forks

Da es sich bei Wine um ein OpenSource-Projekt handelt, darf jeder Änderungen vornehmen, solange er sich an die Lizenzbedingungen hält. Daher begegnet man an diversen Stellen auch immer mal wieder Forks. Die zwei bekanntesten, die noch aktiv in Entwicklung sind, schauen wir uns nun kurz an.

CrossOver

In diesem Zusammenhang sollte man auch CrossOver nicht verschweigen. Das ist eine kommerzielle Wine-Version von CodeWeavers. Wenn man bereit ist, das Geld für CrossOver auszugeben, hat man Anspruch auf Support und auch eine gewisse Garantie, dass bestimmte Software läuft. Selbstverständlich fließen Änderungen am Wine-Quellcode selbst (durch die LGPL) wieder in das Wine-Projekt zurück und zusätzlich beschäftigt CodeWeavers einen Teil der Wine-Entwickler direkt, sodass man durch den Kauf von CrossOver teilweise auch das Wine-Projekt mit unterstützt. Der große Unterscheid bei der Verwendung von CrossOver im Vergleich zum “reinen” Wine ist, dass CrossOver eine grafische Oberfläche bietet und man nicht alles über die Kommandozeile machen muss. Außerdem gibt es, sofern mich mein Gedächtnis nicht täuscht, für manche Softwares auch vorgefertigte Installer.

Proton

Proton möchte ich an dieser Stelle nur kurz erwähnen, da es weit mehr als ein Fork von Wine ist und uns beim Artikel zum Thema Gaming unter Linux garantiert nochmal über den Weg laufen wird. Proton ist eine auf Wine basierende Kompatibilitätsschicht mit dem Fokus auf Gaming. Hinter Proton steckt niemand anderes als Valve, wobei sie auch einige CodeWeavers-Entwickler für die Entwicklung bezahlen. Der auf den ersten Blick größte Unterschied zwischen Proton und “reinem” Wine ist, dass Proton DXVK direkt integriert hat. DXVK ist, vereinfacht gesagt, das Wine im Grafik-API-Umfeld und “übersetzt” Direct3D-Befehle in Vulkan-Befehle.

Frontends

Wine bietet zwar jede Menge Konfigurationsmöglichkeiten, aber erfordert für die Anwendung auch das Setzen von Umgebungsvariablen, das Ausführen von den passenden Verzeichnissen aus und noch ein paar andere Dinge, auf die man achten sollte, wenn man es direkt aus der Kommandozeile heraus verwendet. Glücklicherweise gibt es aber diverse Frontends, die versuchen, dieses Thema zu vereinfachen und im Idealfall so auch Laien die Nutzung zu ermöglichen. Auch hier gilt, wie so oft, dass ich hier nur auf eine kleine Auswahl der verfügbaren Möglichkeiten eingehe. Meine Auswahl basiert dabei in der Regel auf Bekanntheitsgrad und persönlicher Präferenz.

Lutris

Lutris ist eines der besagten Frontends. Der Fokus liegt dabei zwar eigentlich auf Spielen, aber auch andere Software lässt sich darüber installieren und konfigurieren. Lutris ist nicht nur auf Wine beschränkt, sondern man kann auch bspw. ScummVM-Spiele darüber konfigurieren. Zusätzlich kann man auch diverse Accounts (GOG, Steam, …) hinterlegen und hat dadurch direkten Zugriff auf die jeweilige Spielebibliothek.

Neben der reinen Software, bietet Lutris auch noch die Installer-Datenbank. Dort gibt es eine Vielzahl vorgefertigter Installer-Skripte, die man in Lutris einfach benutzen kann. So weiß Lutris direkt, welche Schritte auszuführen sind, um die gewünschte Anwendung zum Laufen zu bringen. Die Skripte werden von Community-Mitgliedern erstellt und ermöglichen es auch weniger technikaffinen Menschen, die jeweilige Software zu installieren. Die Skripte basieren dabei auf YAML und das Format ist ebenfalls dokumentiert.

Bottles

Bottles ist ein weiteres Frontend für Wine. Generell wirkt es auf mich deutlich minimalistischer als Lutris, was auch daran liegt, dass es auf Wine spezialisiert ist. Der Name rührt daher, dass man bei Bottles “Flaschen”, also “Bottles”, anlegt, in denen individuelle Konfigurationen und Abhängigkeiten für verschiedene Anwendungen verwaltet werden können. Technisch stecken da dann unterschiedliche Wine-Präfixe dahinter, also eine bekannte Technik, die natürlich auch von Lutris verwendet wird. Es gibt teilweise auch vorgefertigte Setups für Anwendungen, aber die Auswahl ist noch deutlich geringer als bei Lutris. Ich würde sagen, dass sich Bottles besonders für Nutzer eignet, die Wine verwenden möchten, ohne sich mit komplexen manuellen Einstellungen auseinandersetzen zu müssen.

WinBoat

WinBoat ist noch relativ neu und daher bislang auch nur als Beta-Version verfügbar. Es basiert auf Dockur, das ein sehr abgespecktes Windows 11 als Docker-Container zur Verfügung stellt. Dadurch, dass das Windows in einem Docker-Container läuft und das Anwendungsbild mit Hilfe von RDP, ist der Overhead deutlich geringer als bei einer “normalen” virtuellen Maschine und das Bild deutlich angenehmer und ruckelfreier als mit VNC.

Leider gibt es noch keine Möglichkeit für GPU-Passthrough, sodass die über WinBoat gestarteten Applikationen aktuell leider keine Möglichkeit haben, auf die GPU zuzugreifen. Daher kann es passieren, dass nicht alle Funktionalitäten zur Verfügung stehen oder die Performance doch schlechter als erwartet ist.

In die Praxis

So, genug der grauen Theorie und Hintergrundinformationen. Setzen wir das bislang Gelernte nun endlich in die Praxis um.

Marmoset Toolbag 5

Bevor ich mir Marmoset Toolbag 5 gekauft habe, wusste ich schon, dass ich auf Linux wechseln werde. Daher hatte ich vor dem Kauf mal auf dem offiziellen Discord-Server nachfragt, wie es denn um die Linux-Kompatibilität bestellt ist:

Die Aussage reichte mir aus und ich war deshalb guter Hoffnung, als ich mir die Software kaufte. Als ich dann aber während des Schreibens dieses Artikels Toolbag 5 installieren wollte, holte mich leider die Realität ein.

Bei meinen Versuchen mit Lutris startete am Ende der Installation zwar Marmoset Toolbag sehr zuverlässig und auch der Login klappte problemlos, aber sobald ich etwas in der Menüleiste anklicken wollte, beendete es sich direkt. Da das immer gleich während der Installation passierte und der Installer sich mit dem Rückgabecode 512 beendete, war Lutris der Meinung, dass die Installation fehlerhaft abbrach. Daher konnte ich mit dieser Version erst einmal nicht weiter herumprobieren.

Aber Lutris ist ja nicht die einzige mögliche Option, wie ich vorher beschrieben habe, also dachte ich mir, dass ich doch auch mal Bottles ausprobieren kann. Gesagt, getan. Das Resultat war ein gänzlich anderes, denn Marmoset Toolbag 5 meldete sich beim Start direkt mit der Fehlermeldung, dass es nicht in der Lage sei, das Grafiksystem zu initialisieren. Aber da dank der Fehlermeldung die Installation generell geglückt ist, hatte ich die Möglichkeit, anschließend die verschiedenen Einstellungsmöglichkeiten von Bottles auszuprobieren. Nicht, dass es etwas genutzt hätte, denn egal was ich konfiguriert habe, die Meldung habe ich bislang noch nicht wegbekommen.

Da auch ein Nachfragen im Marmoset Discord keine neuen Erkenntnisse geliefert hat und stattdessen nur auf’s Neue darauf hingewiesen wurde, dass es aktuell keine Pläne gibt, Linux offiziell zu unterstützen und ich diesen Artikel irgendwann auch mal fertigschreiben wollte, habe ich an dieser Stelle erst einmal aufgegeben. Ich hoffe, dass ich mit etwas Abstand und Ruhe Marmoset Toolbag 5 noch zum Laufen bringen kann, da es ansonsten eine extrem gute Software ist und ich mich eigentlich noch tiefgreifender mit den Texturierungsmöglichkeiten auseinandersetzen möchte.

Mit WinBoat habe ich es noch nicht probiert. Die Installation sollte vermutlich problemlos möglich sein, aber da WinBoat aktuell leider noch kein GPU-Passthrough beherrscht, könnte Marmoset Toolbag 5 nicht auf meine GPU zugreifen und somit wäre da nichts gewonnen.

Affinity Suite

Nach meinen Erfahrungen mit Marmoset Toolbag 5 unter Linux hätte ich normalerweise keine Lust mehr gehabt, mich mit Affinity zu beschäftigen. Glücklicherweise hatte ich an dieser Stelle aber schon vorgesorgt und bin bereits vor Wochen auf eine gute Anleitung gestoßen, die ich auch schon mal ausprobiert hatte. Daher wollte ich eigentlich an dieser Stelle einfach auf die Anleitung verweisen und mir das Leben leicht machen. Leider ist mir dann bei der Überprüfung der Repository-Anleitung aufgefallen, dass beim Lutris-Guide nicht mehr alles hundertprozentig wie dort beschrieben funktionieren kann. Daher habe ich nun doch eine eigene Anleitung für Lutris erarbeitet. Ich gehe dabei davon aus, dass Lutris (inkl. wine-10.16-staging) und winetricks bereits installiert sind.

1. Herunterladen des Repositories. Dafür müsst ihr auf den grünen Button mit “<> Code ▼” klicken und dann “Download ZIP” auswählen. Anschließend könnt ihr das ZIP-Archiv entpacken. Der Grund dafür ist, dass man aktuell (22.10.2025) leider noch eine angepasste Wine-Version benötigt. ElementalWarrior, der Ersteller der angepassten Wine-Version, hat seine Änderungen auch schon bei Wine eingereicht und Teile davon wurden glücklicherweise bereits integriert, aber leider noch nicht alle für Affinity notwendigen Patches.
2. Kopiert nun das Verzeichnis ElementalWarriorWine-x86_64, was ihr unterhalb von AffinityOnLinux-main/Auxiliary/wine-affinity/ des entpackten ZIP-Archivs findet, ins Lutris-Verzeichnis für Runner. Bei der lokalen Installation oder bei Nutzung des AppImages befindet es sich unter ~/.local/share/lutris/runners/ und bei der Flatpack-Version von Lutris unter ~/.var/app/net.lutris.Lutris/data/lutris/runners/
3. Für die Installation der gesamten Affinity-Suite habe ich nun auch ein angepasstes Lutris-Installerskript erstellt. Es existiert in zwei Versionen. Die erste Version installiert alle Affinity-Anwendungen innerhalb eines Wine-Präfixes. Die zweite Version installiert immer jeweils nur eine Affinity-Anwendung und legt somit bei Mehrfachnutzung immer ein eigenes Wine-Präfix an.
4. Nach der Installation sind noch ein paar kleinere Anpassungen am Starter notwendig. Daher muss man diesen noch konfigurieren (Rechtsklick auf den Starter -> Konfigurieren):
   1. Wählt im Reiter “Optionen des Starters” ElementalWarriorWine-x86_64 als Wine-Version aus. Das konnte ich leider nicht im Installer vorkonfigurieren, weil die angepasste Wine-Version sich bei der Installation der .NET-Abhängigkeiten über winetricks irgendwie aufhängt.
   2. Wählt im Reiter “Spieleinstellungen” als Ausführbares die ausführbare Datei aus. Die jeweilige EXE, findet ihr
      • für Affinity Photo 2 unter drive_c/Program Files/Affinity/Photo 2/Photo.exe
      • für Affinity Designer 2 unter drive_c/Program Files/Affinity/Designer 2/Designer.exe
      • für Affinity Publisher 2 unter drive_c/Program Files/Affinity/Publisher 2/Publisher.exe
   3. Im Reiter “Spielinfo” könnt ihr nun noch den Namen und die Icons anpassen. Passende Icons findet ihr im Ordner Assets innerhalb des ZIP-Archivs des Repositories, welches ihr bei Schritt 1 heruntergeladen habt.
5. Wenn ihr direkt alle drei Anwendungen installiert habt, dupliziert ihr den Starter und wiederholt Schritt 4.

Fazit & Ausblick

Eigentlich dachte ich, dass ich diesen Artikel relativ schnell “herunterschreiben” kann. Dann wurde ich mal wieder von der Realität eingeholt. Dafür solltet ihr nun sehen können, dass ich die Dinge, von denen ich schreibe, auch wirklich ausprobiere. Ich finde es weiterhin schade, dass ich Marmoset Toolbag 5 aktuell nicht zum Laufen kriege, habe aber etwas Hoffnung für die Zukunft. Aber glücklicherweise konnte ich dann doch noch eine Lösung für Affinity finden. Es war zwar für mich aufwendiger als gedacht, aber zumindest funktioniert es.

Nach der ganzen bisherigen Arbeit und dem “Produktivsein”, widme ich mich im nächsten Artikel den angenehmeren Seiten: Dem Gaming. Wahrscheinlich wird da ein Artikel nicht reichen, aber warten wir es mal ab.