Dieser Text wurde von CodeWeavers unter einer freien Lizenz
im offiziellen Blog veröffentlicht wobei ich mir die Freiheit genommen habe, diesen Text zu übersetzen und den Interessenten an Wine, sei es Linux oder macOS zur Verfügung zu stellen.
Über diese Hilfen
Dies ist eine Serie von Hilfen, die darauf abzielen, Softwareentwickler in das Wine-Ökosystem einzuführen. Es wird was Wine ist, wie man Wine benutzt, wie man Wine debugt, wie man Wine repariert und was man mit der Korrektur macht sobald man es geschafft hat.
Diese Handbücher werden im Laufe des Januars veröffentlicht werden.
- Teil 1 beschreibt was Wine ist und bietet eine kurze Beschreibung verschiedener bekannter Forks von Wine.
- Teil 2 beschreibt Wine’s Buildprozess.
- Teil 3 beschreibt wie man Wine als Entwickler nutzt.
- Teil 4 beschreibt wie man allgemein Wine debugt.
- Teil 5 beschreibt Wines Quellbaum-Aufbaum und wie man die Quellen bearbeitet.
- Teil 6 beschreibt wie man seine Arbeit “upstream” senden kann.
Was ist Wine?
Wine ist eine Open Source Reimplementierung von Microsofts Windows Betriebssystem auf Basis von verschiedenen Unix Betriebssystemen. Es zielt vorrangig auf Linux und macOS ab, kann aber auf anderen Systemen wie FreeBDS, NetBSD und Solaris laufen. Dies bedeutet für Benutzer, dass sie Software, die für Windows geschrieben wurde, auf anderen Systemen laufen lassen können. Wine beinhaltet keinen Microsoft-eigenen Code womit kein Bedarf an einer Windowslizenz zum Betrieb von Wine nötig ist. Stattdessen haben die Wine-Entwickler Komponenten des Windows-Betriebssystems neu geschrieben. So denkt die Software, dass sie auf Windows läuft obwohl sie tatsächlich auf Linux beispielsweise betrieben wird.
Als ein einfaches Beispiel betrachten wir die Windows CreateFile API. Auf Windows könnte der Aufruf einer Anwendung wie folgt aussehen:
CreateFileA(
"C:\some_file.txt", //lpFileName
GENERIC_WRITE, //dwDesiredAccess
0, //dwShareMode
NULL, //lpSecurityAttributes
CREATE_ALWAYS, //dwCreationDisposition
FILE_ATTRIBUTE_NORMAL, //dwFlagsAndAttributes
NULL //hTemplateFile
);
Wine übernimmt diesenCreateFileA Aufruf und übersetzt diesen in einen Unix open Aufruf:
open(
"/home/aeikum/.wine/drive_c/some_file.txt", //path
O_WRONLY | O_CREAT, //oflag
0644 //creation mode
);
Das Filehandle wird der Anwendung zurück gemeldet, welche dann in die Dateie mit einer ähnlichen Implemtierung schreiben kann. Beispielsweise wäre dies WriteFile auf Unix’s write. Natürlich ist die tatsächliche Implementierung von CreateFileA in Wine weit, weit komplizierter als dies (siehe Konvertierung von Pfaden beispielsweise) aber dies vermittelt einen Eindruck, was Wine macht.
Wine Forks
Da Wine ein Open Source Projekt ist, steht es jedem offen, Kopien zu erstellen und diese zu modifizieren um den Bedürfnissen der jeweiligen Benutzer zu entsprechen. Es gibt Hunderte von Wine-Forks aber einige davon wurden sehr bekannt und werden hier beschrieben.
“Upstream” Wine
Webseite: https://www.winehq.org/
Dies ist die reine Version von Wine von der alle anderen Forks abgeleitet werden. Wenn sich jemand auf “Upstream Wine” beruft, spricht er von diesem Projekt. Wine fokussiert primär auf Richtigkeit. Wine beinhaltet extensive Unittests, welche das Verhalten von Windows zeigen und verlangt von den meisten Patches, dass sie Tests liefern. Alle Patches müssen die bestehenden Tests erfolgreich durchlaufen damit sie akzeptiert werden. Es gibt ebenso eine starke Fokussierung auf Code-Qualität. Wine ist ein sehr großes Projekt (eigentlich ein ganzes Betriebssystem inkl. GUI) wobei Technische Schulden stark vermieden werden damit das Projekt wartbar im Laufe der Zeit bleibt.
Wine Staging
Webseite: https://wiki.winehq.org/Wine-Staging
Dennoch bedeutet Wines strenge Akzeptanz von Patches, dass viele ungetestete, falsche oder gefährliche Patches in privaten Forks oder im Bugtracken sich sammeln würden. Diese könnten aber für heutige Nutzer durch aus nützlich sein. Das Wine Staging Projekt (auch “wine-staging” genannt) ist ein Versuch, diese nützlichen Patches zu sammeln so dass Nutzer leicht Vorteile darauf ziehen können. Die Wine Staging Community arbeitet daran, diese Patches in Wine zu bringen damit der Nutzen für alle Winenutzer und Forks zu Gute komme wobei gleichzeitig Wine Stagings eigene Wartung sinkt. Es kann auch als “Bewährungsfeld” für Patches dienen die eine schwere Bewährung haben bevor sie Upstream akzeptiert werden.
CrossOver
Webseite: https://www.codeweavers.com/
CrossOver ist ein kommerzieller Fork von Wine, welcher von der Firma CodeWeavers verkauft wird. Es beinhaltet viele anwendungs-spezifische Hacks, die nicht zum Einbinden in Upstream geeignet sind.CodeWeavers unterhält ebenso eine Anwendungs-Kompatibilitäts-Datenbank welche einige Softwarekomponenten vorab installiert und die Wineumgebung entsprechend modifiziert. Dennoch zieht es CodeWeavers stark vor, Features richtig zu implementieren und sendet die Arbeit an “Upstream Wine”. CodeWeavers Mitarbeiter leisten einen bedeutenden Beitrag bei der Arbeit an Wine.
Proton
Webseite: https://github.com/ValveSoftware/Proton/
Proton ist ein Fork, welcher von der Firma Valve erstellt wurde und in ihre Steam Software, eine bedeutende Videospiel und Programm-Plattform, integriert ist. Proton fokussiert sich darauf, ein angenehmes Erlebnis für Steamnutzer beim Betrieb von Windowstiteln auf Linux zu bieten. Wie auch bei CrossOver, werden die meisten der Beiträge auch an “Upstream Wine” geschickt.
Andere Forks
Es gibt sehr, sehr viele andere Forks von Wine. Manche werden mit kommerzieller Software paketiert und als macOS und Linux-Software verkauft. Manche sind einmalige Forks, die von Benutzern für eine einzelne Anwendung erstellt wurden.
Entwickeln für Wine
Wine ist nicht perfekt und es ist wahrscheinlich, dass man auf einen Mangel oder Bug im Tagesbetrieb von Wine stößt. Vielleicht sind Sie interessiert daran, Wine zu verbessern damit es ihre Anwendung oder Spiel in Betrieb nimmt oder vielleicht will ihr Arbeitgeber Wine verwenden und Sie bezahlen, es zu beheben. Dieses Handbuch wird Sie darin unterstützen wie man Wine kompilieren, Debuggen und beheben kann und wie man diese Fixes upstream sendet.
The text of this blog post is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
