Schlagwort-Archive: Emulation

Eines meiner heiligsten Prinzipien bei der Entwicklung meines Remakes von Spacola ist Authentizität. In dieser Hinsicht bin ich leider ein Perfektionist. Zumindest so weit es mir technisch möglich ist, versuche ich mich immer zu 100% an den Originaldateien und an Originalmechanismen zu orientieren, und ich weiche nur davon ab, wenn es absolut nötig, wirklich sinnvoll, oder mit meinem Know-How sonst nicht machbar ist. Zu Beginn der Entwicklung konnte ich lediglich rein aus der Beobachtung nachimplementieren, ich musste notgedrungen tausende selbsterstellte Screenshots verarbeiten und Tonaufnahmen aus dem Emulator aufnehmen. Das Ergebnis war natürlich oft nah am Original dran, aber für mich nie authentisch genug. Glücklicherweise habe ich mittlerweile so einige Fortschritte gemacht, die mir meine Mission deutlich erleichtern. In den vergangenen Wochen habe ich einen äußerst wichtigen Meilenstein bei der Analyse des Originalspiels erreicht. Um verstehen zu können, was mir da konkret gelungen ist, muss ich etwas weiter ausholen. Daher hier ein kleiner technischer Exkurs in meine Welt.

Schon wie zuvor im 1990 veröffentlichten OXYD hat Spacola einen eigenen Kopierschutz in Form eines Dongles (das Codebuch). Im Gegensatz dazu sind die Codes allerdings mittlerweile ein integraler Bestandteil des Gameplays geworden, und nicht mehr nur Steine, die den Weg blockieren. Den Kopierschutz schlicht auszubauen hätte im einfachsten Fall bedeutet, direkt das Gameplay von Spacola zu verändern, die Siegbedingungen im Spiel zu entfernen; das Spiel wäre quasi sinnlos geworden. (Spoiler-Warnung: Dennoch ist einem findigen Entwickler vor wenigen Jahren auch das schon auf intelligente Weise gelungen.) Weiterhin bringt das Spiel jedoch noch einen raffinierten Crackschutz mit, um zu verhindern, dass der Kopierschutz überhaupt angegriffen werden kann. Die Daten der Dongleware-Spiele bis einschließlich OXYD lagen noch offen da, wenn auch in proprietären Dateiformaten (SHL, IMG, CMP, PAC), mit denen man so jedenfalls nichts anfangen konnte, bis auf die Sounddateien, die einfach im Rohformat vorhanden waren. Da OXYD schließlich geknackt werden konnte (und auch das Codebuch trotz absichtlich schlechtem Farbkontrast kopiert wurde), wurden die Daten in Spacola inzwischen gegen unbefugte Zugriffe geschützt. Dies macht es natürlich für interessierte Remake-Entwickler wie mich deutlich schwieriger, die eigentlich nicht den Kopierschutz entfernen wollen, sondern Einblick in die Spieldaten brauchen.

Wie sieht dieser Crackschutz nun eigentlich aus? Bei Spacola lagen weder die Spieldaten noch die ausführbare Datei in lesbarer Form auf der Diskette vor. Auf dieser gab es lediglich ein großes mit PFXPak erstelltes, selbstextrahierendes Programm, das das Spiel zur Laufzeit ausschließlich in den Arbeitsspeicher entpackt und dort ausführt. Laut PFXPak-Dokumentation bringt das nicht nur den Vorteil, dass man mehr nutzbaren Netto-Speicherplatz auf der Diskette hat, sondern auch Performance-Verbesserungen, da weniger Daten über das langsame Diskettenlaufwerk geladen werden müssen. Außerdem werden zum einen die einzelnen Dateien immer erst dann entpackt, sobald sie vom Programm referenziert, also im Spiel benötigt werden, zum anderen werden die Dateien auch gleich noch dekodiert, da sie teilweise nur in verschlüsselter Form vorliegen. Und selbst das ist noch nicht alles: Sogar wer glaubt, es sei ihm gelungen, das integrierte LHarc-Archiv des Entpackers aus der Datei zu extrahieren, und dieses von Hand entpacken will, erhält leider kein Spacola, sondern nur ein Programm, das eine kleine Grußbotschaft an den Hacker auf dem Bildschirm anzeigt und gleichzeitig die Festplatte vollmüllt, sofern eine angeschlossen ist. Ja, man musste sich als Spieleentwickler wohl irgendwie gegen Raubkopierer zur Wehr setzen. Der wenig freundliche Inhalt besagter Grußbotschaft wurde mit dem ersten und wahrscheinlich einzigen Spacola-Patch einige Wochen später zensiert.

Wer sich mit Atari ST-Emulation intensiver befasst, weiß, dass es mit dem STeem Debugger ein äußerst mächtiges Debugging-Werkzeug gibt, das genutzt werden kann, um sämtliche ST-Software zu analysieren und zu modifizieren. Fürs Reverse-Engineering ist ein brauchbarer Debugger quasi unverzichtbar. Als ich vor etlichen Jahren zum ersten Mal die Oberfläche des Debuggers öffnete, war ich wie erschlagen von den endlosen Möglichkeiten, die sich mir hier boten. Und mir war sofort klar, dass ich nicht die nötigen Fähigkeiten hatte, um hier irgendetwas zu bewegen, denn natürlich setzt so ein Debugger unter anderem auch ein tieferes Verständnis der Hardware voraus. In meinem Studium hatte ich wenigstens zwei Semester Rechnertechnik, in welchen ich die Grundlagen von 68K-Assembly lernte und auch sehr kleine Programme schrieb. Dies brachte mich zumindest theoretisch in die Lage, die Funktionen des Debuggers rudimentär zu verstehen. Doch als ich mich damals spaßeshalber in ein laufendes Programm einklinkte, Schritt für Schritt durch den Programmcode bewegte, und die Hieroglyphen verstehen wollte, die der Prozessor da ausführte, hörte der Spaß irgendwie auf. Mein Verstand konnte zwar mühsam und sehr langsam erfassen, was dort in jeder Zeile ausgeführt wurde, aber mir fehlte jeglicher Durchblick dafür, warum es ausgeführt wurde, an welcher Aufgabe der Programmcode gerade arbeitete. Es gab keinen Kontext. Es ist ein bisschen so als würde ich mir unter einem Mikroskop nacheinander die einzelnen Holzfasern genauer anschauen, um dadurch herausfinden zu wollen, worum es in dem Buch geht. Dabei könnte ich nicht einmal erkennen, welchen Buchstaben ich mir da gerade ansehe.

Der STeem Debugger mit laufendem Spacola beim Ladevorgang

Aber die ersten kleinen Fortschritte ermutigten mich, den Kopf nicht hängen zu lassen. Der Memory-Browser des Debuggers bietet zum Beispiel eine Suchfunktion und erlaubt das Editieren des Speichers zur Laufzeit. So kann man Texte in den Programmen finden und ersetzen, was nette Spielereien ermöglicht. Eine andere nützliche Funktion ist der Speicherdump, der es erlaubt, den kompletten Arbeitsspeicher in eine Datei zu schreiben. Mit diesem wertvollen Hilfsmittel hatte ich endlich einen ersten direkten Zugang zu vielen Spielinhalten, wenn es auch noch lange nicht lückenlos war. Im Audiobearbeitungsprogramm Audacity konnte ich dieses Speicherabbild als Rohdaten einlesen und die Sounds von Spacola hörbar machen und grob „ausschneiden“, was mir wirklich enorm half. Eines meiner Probleme mit dieser Methode war jedoch, dass ich nie wusste, wo eine Datei beginnt oder aufhört. Die Dateien waren nicht byteperfekt. Und jahrelang waren die Audiodateien leider die einzigen, auf die ich dadurch Zugriff erlangen konnte. Ich wollte aber unbedingt auch an die Grafikdateien herankommen. Später gelang es mir mit großem Aufwand, das „Rentenbescheid“-Bild, das nach gewonnenem Spiel als Urkunde zum Ausdrucken verwendet wird, zu extrahieren. Die Monochrom-Rohdaten habe ich unter anderem durch einen emulierten Drucker als virtuelle Hardcopy in eine Datei schreiben lassen, mühsam rekonstruiert und mit STAD v1.3 laden können. Dadurch konnte ich einen Screenshot anfertigen. Dies war ein weiterer Motivationsschub, der mich daran glauben ließ, irgendwann alles zu schaffen.

Ende 2018 begann ich erneut damit, das Originalspiel aufwändig Schritt für Schritt im Debugger zu beobachten. Ich hatte erst angefangen, mich mit den Breakpoints und den Read- und Write-Monitors vertraut zu machen, und war überzeugt davon, ich könnte die entpackten Dateien abfangen, während sie gerade in den Arbeitsspeicher geschrieben werden. Im selbstextrahierenden Programm gibt es glücklicherweise eine Dateitabelle, die Dateinamen, Dateigrößen und Byte-Offsets enthält. Dies war letztlich der Schlüssel zum Erfolg. Jemand mit mehr Erfahrung im Reverse-Engineering hätte natürlich sofort gewusst, was hier zu tun ist. Ich musste es erst durch unzählige Fehlversuche und Rückschläge lernen. Am Ende dauerte es bis zum Frühjahr 2020, dann hatte ich endlich einen Plan. Durch das geschickte Setzen der Read- und Write-Monitors und Zurückverfolgen der Lese- und Schreibzugriffe, konnte ich genau den Teil des Codes ausmachen, der direkt für das Entpacken aller Dateien zuständig ist. Anschließend musste ich nur noch den Program Counter, die Schleifendurchläufe und die Adress- und Datenregister überwachen, dadurch konnte ich sehen, welche Datei gerade verarbeitet wurde, wo die Daten gelesen und wohin sie geschrieben wurden, und wann der Schreibvorgang exakt beendet ist. Ich führte Notizen darüber, welche Dateien ich dadurch erhalten konnte und ob sie die richtige Größe haben, um ihre Richtigkeit zu verifizieren.

Das Debugging beim Entpacken der Dateien

Das Modifizieren der Dateitabelle im Programm erlaubte es mir sogar, den Entpacker dazu zu bringen, die „falschen“ Dateien zu entpacken, darunter auch eine Sounddatei, die offenbar gar nicht referenziert, also im Spiel selbst niemals verwendet wird. Dies war immens hilfreich und verkürzte die weitere Zeit, um auch die letzten verbliebenen Dateien zu bekommen. Später bemerkte ich noch, dass Spacola leider wieder mal schlauer war als ich: Viele Sounddateien wurden im Spiel komprimiert, d.h. in der Größe reduziert, andere Sounddateien wurden aber nur in irgendeiner Weise kodiert, also bei gleicher Dateigröße unlesbar gemacht. Hierzu musste ich einen weiteren Codeabschnitt ausfindig machen, der Sounddateien entschlüsselt. Die zentralen Breakpoints waren mir in der Folge heilig, ich habe sie akribisch notiert und verwendet, um nacheinander alle 104 Dateien mühsam zu entpacken, aus dem Memory-Browser zu extrahieren und mittels HEX-Editor byte-perfekt auf die Festplatte zu schreiben. Das Ergebnis sind 557 KByte an Rohdateien, die exakt so im Originalspiel verwendet werden: 50 Sounddateien, 48 Sprite-Dateien, vier Bilddateien, eine Textdatei und eine IMG-Datei. Als Bonus erhielt ich auch die ungeschützte SPACOLA.PRG, also die ausführbare Datei ohne den Packer. Diese lässt sich auch starten und lädt sogar das Titelbild, anschließend hängt sie sich leider auf. Allerdings habe ich mich entschlossen, dieses Problem nicht weiter zu verfolgen, da es sich wahrscheinlich nicht lohnt.

Für mich war das bis hierhin schon ein großartiger Durchbruch. Dies war ein Thema, das mir noch Jahre zuvor wie eine unlösbare Aufgabe erschien, und plötzlich liegen mir alle Daten offen, um sie endlich in unberührter Form in meinem Remake zu verwenden. Aber da war natürlich weiterhin diese eine nicht ganz unbedeutende Hürde: Das selbstentwickelte Dateiformat der Sprite-Dateien ist leider unbekannt, undokumentiert und es gibt kein öffentlich verfügbares Programm, das die Dateien lesen könnte. Scheint so, als sei ich in einer Sackgasse gelandet.

Und in der nächsten Folge lesen Sie: Die Sprites von Spacola.

Eine seltsame, geradezu verschrobene Person wie ich, die mit ihren Gedanken sowieso bei jeder Gelegenheit in der Vergangenheit ist, ständig der Vergangenheit nachhängt, ihr beinahe nachweint, verbringt auch übermäßig viel Zeit damit, nach Wegen zu suchen, die Vergangenheit für sich zu erhalten. Und die Nostalgie ist stark in mir. Praktisch schon als Jugendlicher wurde ich regelmäßig nostalgisch gegenüber sämtlichen Dingen, die ich aus der (damals noch gar nicht so lange zurückliegenden) Kindheit kannte. Das betrifft das übliche Spektrum typisch nostalgiegeladener Dinge von Spielsachen, Zeitschriften, TV-Serien, über Personen, alte Schulsachen, Musik, bis hin zu Orten, Snacks und Süßigkeiten, und in meinem Fall eben auch ganz besonders: Computer, Computerspielen und anderer Software.

Schon in den späten 90er Jahren befasste ich mich durchgängig mit Emulatoren für den Atari ST, den Amiga, den C64, sowie sämtlichen beliebten Spielekonsolen meiner Kindheit, bastelte an Konfigurationen und verwendete gerne Programme und Spiele, die praktisch als ausgestorben galten. Allein die Vorstellung, für mich wichtige veraltete Hardware auf einem einzigen modernen Notebook bzw. Rechner zu vereinen, komplett mit einer umfangreichen Softwarebibliothek, jederzeit auf Knopfdruck abrufbar, erfüllte mich mit einem wohligen Gefühl. An diesem kleinen Traum arbeite ich praktisch seit Jahrzehnten. Und die technischen Möglichkeiten werden von Jahr zu Jahr besser, weil die Prozessoren immer leistungsfähiger und die Festplatten immer größer werden.

Während ich etwa das Feld der Amiga- und Atari ST-Emulation, sowie der meisten Spielekonsolen von vor 1994 weitestgehend abgearbeitet und durchleuchtet habe, kam vor knapp 15 Jahren ein weiteres großes Thema auf meiner Agenda hinzu: PC-Emulation. Dabei mag es vordergründig zunächst schwachsinnig klingen, einen PC auf einem PC emulieren zu wollen. Doch so unlogisch ist das nicht. Der PC als Plattform ist mittlerweile so alt, ausdauernd und langlebig, dass er viele Äras und Iterationen von Hardwarestandards und Betriebssystemen durchlebt hat. Das ist zwar eigentlich fast überall so, aber nirgends waren die Schritte so groß wie hier: Die Spanne reicht mindestens von den ersten x86-Prozessoren in den IBM PCs von Anfang der 80er mit MS-DOS, über den 486ern, Pentiums, dem K5 und z.B. den Cyrix-Prozessoren Mitte der 90er mit Windows 3.x/Windows 95, bis hin zu deutlich modernerer Hardware wie Mehrkernprozessoren und vollständig multitasking- und multiuserfähiger Betriebssysteme wie Windows XP/Vista/7/8/10 und Linux. Und dabei habe ich nur einen ganz groben Querschnitt aufgezählt. Diese sich permanent verändernde Umgebung innerhalb der Plattform bringt es mit sich, dass Software, die beispielsweise heute noch tadellos läuft, morgen schon nur noch eingeschränkt mit Tricks zum Laufen gebracht werden kann, während sie übermorgen wegen Hardwareinkompatibilitäten und weggefallener Betriebssystemstandards überhaupt nicht mehr startet, und das ist nur völlig natürlich und irgendwo auch notwendig, denn manchmal müssen alte Zöpfe zum Wohl des Fortschritts abgeschnitten werden. Das haben wir bei Spielen und Programmen unter MS-DOS beobachtet, danach mit 16-Bit-Windows-Software, die heute garantiert nirgends mehr läuft, und inzwischen gehen auch 32-Bit-Programme allmählich unter. Gegensteuern kann man hier nur mit Kompatibilitätschichten, Virtualisierung und Emulation.

PC-Virtualisierung bzw. -Emulation gibt es schon sehr viel länger als ich mich damit befasse. „Bochs“ gibt es seit 1994 und „QEMU“ immerhin seit 2003. Mit beiden bin ich leider nie besonders gut klargekommen, sie sollen aber, in den richtigen Händen, äußerst leistungsfähige Werkzeuge sein. Bei den Virtualisierern erprobe ich VMware, VirtualBox und Virtual PC schon seit langem. Letzteres fand sogar in Form des vorkonfigurierten „Windows XP-Modus“ einst offiziell seitens Microsoft Einzug in Windows 7, um erwartete Kompatibilitätsprobleme zumindest abzufedern. Mit „DOSBox“ gibt es seit 2002 einen Emulator, der einen typischen DOS-Rechner mit allen Schikanen nachstellt, und der speziell für Spiele optimiert wird. Dieses kleine aber äußerst kräftige Tool ist so gut, dass es von Spieledistributionsplattformen wie GOG offiziell verwendet wird, um die Nutzung sämtlicher DOS-Spiele unter modernen Betriebssystemen zu ermöglichen. DOSBox emuliert den PC heute so akkurat und schnell, dass man im emulierten DOS sogar Windows 95 installieren und darunter Spiele spielen kann – leider mit diversen technischen Einschränkungen.

Soviel also zur Einleitung. Vor wenigen Monaten entdeckte ich eher zufällig einen weiteren Mitstreiter auf dem Gebiet der PC-Emulatoren: PCem. Dieses Programm ist vereinfacht gesagt das Windows-Gegenstück zu DOSBox, wenn auch noch lange nicht auf Windows beschränkt. PCem emuliert grundsätzlich eine ganze Vielzahl von alten Mainboards, Prozessoren, Grafikkarten, selbst einst beliebte 3D-Beschleuniger wie Voodoo und Voodoo2. Entsprechend lassen sich damit die allerersten PCs, bis hin zu PCs der Pentium MMX Ära emulieren. Die akkurate Low Level Emulation fordert jedoch ihren Tribut, so benötigt man zur Nachbildung meines damaligen 200 MHz Pentiums von 1997 heutzutage über den Daumen gepeilt knapp 4 GHz Taktrate auf einem einzelnen Kern, denn selbstredend lässt sich die Emulation eines Singlecore-Prozessors nicht einfach auf mehrere Kerne aufteilen. Das ist also mal eben das 20-fache an Leistung.

Das beste an PCem ist, dass er mit dem Ziel entwickelt wird, Spiele perfekt zu unterstützen, also einer der hardwareforderndsten Formen von Software, was mich insgesamt sehr begeistert hat. Wenn man den Gerüchten glauben durfte, soll die Voodoo2-Emulation inzwischen so brauchbar sein, dass hardwarebeschleunigte 3D-Spiele aus der Zeit kurz vor der Jahrtausendwende mit Abstrichen problemlos spielbar sein sollen. Dies wollte ich unbedingt selbst testen und so versuchte ich mich einmal an einer kleinen Demo-Installation, die einen halben Tag in Anspruch nahm.

Ich will hier an dieser Stelle bewusst nur einen Erlebnisbericht und kein Tutorial schreiben, weil die Installation leider relativ aufwändig ist, und es schon diverse brauchbare Anleitungen im Internet gibt. Der Aufbau einer lauffähigen Konfiguration in PCem ist nicht sehr intuitiv im Gegensatz zu DOSBox oder VirtualBox, aber die Mühe lohnt sich. So ist PCem nach der Installation leider völlig nutzlos, benötigt er doch eine ganze Reihe an BIOS-Dateien für die ganze Hardware, die man haben möchte. Die Verwendung derselben ist wohl nur so halblegal, die entsprechenden Dateien lassen sich aber an vielen Ecken finden. Hat man diese Hürde überstanden, darf man seinen emulierten Pentium zum ersten Mal einschalten und findet eine nicht bootfähige, unformatierte Festplatte vor. Nach einigen Fehlversuchen gelang es mir schließlich tatsächlich, mit Hilfe mehrerer Bootdisketten und meiner eigenen CD ein taufrisches Windows 98 SE zu installieren, das auch fehlerfrei bootete. Die größte Zeit aber beanspruchte die nervenaufreibende Schnitzeljagd im Internet nach Treibern für die SoundBlaster 16, der Voodoo2-Karte und DirectX 7.0, zudem generische Maus- und CD-ROM-Treiber, die ich ganz klassisch in die CONFIG.SYS und AUTOEXEC.BAT einpflegen durfte. Oh wie lange ich diese beiden Dateien schon nicht mehr gesehen habe. Nostalgie pur!

Das Betriebssystem machte einen stabilen, schnellen und vor allem makellosen Eindruck, im Gegensatz zu so mancher gleichförmiger Installation unter VMware Workstation, die mit Windows 9x oft schon beim Sound überfordert schien. Aber ich wollte mein neues altes System definitiv einer Feuerprobe unterziehen und beschloss daher, einen Klassiker aus meinen alten Tagen zu installieren, den ich wirklich sehr gerne und sehr lange gespielt habe: Need for Speed III: Hot Pursuit.
Die Installation von CD-Image verlief in PCem ausgesprochen gemütlich, und das Spiel startete schließlich (nach Korrektur der Hardwarekonfiguration und Installation noch fehlender Treiber) sogar ohne weitere Schwierigkeiten und plötzlich lief das actiongeladene Introvideo von NFS3 – fast ohne Ruckler. Eigentlich hatte ich erwartet, dass das Spiel mir zunächst via Dialogbox meldete, dass ich doch bitte die CD einlegen solle, so wie das früher (durch den CD-Kopierschutz) bei gebrannten Datenträgern ein generelles Thema war. Aber möglicherweise ist auch das in PCem gar kein Problem mehr.

Nun, was soll ich sagen. Schon kurz darauf drehte ich meine ersten paar Runden in der Corvette über meine Lieblingsstrecke, den Gebirgspass, in gnadenlosen Rangkämpfen gegen Lamborghinis, Ferraris, Aston Martins und anderen Sportwagen, teils auf der Flucht vor der Polizei, teils auch nur gegen die Zeit. Anfangs noch ein wenig wackelig mit etlichen Kollisionen, gewann ich mein altes Fahrgefühl bald wieder zurück und ehe ich mich versah, driftete ich wie vor über 20 Jahren mit Begeisterung in die Kurven, gab Vollgas auf den Geraden, versuchte die perfekten Bremspunkte zu finden, und schlängelte mich zwischen den gegnerischen Boliden hindurch auf dem Weg an die Spitze des Fahrerfeldes. Die Kompatibilität ist wie erwartet einwandfrei, es gibt keine Fehler oder grafische Glitches. Die Performance ist auf meiner Kiste nicht bahnbrechend, aber ausreichend schnell. Für die Standardauflösung des Spiels von 640×480 reicht es allemal, mehr ist nicht zu empfehlen. Die größte Schwierigkeit hierbei wird sein, dass die 3D-Beschleunigung paradoxerweise in Software emuliert wird, und so natürlich keine Vorteile von der Leistungsfähigkeit der physischen Grafikkarte erfährt. Dennoch gibt es spürbare Performanceverbesserungen durch den Einsatz der Voodoo2-Schnittstelle im Gegensatz zum Software-Renderer.

Die Demonstration war für mich ein voller Erfolg, vielleicht nicht komplett repräsentativ, aber in jedem Fall sehr beeindruckend. PCem erlaubt keine Festplatten-Snapshots wie bei Virtualisierungssoftware üblich, aber meine perfekt eingerichtete, unberührte Konfiguration habe ich für die Zukunft weggesichert und werde auf diese künftig regelmäßig zurückgreifen. Auch erwarte ich weitere Verbesserungen durch die jährlich erscheinenden, neueren Versionen von PCem, so dass das Retro-Spielvergnügen immer besser wird und auch die mit ziemlicher Sicherheit existierenden Grenzfälle unterstützt. Mal sehen welches Spiel ich als nächstes installiere. Vielleicht Interstate ’76. Es sollte jedenfalls ein echter Problemfall sein, der heute nur noch sehr schwer lauffähig gemacht werden kann.

Nach anfänglichen Zweifeln vor etlichen Jahren ob wir jemals in der Lage sein würden, die früheren Windows-Spiele (ab circa 1993 bis Anfang der 2000er) jemals lückenlos in spielbarer Form zu bewahren, abseits natürlich vom Weiterbetrieb der echten Legacy-Hardware, bin ich nun überzeugt, dass für Retrogamer wie mich endlich goldene Zeiten anbrechen. Mit DOSBox, PCem, VirtualBox, VMware und diversen anderen Lösungen, die glücklicherweise allesamt nicht nur für Windows sondern auch Linux und mitunter anderen Plattformen verfügbar sind, dürfte die sich stetig verbessernde Kompatibilität endlich flächendeckend ermöglichen, auch hartnäckige Fälle von Spielen perfekt spielbar zu machen und somit vernünftig zu erhalten. Und natürlich muss man sich auch nie wieder Sorgen über eine ewige Abhängigkeit von Windows machen, denn egal ob Spiele für DOS, Windows 95/98 oder XP: Heute läuft endlich (fast) alles überall. Und hey, mit Wine und Proton sind wir sogar schon für die Spiele danach wirklich gut aufgestellt, mit unzähligen Optimierungen und Verbesserungen, die monatlich dazukommen. Wahrlich goldene Zeiten sind das.