Kinners, holt euch mal nen Tee und setzt euch. - Opa erzäht von früher...
VOR Steam war es so, dass man Programme (Spiele, Anwendungen, ...) entweder auf Datenträgern bekam oder sich von Hersteller XY herunterlud. Zu den Programmen gab es AGB, EULAs, Kopierschutzmechanismen (wie Passwort-Abfragen aus dem Handbuch, welches schwarze Schrift auf dunkelbraunem Untergrund hatte) und Co wie heute. Aber im Prinzip konnte man die Programme nehmen, ins Regal stellen und auch in 50 Jahren noch neu installieren. Online-Abfragen waren gerade erst im kommen. Üblicherweise wurde das Problem der Lizenz-Validität durch Prüfung der Datenträger-Gültigkeit (Secu-ROM, Nicht-lesbare Sektoren auf CDs/DVDs und sogannte Un-CDs) gelöst. Unter Windows lief der Kram mehr oder weniger und unter Linux gab es die entsprechenden NoCD-Cracks, um das Zeug dennoch abspielen zu können. Updates gab es entweder gar nicht oder wenn doch, wurden sie per Internet oft händisch nachinstalliert. Um ein Spiel unter Linux zu installieren, wurde es entweder aus der Kommandozeile mit "wine Installer-zu-Programm.exe" aufgerufen oder mittels Kontext-Menü (rechte Maustaste) "Anwendung mit Wine starten" ge... äääh ja, ...startet.
WINE sieht sich selbst als "Wine Is Not an Emulator". Es emuliert also angeblich kein Windows, auch wenn es das z.B. durch die mögliche Auswahl der Ziel-Windows-Version letztlich doch irgendwie tut. Es ist eine Übersetzungsschicht, die die Windows-Programmbefehle in Linux-Befehle umsetzt und das Ergebnis für das Windows-Programm wieder verständlich macht. In frühen Versionen unterstützte es lediglich Anwendungen, die auch OpenGL sprachen, wenn es 3D sein musste. (Nicht ungewöhnlich. DirectX war erst auf dem Siegeszug auf dem PC. Vorher waren GLIDE (3dfx) und OpenGL durchaus Konkurrenten.) Erst später kamen die Direct3D-Versionen 7, 8 und später 9 dazu. Ab 10 wurde es schwierig, denn der dazu nötige Code war unglaublich langsam.
Aber erstmal genug zum Exkurs zu Wine. Zurück zu den Programmen und den Datenträgern... denn:
Dann, so munkelt man, musste sich der doch gut beleibte Gabe Newell, der Chef von Valve, vermutlich einmal zu oft nach einem heruntergefallenen Datenträger bücken und hatte eine Eingebung: Was, wenn man allen Kram direkt von einem Programm aus organisieren konnte? Alle Spiele mit je einem Klick installieren und aktuell halten? STEAM war geboren. Die Windows-Welt musste nicht mehr ständig Dutzende Seiten abklappern, um Updates für ihre Spiele zu bekommen. Ein Traum? Eher nein. Denn: Mit Steam begann auch die Lizensierung von Software für die Endnutzer einschneidender zu werden. Konnte man früher Software verkaufen, indem man den Datenträger/die Software plus Lizenzschlüssel weitergab, fiel das mit Steam weg. Software, die DU gekauft hast, konntest auch nur DU nutzen. Überhaupt bekam der Begriff "Nutzungsrecht" eine neue Dimension. Denn: War der Steam-Dienst mal weg, konnte man eben keine neue Software mehr installieren, deren Lizenz via Steam lief. Lediglich bereits installierte Software lief in einem Notfall-Offline-Modus. Und unter Linux? Lange Zeit lange Gesichter. Steam musste laufen, um die dazugehörigen Anwendungen starten zu können.
Wegen der ganzen Probleme daher war Steam in vielen Kreisen lange als "STEAMing pile of shit" bekannt. Es nahm einem die Freiheiten, die Software aus beliebigen Quellen zu installieren oder wie in der Linux-Welt üblich, in seine Repositories (große Software-Bibliotheken, die alles enthalten, was man zur Nutzung der jeweiligen Distribution wollen könnte) zu integrieren. Zusätzlich verdongelte Steam auch die Lizenz mit der Steam-Nutzung und machte die bisherigen Ansätze der Spiele-Nutzung unter Linux schwieriger. Ähnlich wie Epic heute war Valves Steam umstritten. Man darf ja auch nicht vergessen: Gabe kassierte je gekaufter Anwendung 30% Provision. Und das läpperte sich so sehr, dass man gar kein Half Life³ mehr entwickeln musste, um im Geld zu schwimmen.
Das änderte sich erst, als Microsoft aus den Debakeln um Windows Fone 7 und 8 (und dessen restriktiver Politik des Anwendungsmarktes) nichts gelernt hatte und mit Windows for ARM 8 einen auf "Apple" machen wollte und jegliche Fremdinstallation von Software verbat. Das inkludierte übrigens auch die Installation von Launchern wie Steam. Keine Awendung durfte weitere Programme installieren. (Kommt das irgend welchen Apple-Jüngern im Hinblick auf Remote Gaming grade bekannt vor?) Und für die Zukunft, also Windows 10 war das ebenso gesetzt. Das Zeichen setzte man auch mit der Xbox3 (Xbox One), die geplant nur noch einen digitalen Distributionskanal haben sollte. Da wurde Gabe munter. Die Software-Hersteller sollten auf SEINER (also Gabes) Hauptplattform "Windows" direkt mit Microsoft reden müssen und ihr Geld dann an Microsoft abdrücken? Das durfte nicht sein. Also erinnerte sich Gabe zurück, wie es vor Steam und Windows war. - Und dass es da noch eine Welt gab, auf die er setzen konnte: Quasi eine eigene Xbox/Playstation-Version. Eine Steam-Box. Und da Windows ja raus war, denn darauf sollte man ja keine Anwendungen mehr am MS-Store vorbei installieren können, fiel im Linux auf. ReactOS (ein binärkompatibler Windows-Nachbau) war keine Lösung, da ZU weit von aktuell nötiger Leistungsfähigkeit entfernt. Halbwegs akzeptable Grafiktreiber, Wine war so weit gereift, das DX9-Anwendungen und damalige Multiplayer-Titel recht brauchbar liefen... Und aus der Idee Steam-Box WURDE die Steambox. Basierend auf Ubuntu und Wine.
Blöd nur: Die ganzen Publisher wollten nicht so ganz mitziehen. Eine native Linux-Version hätte viel Entwicklungs- und Supportaufwand bedeutet. Und ihnen war auch egal, wer letztlich ihr Geld bekam. Valve oder MS? War ihnen Leiste. Also musste sich Valve reinhängen. Es wurden ein richtiges Projekt daraus, die Steam-Machines, so hießen die Steam-Boxen später, wenn ich mich recht erinnere, fit für Windows Games zu bekommen. Valve stieg groß in die Wine-Entwicklung ein, die ansonsten hauptsächlich von Cedega (einer Firma, die kommerziell eine Wine-Version vertrieb) und freien Entwicklern vorangetrieben wurde.
Die Geschichte zeigt, dass die Steam-Machines nie wirklich abhoben. Zu wenig Anbieter, zu viel FUD durch Microsoft und zudem noch der Nackenschlag, dass MS zurückruderte und man Anwendungen auch weiterhin am MS-Shop vorbeiinstallieren konnte und auch Kombi-Launcher (wie Steam) kein Problem (mehr) wären.
Valve war in einer Zwickmühle. Alles wieder einstampfen? Würde die neue Community, die sich auf den Steam-Launcher für Linux gestürzt hatten, massiv verprellen und auch Publisher, die jetzt DOCH Aufwände in die Steam-Runtime/Linux-Kompatibilität gesteckt hatten, aus Steam vertreiben. (Denn den MS-Store gab es ja jetzt und jede Abwanderung war ein Verlust.) Weiter volle Kraft und Geld verlieren? Geht auch nicht.
Also stampfte man die Steam-Machines ein. Lediglich der Remote Play-Client blieb, womit man selbst auf einem RasPi von einem entfernen, großen/lauten PC aus dem Arbeitszimmer im Wohnzimmer spielen konnte. Und aus den Anpassungen, die Valve für Steam an Wine für jede eigene Version ihrer Runtime stricken musste, wurde "Proton". Die Abgrenzung war nötig, denn Cedega und die Wine-Community kamen mit den Änderungen nicht hinterher. Für die ganzen Hacks der Spiele, die es auch ohne das Steam-Universum gab, wurde ja weiter daran gearbeitet, das Zeug Linux-fähig zu bekommen. Und es kamen immer mehr Interessierte dazu, die ein paar Fixes einpflegen wollten, die aber wieder andere Spiele kaputt machten.
So entstand auch "Lutris". - Sowohl Proton als auch Lutris sind Modifikationen der Basis-Wine-Version, um jeweils die dafür gedachten Spiele/Programme besser nutzen zu können. Bei Lutris bedarf es des Lutris-Launchers. Im Prinzip einer Weiterentwicklung des weitestgehend eingeschlafenen "PlayOnLinux". - Welches wiederrum im Prinzip zu Beginn der Versuch war, je Anwendung die sonst individuell nötigen Schritte (wie eine Installation von zusätzlichen Schriftarten, Decodern oder sonstigem Kram, den Windows ggf. haben könnte, der in einer "leeren" Wine-Konfiguration aber nicht vorhanden ist), die man sonst einzeln mit "winetricks" abwickeln muss, zu automatisieren.
Schwierig wurde es aber wieder, als Microsoft erst DirectX11 - eigentlich Microsofts LETZTER Direct-X-Version - und später - wegen dem penetranten Nicht-Stillhalten von AMD mit seinem "Mantle" - DX12 forcierte und mit dem Ende von Windows XP nach und nach - spätestens mit dem Ende von Windows 7 - der Support für DirectX9 entfiel und die Hersteller auf neuere DX-Versionen setzen MUSSTEN. War DX10 - eingeführt mit Vista - weitestgehend obsolet, war DX11 doch eine echte Weiterentwicklung von DX9 und mit seinen deutlich mächtigeren Shadern ein Schritt nach vorn. Leider: Diese Shader ließen sich nicht wie DirectX9 vergleichbar einfach in OpenGL umsetzen. Teilweise war direkter Zugriff zur Grafik-Hardware nötig. Und der war via OpenGL schlicht unmöglich. Zum Glück war aber AMD nicht mit DirectX11 glücklich. Im Prinzip hatten sie es selber verbockt. Der eigene Treiber war in DX11 bei gleicher technischer Leistungsfähigkeit der Hardware nVidia unterlegen. Die bislang wenig relevanten "Zeichnen!"-Aufrufe je Sekunde schossen bei der jetzt möglichen Hardware in die Höhe. Blöderweise war der Treiber nicht darauf ausgelegt und AMD hätte Jahre gebraucht, das Ding von Grund auf neu zu konzipieren. - Zumal die Technik das alles konnte. Also setzte man sich bei AMD ins Kämmerlein und prototypisierte eine neue Schnittstelle, die nicht mehr wie ein dickes Daunenbett mit vielen Schichten über der Grafikkarte liegen (und mit jeder Schicht CPU-Leistung fressen) sollte, sondern deutlich näher an der HW dran sein. - Ähnlich wie ein dünner "Mantle", der die Hardware eng umschlingt und trotzdem vor Ungemach schützt, wo nötig.
Microsoft war "not amused", wie die Queen sagen würde. Eine Schnittstelle, die MS nicht unter Kontrolle hatte? So wie OpenGL damals, bis man es ENDLICH weitestgehend von der Plattform bekam? Zumal von nVidia Feuer gemacht wurde, solche Auswüchse zu unterbinden. Denn auf einmal waren die AMD-Karten konkurrenzfähig. So biss also bei MS dann doch wieder jemand in die Tischkante und die Entwicklung von DX12 begann. - Kurz nachdem AMD die Mantle-Spezifikationen an die Chronos-Group - die Jungs, die bisher über die Weiterentwicklung von OpenGL wachten - übergab, die das Baby "Vulkan" nannten.
Damit sind wir so ziemlich in der Gegenwart. Denn Dank Vulkan ist es möglich, die Grafikkarten ähnlich Hardware-nahe (und performant) zu betreiben, wie unter DX12 auch. Und ältere Versionen von DirectX erst Recht. So konnte es passieren, dass Spiele, die via DirectX11 mittels dem Hilfstool "dxvk" (DirectX to Vulkan) letztlich auf Linux schneller als unter Windows laufen. Unter den Linux-Entwicklern geht ja sogar die Idee herum, selbst OpenGL nicht mehr als grundlegenden Code zu entwickeln, sondern ähnlich wie bei DirectX über Vulkan umzusetzen. Denn die Treiber sind neu. Altlasten müssen sie nicht berücksichtigen. Die Hardware ist klar abgegrenzt.
Für alte Spiele (DirectX9/10 und älter) weigerten sich die Wine-Entwickler aber lange, DXVK zu nutzen. Denn: Die bisherige Umsetzung war lang erprobt, die meisten Fehler behoben. Das alles würde man sich mit DXVK9 wieder einreißen. Und die Geschwindigkeitsvorteile bei ALTEN Spielen ist i.d.R. nicht relevant. Die Hardware hat genug Dampf, es auch so zu können. Außerdem: Alte Software läuft oft auf alten Systemen. Was ist, wenn die HW - ähnlich wie die Therm... äääh Fermi-Generation (und frühere) von nVidia und alles vor den Southern Islands bei AMD - gar kein Vulkan kann? Es entstand DXVK9. Lange parallel gepflegt, bis man sich doch entschied, mit Wine 4.irgendwas DXVK nicht mehr als Modul sondern als Kernbestandteil zu implementieren und mit Wine 5 dann auch DirectX9 und Co über Vulkan zu realisieren. (So kann es passieren, dass ein Spiel, dass auf einem PC unter Windows geht und unter Linux ging, es heute nicht mehr läuft. Die Hardware kann kein Vulkan. - Herzlichen Glückwunsch.)
Und wer bis hier hin noch nicht eingschlafen ist, darf sich noch nen Keks nehmen und dann aber Zähneputzen und ab ins Bett!
Regards, Bigfoot29
