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
5. Gaming unter Linux
6. Die Unreal Engine unter Linux
7. Mögliche Backup-Lösungen 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. Meine ursprünglichen Versuche, die ich hier auch niedergeschrieben hatte, sind leider alle gescheitert. Aber glücklicherweise hat mich heute eine Nachricht erreicht, wie man Marmoset Toolbag 5 nun zuverlässig mit Lutris starten kann.

Die Installation mit Lutris läuft in der Regel problemlos. Bevor die Installation aber starten kann, muss zuerst der aktuelle Installer von der Marmoset-Seite heruntergeladen werden. Anschließend klickt man in Lutris auf das “+” in der oberen linken Ecke und wählt “Install a Windows game from an executable” aus, um dann den Schritten des Setups zu folgen.

Nach erfolgreicher Installation kommt nun der eigentliche Trick: Damit Marmoset Toolbag 5 stabil mit Lutris bzw. Wine läuft, muss man die Version von VKD3D auf die ältere Version v2.11.1 setzen. Dafür öffnet man per Rechtsklick auf die zugehörige Kachel in der Bibliothek die Konfigurationseinstellungen des frisch installierten Programms. Anschließend navigiert man in den Reiter “Optionen des Starters”, um dort die “VKD3D-Version” auf v2.11.1 zu ändern. Nun kann man Marmoset Toolbag 5 starten und, wie von Windows oder MacOS gewohnt, benutzen.

Die einzige Einschränkung, welcher ich mir aktuell bewusst bin, ist, dass man trotz NVIDIA RTX GPU leider momentan kein GPU-basiertes Denoising beim Raytracing hat. Aber wer weiß, vielleicht findet dafür irgendwann jemand ebenfalls einen passenden Workaround.

Installer “stürzt” ab

Sollte nach der Installation Lutris der Meinung sein, dass die Installation nicht erfolgreich war, weil sich der Installer bspw. mit Error 314 beendet hat, sollte man beim Abbruch des Lutris-Installers darauf achten, dass man die Installationsdateien nicht löscht. Dadurch kann man im zweiten Schritt die Installation retten, indem man eine lokal installierte Anwendung - bzw. im Lutris-Sprech ein “Spiel” - hinzufügt. Die eigentliche Installation sollte erfolgreich gewesen sein.

Dafür klickt man ein weiteres Mal auf das “+” in der oberen linken Ecke und wählt nun “Lokal installiertes Spiel hinzufügen” aus. Den Namen kann man frei wählen und als Starter wählt man natürlich Wine aus. Anschließend wechselt man auf den Reiter “Spieleinstellungen” und wählt als “Ausführbares” das vorher installierte Toolbag aus. Die passende ausführbare Datei findet man unter <INSTALLATIONSORDNER>/drive_c/Program Files/Marmoset/Toolbag 5/toolbag.exe, wobei <INSTALLATIONSORDNER> dem Ordner entspricht, den man bei der ursprünglichen Installation angegeben hat. Als “Wine-Präfix” wählt man <INSTALLATIONSORDNER> aus. Im nächsten Schritt kommt hier natürlich ebenfalls der Trick, um Marmoset Toolbag 5 unter Linux zum Laufen zu bringen: Man wechselt auf den Reiter “Optionen des Starters” und ändert dort die “VKD3D-Version” auf v2.11.1. Nun kann man Marmoset Toolbag 5 starten und, wie von Windows oder MacOS gewohnt, benutzen.

Affinity Suite

Es gibt mittlerweile den Linux-Affinity-Installer, ein inoffizielles Projekt, was die Affinity-Suite möglichst einfach unter Linux lauffähig machen soll. Es wird sowohl die “alte” v2-Version von Affinity unterstützt als auch das “neue” affinity by Canva. Auch dieses Projekt ist nicht fehlerfrei, sodass es zum aktuellen Zeitpunkt leider noch nicht möglich ist, Programmeinstellungen in der v2-Version zu speichern, aber wie man dem zugehörigen Issue entnehmen kann, ist der Fix eigentlich vorhanden und muss nur noch mit dem nächsten Release ausgerollt werden.

Als Download wird ein AppImage bereitgestellt, welches ausführbar gemacht werden muss, um es anschließend auszuführen. Das kann man entweder graphisch über den Dateimanager erledigen oder natürlich auch im Terminal:

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

Im Dateimanager geht dies in der Regel unter Rechtsklick -> Eigenschaften -> Berechtigungen und anschließend kann es per Rechtsklick -> In Konsole ausführen gestartet werden.

Nach dem Start sollte der Installer eigentlich selbsterklärend sein, falls nicht, findet ihr hier die Anleitung. In der Regel sollte es reichen, auf One-Click Full Setup zu klicken und anschließend abwarten, dass alles installiert wird.

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.