Interview: Wine - spieletauglich und mit Antivirenfunktionen

Golem.de im Gespräch mit Wine-Projektleiter Alexandre Julliard. Das Wine-Projekt arbeitet an einer freien Implementierung des Windows-API, die es ermöglicht, Windows-Anwendungen unter Linux und anderen Unix-Derivaten auszuführen. Bereits seit 1994 leitet Alexandre Julliard das ein Jahr zuvor gegründete Projekt und war auch einer der ersten Entwickler. Sein Geld verdient der Schweizer als CTO bei CodeWeavers, die eine kommerzielle Wine-Variante anbieten. Mit Golem.de sprach er über die herannahende Version 1.0, die Vorbereitungen auf Windows Vista und CodeWeavers-Produkte.

5. Juli 2006 um 12:14 Uhr / Julius Stiebert

Golem.de: Seit die erste Beta-Version von Wine im Oktober 2005 erschienen ist, gibt es nur 0.9.x-Veröffentlichungen anstatt einer Version 1.0. Wie ist der derzeitige Status des Projektes, wie nah sind Sie an etwas, das Sie als 1.0 bezeichnen würden?

Alexandre Julliard: Der Kern ist ziemlich stabil und wir haben große Fortschritte bei Installern gemacht, so dass sich die meisten Anwendungen installieren lassen sollten. Dies ist das Hauptziel für 1.0. Derzeit arbeiten wir noch daran, die Spieleunterstützung zu verbessern und ich warte mit der Veröffentlichung von 1.0, bis diese ebenfalls stabil ist. Spiele sind einer der Hauptgründe, weshalb Leute sich Wine anschauen. Also muss die Version 1.0 in dieser Hinsicht so gut wie möglich sein.

Golem.de: Wine implementiert auch Fehler aus Windows, die zu ernsten Problemen führen können. Ein Beispiel ist das Ende 2005 aufgetretene WMF-Problem . Einige Leute könnten daher fordern, dass Sie Fehler besser korrigieren statt übernehmen sollten. Was ist Ihre Meinung dazu?

Julliard: Wir korrigieren Fehler natürlich, sofern dies möglich ist, ohne die Kompatibilität zu zerstören. Der WMF-Fehler wurde nicht absichtlich übernommen. Es war eine unbeabsichtigte Konsequenz aus der Arbeitsweise des APIs und ich denke, weder wir noch Microsoft haben realisiert, dass sie missbraucht werden könnte.

Ich erwarte jedoch nicht, dass der Wine-Code unbedingt sicherer ist als Microsofts Quelltext. Wahrscheinlich haben auch wir eine Menge derselben Fehler, da wir dieselben Funktionen implementieren. Unsere zusätzliche Sicherheit kommt daher, dass Wine unter Unix läuft. Es ist also egal, wie viele Sicherheitslücken in Wine sein könnten, sie würden einer Anwendung nicht ermöglichen, die Unix-Sicherheitsmechanismen zu umgehen.

Golem.de: Die Entwickler des freien Windows-Klons ReactOS hatten kürzlich Probleme, da ihnen vorgeworfen wurde, ihr Quelltext enthalte illegale Teile. Sie mussten daraufhin den kompletten Quellcode überprüfen , um sicherzustellen, dass niemand, der Zugang zum original Windows-Code hatte, entsprechende Teile für ReactOS programmiert. Wie geht das Wine-Team mit diesem Problem um, wie stellen Sie sicher, dass kein Windows-Code in Wine gelangt?

Julliard: Ich prüfe persönlich alle Beiträge. Wenn etwas verdächtig aussieht, ist es kein Problem, durch ein paar Fragen festzustellen, ob derjenige den Quelltext wirklich selbst geschrieben hat. Wir arbeiten außerdem momentan mit dem Software Freedom Law Center zusammen, um die Herkunft eines jeden Code-Beitrags zu dokumentieren. Außerdem entwicklen wir Prozeduren für neue Entwickler, um sicherzustellen, dass uns das ReactOS-Problem nie trifft.

Golem.de: In den letzten Wine-Versionen gab es viele Verbesserungen für die DirectX-Unterstützung. Allerdings setzt Transgaming das DirectX-API für Cedega ebenfalls auf Basis von Wine um. Muss das Wine-Projekt dennoch die ganze Arbeit nochmal machen oder gibt Transgaming etwas zurück?

Julliard: Wir müssen es alles nochmal machen, Transgaming gibt nichts von ihrem DirectX-Code zurück. Wie dem auch sei, ihr Quelltext wäre zu diesem Zeitpunkt auch nicht sonderlich nützlich. Ihr Code ist sehr von unserem abgewichen, seit sie ihren Fork begonnen haben.

Golem.de: Ist dies ein Problem für das Wine-Projekt, da Transgaming doch sicher noch immer von Wine profitiert? Und muss Transgaming nicht die eigenen Entwicklungen ebenfalls unter der LGPL zugänglich machen?

Julliard: Nein, Transgaming hat den Fork begonnen, als Wine noch unter der X11-Lizenz veröffentlicht wurde. Sie müssen ihre Änderungen also nicht zurückgeben. Tatsächlich war Transgamings Verhalten ein Hauptgrund, der die Entwickler überzeugt hat, dass die LGPL die bessere Wahl ist.

Für Wine ist es kein großes Problem, dass sie nichts zurückgeben, da dies durch die Lizenz explizit gestattet war. Das wirkliche Problem ist, dass Transgaming versprochen hatte, uns ihre Arbeit zu übergeben. Die DirectX-Entwicklung in Wine stand daher lange still, während wir auf einen Beitrag gewartet haben, der nie kam. Aber das liegt hinter uns, die Entwicklung hat wieder begonnen und ist sehr aktiv.

Golem.de: Derzeit setzt Wine das Windows-2000-API um, Vista wird ein neues API haben. Wie wirkt sich das aus, wird es eine Kooperation mit dem Mono-Projekt geben?

Julliard: Ich glaube nicht, dass das API völlig neu sein wird, es ist dasselbe, was Microsoft bei jeder neuen Windows-Version behauptet. Für die .Net-Unterstützung müssen wir natürlich mit dem Mono-Projekt zusammenarbeiten, aber es wird auch in Vista noch eine Menge altmodischer Win32-API-Aufrufe geben. In jedem Fall interessiert uns nur, was die Anwendungen nutzen. In jeder neuen Windows-Version gibt es einen Haufen neuer APIs, die einfach nie von Programmen angesprochen werden. Also bemühen wir uns auch nicht, diese zu implementieren.

Golem.de: Gibt es schon konkrete Versuche, Mono in Wine zu integrieren?

Julliard: Es gab bereits einige Gespräche. Wir haben aber noch nichts unternommen, um Mono zu integrieren, einfach weil wir keinen Bedarf sehen. Zurzeit scheint es keine interessante .Net-Anwendung zu geben, die die Anwender mit Wine einsetzen wollen. Also hat Mono für uns keine Priorität.

Golem.de: Wine läuft ausschließlich auf der x86-Architektur, inwiefern ist das ein Problem für Linux?

Julliard: Die Mehrheit der Linux-Systeme läuft auf x86, also denke ich nicht, dass es ein Problem für Linux ist. Es kann natürlich ein Problem für Leute sein, die sich für eine andere Plattform entschieden haben, aber das ist natürlich ihre Schuld... Ok, das ist nicht ganz ernst gemeint.

Man sollte allerdings bedenken, dass Wine X11 nutzt und damit transparent über das Netzwerk laufen kann. Es ist also immer möglich, eine billige x86-Maschine in die Ecke zu stellen und Windows-Anwendungen entfernt auszuführen. Natürlich kann man Wine auch immer mit einem CPU-Emulator wie QEMU einsetzen.

Golem.de: CodeWeavers hat CrossOver Office für MacOS X für Intel-Prozessoren angekündigt. Wie weit ist dieses Projekt, wann wird die fertige Version kommen?

Julliard: Wir befinden uns zurzeit noch in der Alpha-Phase. Ich denke, es funktioniert bereits ganz ordentlich, aber der Feinschliff fehlt noch. Es sollte aber in ein bis zwei Monaten fertig sein.

Golem.de: Wie sieht CodeWeavers denn die Chancen für dieses Produkt, da viele Windows-Anwendungen auch in einer Variante für MacOS X existieren?

Julliard: Es wird einen anderen Schwerpunkt haben. Es ist klar, dass die großen Anwendungen wie Microsoft Office nicht interessant sind, da es sie bereits für MacOS gibt. Es gibt aber auch eine Reihe von Programmen, die es auf dem Mac nicht gibt, Outlook und Visio beispielsweise. Vor allem auch viele Spiele, also konzentrieren wir uns darauf, diese zu unterstützen. Ich denke, diese Situation wird auch in der Linux-Welt auftreten. Der Bedarf für Microsoft Office nimmt ab, da es zuverlässige Alternativen wie OpenOffice gibt. Der Fokus wird sich also auf beiden Plattformen hin zu exotischeren Applikationen bewegen.

Die größte Herausforderung für uns ist nun, dass es auf dem Weg weg von den Blockbuster-Anwendungen weniger Nutzer für jedes Programm gibt. Wir müssen also eine breitere Basis unterstützter Applikationen bieten, um dieselbe Anzahl an Kunden zufrieden zu stellen.

Golem.de: Wie möchten Sie dies erreichen? Viele Nutzer schauen sicher nur auf die großen Applikationen, die es auch für MacOS gibt.

Julliard: Ich denke nicht, dass es ein Problem sein wird, Kunden zu finden, die Windows-Software brauchen, die es nicht für den Mac gibt. Es gibt viele solcher Programme. Die Herausforderung ist eher, genügend Anwender zu finden, die dieselbe Software wollen, so dass sich die Zahlen für uns lohnen. Ein Weg, um dies zu erreichen, ist das " CodeWeavers Compatibility Center ". Dort können Anwender für Programme, die sie haben wollen, abstimmen und Geld für die Arbeit an bestimmten Anwendungen stiften.

Wenn Wine besser wird und Fehler korrigiert werden, wird es außerdem zunehmend einfacher, für uns neue Anwendungen zum Laufen zu bringen. Dadurch wird es für uns hoffentlich machbar, Anwendungen zu unterstützen, für die es nur bei wenigen Nutzern Bedarf gibt.

Golem.de: CodeWeavers hat vor längerer Zeit auch bekannt gegeben, dass es Überlegungen über eine FreeBSD-Portierung gibt. Wie weit ist dieser Gedanke fortgeschritten und wird die Portierung durch die Arbeit an der MacOS-X-Version erleichtert?

Julliard: Es wird unter Umständen ein bisschen einfacher, obwohl FreeBSD und Darwin unter der Haube ziemlich unterschiedlich sind. Zumindest was die Funktionen des Kernels angeht, die wir nutzen. Eine FreeBSD-Version ist sicherlich machbar, aber es arbeitet noch niemand von uns daran. Es fehlt die notwendige Nachfrage, um die Entwicklungskosten zu rechtfertigen.

Golem.de: Google hat mit CodeWeavers zusammen an der Picasa-Version für Linux gearbeitet. Warum gab es eine speziell mit Wine gebündelte Version anstatt einer für Wine zertifizierten Picasa-Variante?

Julliard: In gewisser Hinsicht ist es eine für Picasa zertifizierte Wine-Version, die enthalten ist. Das Picasa-Binary ist identisch mit der Windows-Version, die komplette Linux-Unterstützung kommt also von Wine. Die mitgelieferte Wine-Version enthält daher einige Picasa-spezifische Änderungen, um die Arbeit mit Picasa angenehmer zu gestalten. Hauptsächlich waren es kleine Details. Der Großteil dieser Änderungen ist bereits in die offizielle Wine-Version zurückgeflossen.

Golem.de: Wie kam es denn zu der Arbeit mit Google und sind schon andere Projekte geplant?

Julliard: Ein Teil von Googles Motivation war einfach, dabei zu helfen, Wine zu verbessern und dafür sind wir sehr dankbar. Ich denke, ein anderer Grund war zu schauen, wie eine Linux-Portierung ankommt und Wine ist hierfür eine gute Wahl. Da es sehr einfach ist, eine Linux-Version zu veröffentlichen, ohne die halbe Anwendung neu zu schreiben. Ich hoffe, dass es weitere Projekte geben wird, aber zu diesem Zeitpunkt kann ich dies nicht weiter kommentieren.

Golem.de: Was erwarten Sie für Wine von Googles Summer of Code 2006?

Julliard: Es wird hoffentlich ein paar neue Funktionen geben, wie eine bessere Desktop-Integration und Antivirenfunktionen. Was viel wichtiger ist: Ich hoffe, dass wir neue Entwickler dazugewinnen. Ein paar der Studenten vom letztjährigen Summer of Code tragen immer noch zu Wine bei und ich hoffe, dies wird 2006 wieder der Fall sein.

Golem.de: Welchen bestimmten Zweck sollen Antivirenfunktionen in Wine erfüllen?

Julliard: Die befinden sich noch im Forschungsstadium, aber die Idee dahinter ist, jede ausführbare Datei zu überprüfen. Entweder, bevor sie ausgeführt oder jedesmal, wenn sie geändert wird. Ähnlich dem, was Antivirenprogramme unter Windows machen. Wir hatten noch keine Virenprobleme mit Wine, aber da die Kompatibilität zunimmt, ist es nur eine Frage der Zeit, bevor ein Windows-Virus auch unter Wine läuft. Selbst wenn Viren unter Wine nicht denselben Schaden wie unter Windows anrichten können, könnten sie beispielsweise immerhin in der Lage sein, E-Mails zu versenden. Es wäre also gut, entsprechende Mechanismen zu haben, um dies zu verhindern.