Der Master-Disk-Fehler von Space Quest II

 (lanceewing.github.io)
1 Punkte von GN⁺ 2024-05-24 | 1 Kommentare | Auf WhatsApp teilen
  • Auf Space Quest II 2.0D/2.0F 720KB Disk 1 von Sierra On-Line befand sich noch Quellcode des AGI-Interpreters, der in der Dateiliste nicht sichtbar war; ein Fehler bei der Vorbereitung der Master-Disk wurde unverändert auf kommerzielle Disketten kopiert
  • Beim Löschen von Dateien unter DOS FAT werden die Daten nicht entfernt, sondern die Sektoren nur als unbenutzt markiert. Wird eine nicht formatierte Diskette als Master verwendet, können frühere Daten auf alle Kopien mitwandern
  • Im 402.432 Byte großen „freien“ Bereich von Disk 1 befand sich statt des Format-Füllwerts 0xF6 noch C-/Assembler-Quellcode; bei der Extraktion wurden 93 Dateien, mehr als 15.000 Zeilen und rund 70 % des AGI-Interpreter-Quellcodes gefunden
  • Da die FormMaster-Kopiergeräte nicht dateiweise kopierten, sondern alle Sektoren der Diskette bytegenau, könnten auch gelöschte Daten, die in der tatsächlichen Dateiliste nicht auftauchten, auf Disketten für Kunden und Händler gelangt sein
  • Dieser Fehler aus dem März 1988, gegen Ende der AGI-Ära, blieb verborgen, bis NewRisingSun im Oktober 2016 die erste bekannte Entdeckung machte; 36 Jahre später wurde er zu digitalarchäologischem Material für einen Blick in Sierras AGI-Implementierung

Spuren, die in der Dateiliste nicht sichtbar waren

  • Die 720KB-Disketten der Space-Quest-II-Versionen 2.0D und 2.0F wirkten äußerlich unauffällig, und auch die Dateiliste sah wie bei einer typischen Sierra-Spielediskette aus
  • Im Verzeichnis von 2.0D gab es keine verdächtigen Zusatzdateien; wichtige Datendateien wie PICDIR, LOGDIR, VIEWDIR, SNDDIR, VOL.0 und VOL.1 wurden am 14. März 1988 erstellt
  • Die .OVL-Dateien tragen Zeitstempel vom 15. März 1988, der AGI-Interpreter-Code vom 18. März 1988; das zeigt Spuren davon, dass die Vorbereitung von Space Quest II 2.0D in Sierras Büro über eine Woche lief
  • Der belegte Speicherplatz der Diskette wurde mit 302.918 Byte angegeben, der „freie“ Speicherplatz mit 402.432 Byte – der leere Bereich war also größer als der belegte

Der unbenutzte Bereich im Hex-Editor

  • Auf einer unter DOS frisch formatierten Diskette sind unbenutzte Sektoren normalerweise mit dem Format-Füllwert 0xF6 gefüllt
  • Bei Disk 2 von Space Quest II 2.0D waren die unbenutzten Sektoren mit 0xF6 gefüllt, auf Disk 1 gab es jedoch keinen einzigen unbenutzten Sektor mit 0xF6-Füllung
  • Die längste Folge zusammenhängender 0xF6-Bytes auf Disk 1 war nur 2 Byte lang; obwohl mehr als die Hälfte des Speicherplatzes als „frei“ galt, waren tatsächlich noch frühere Daten vorhanden
  • In dem als unbenutzt markierten Bereich befand sich Text, der wie C-Quellcode aussah; das deutet stark darauf hin, dass diese Diskette vor ihrer Verwendung als Master für Space Quest II Disk 1 anderweitig genutzt worden war
  • Im DOS-FAT-Dateisystem entfernt das Löschen einer Datei die eigentlichen Daten nicht, sondern markiert die Sektoren nur als wiederverwendbar; solange keine neuen Dateien darübergeschrieben werden, bleibt der frühere Inhalt erhalten

Zurückgebliebener Quellcode des AGI-Interpreters

  • Beim Extrahieren des ASCII-Texts aus dem unbenutzten Bereich wurden C-Funktionen wie DisplayStatusLine und StatusLineOn gefunden
  • DisplayStatusLine ist Code, der eine Textzeile mit aktuellem Punktestand und Sound-On/Off-Status anzeigt, und hängt mit der weißen Statusleiste am oberen Rand des Space-Quest-II-Bildschirms zusammen
  • Dieser Code gehört nicht zu den Spieldaten, sondern zum AGI-Interpreter selbst von Sierra
  • In den unbenutzten Sektoren steckte eine große Menge Quellcode; da der Code in aufeinanderfolgenden Sektoren gespeichert war, ließ er sich relativ einfach extrahieren und in einzelne Dateien aufteilen
  • Am Anfang jeder Datei standen Kommentare mit dem Namen der Quelldatei, wodurch die Trennstellen leicht zu finden waren; die Aufteilung ergab insgesamt 93 Dateien
    • 75 C-Quelldateien
    • 16 Assembler-Quelldateien
    • 2 DOS-BAT-Dateien
  • Der gesamte Code umfasst mehr als 15.000 Zeilen, und die meisten Dateien lagen vollständig vor
  • Auf dieser Diskette befanden sich rund 70 % des Quellcodes von Sierra On-Lines AGI-Interpreter, einschließlich Kommentaren und Änderungshistorie

Änderungshistorie und Spuren der Entwickler

  • Einige Header-Kommentare am Anfang der Quelldateien enthalten eine Change History
  • Der Header von ANIMATE.C enthält den Namen der Quelldatei, eine kurze Beschreibung – „verarbeitet einen Animationszyklus in einem Adventure Game“ – sowie Angaben wie compile: MWC
  • MWC dürfte für den damals häufig verwendeten C-Compiler der Firma Mark Williams stehen
  • Die Änderungshistorie enthält Datum, Uhrzeit, Initialen der Person, die die Änderung vorgenommen hat, und eine Beschreibung der Änderung
  • Unter den Initialen steht JAS für Jeff Stephenson, der hauptsächlich am AGI-Interpreter-Code arbeitete, und DCI für Chris Iden
  • Auch Robert Heitman taucht auf, sein Schwerpunkt lag jedoch auf Grafikwerkzeugen wie Picture Editor und View Editor; Jeff Stephenson und Chris Iden waren vor allem für den Interpreter-Code zuständig

AGI.EXE-Speicherkarte und die 70-%-Berechnung

  • Neben den 93 Quelldateien enthielt Space Quest II 2.0D 720KB Disk 1 auch eine Speicherkarte der ausführbaren Datei AGI.EXE mit mehr als 2.000 Zeilen
  • In veröffentlichten AGI-Spielen heißt die ausführbare Interpreter-Datei schlicht AGI und lässt sich nicht direkt ausführen; während der Entwicklung wurde jedoch ein direkt ausführbarer Interpreter mit der Erweiterung .EXE verwendet
  • Jemand bei Sierra erzeugte am 7. Oktober 1987 eine Speicherkarte von AGI.EXE, also des AGI-Interpreters
  • Dieses Datum passt dazu, dass der neueste Kommentar in der Änderungshistorie des Quellcodes vom September 1987 stammt
  • Die Speicherkarte liefert eine relativ vollständige Übersicht über die Module und Quelldateien, aus denen der AGI-Interpreter besteht
  • In der Speicherkarte erscheinen 98 unterschiedliche Quelldateien; davon liegen 71 Dateien vollständig auf der SQ2-Diskette vor
  • Auf Basis dieses Verhältnisses wurde berechnet, dass sich rund 70 % des AGI-Interpreter-Quellcodes auf der Space-Quest-II-Diskette befanden
  • Einige Module enthalten nur C-Header-Dateien und wurden in diese Berechnung nicht einbezogen

AGI als geistiges Eigentum von Sierra

  • Sierra On-Line befand sich um die Veröffentlichung von King’s Quest im Jahr 1984 in einer geschäftlich schwierigen Lage, und Ken Williams musste etwa 100 Mitarbeitende entlassen, wodurch die Belegschaft von rund 130 auf etwa 30 Personen schrumpfte
  • Der spätere Erfolg des AGI-Adventure-Game-Systems und der darauf entwickelten Spiele trug dazu bei, die Lage des Unternehmens zu verändern
  • Ende 1984 stieg King’s Quest in die Top 20 der Verkaufscharts für Computerspielsoftware ein und blieb bis zur Veröffentlichung von King’s Quest II etwa ein halbes Jahr lang in den Charts
  • Hilfreich war auch die Vereinbarung mit Tandy Radio Shack, durch die Tandy-Versionen der Spiele in Radio-Shack-Filialen verkauft wurden
  • Von 1985 bis 1988 blieben AGI-Spiele Bestseller, und der AGI-Interpreter war für Sierra On-Line eine wichtige Einnahmequelle und zentrales geistiges Eigentum
  • Dass 70 % des AGI-Interpreter-Quellcodes massenhaft kopiert und an Zehntausende oder Hunderttausende Kunden ausgeliefert wurden, war aus Sierras Sicht ein schwerer Fehler

Die Folgen einer nicht formatierten Master-Disk

  • Wenn Sierra eine neue Spielveröffentlichung vorbereitete, erstellte das Unternehmen eine production copy-Master-Diskette für die FormMaster-Diskettenkopiergeräte
  • FormMaster kopierte nicht nur Dateien von der Master-Diskette, sondern alle Sektoren der Diskette bytegenau, unabhängig davon, ob sie als belegt oder frei galten
  • Bei Space Quest II 2.0D und 2.0F Disk 1 wurden durch dieses Verfahren auch die 402.432 Byte mitkopiert, die nicht als tatsächliche Dateien verwendet wurden
  • Bei der Vorbereitung einer Master-Diskette musste die Diskette vollständig formatiert werden, bevor die Spieldateien kopiert wurden; bei den meisten originalen Spieledisketten führte Sierra diesen Schritt korrekt aus
  • Bei Space Quest II 2.0D Disk 1 scheint jemand diesen Formatierungsschritt ausgelassen zu haben, und dieselbe Diskette wurde auch für 2.0F verwendet
  • Dadurch könnten Hunderttausende SQ2-Disketten, die an Kunden und Händler gingen, versteckt 70 % des AGI-Interpreter-Quellcodes enthalten haben

Ein Fall digitaler Archäologie, der erst 2016 bekannt wurde

  • Der Vorfall war mit ziemlicher Sicherheit ein unbeabsichtigter Fehler, und offenbar bemerkten ihn damals weder Sierra noch Wettbewerber oder Kunden
  • Die erste bekannte Entdeckung machte der Online-Nutzer NewRisingSun im Oktober 2016
  • Wichtig ist auch, dass dies gegen Ende der AGI-Ära geschah
    • Im März 1988 hatte Sierra bereits das SCI-Adventure-Game-System entwickelt
    • Das erste Spiel, das SCI nutzte, King’s Quest IV, stand kurz vor der Veröffentlichung
  • Wäre der AGI-Interpreter-Quellcode ein oder zwei Jahre früher versehentlich offengelegt worden, hätte das größere Probleme verursachen können
  • Der extrahierte AGI-Interpreter-Quellcode wurde in ein GitHub-Repository hochgeladen
  • Die Implementierung von AGILE, einem webbasierten AGI-Interpreter, profitierte ursprünglich teilweise vom AGI-Quellcode

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-24
Hacker-News-Kommentare

  • Die DOS-Version von Double Dragon II: The Revenge aus dem Jahr 1989 wurde auf zwei Disketten ausgeliefert, und auf einer davon befand sich der vollständige Quellcode in Form eines gelöschten komprimierten Archivs.
    Im DIR-Befehl war er nicht sichtbar, ließ sich aber leicht wiederherstellen: https://tcrf.net/Double_Dragon_II:The_Revenge(DOS)

    • Es ist immer wieder lustig, wenn man ein ROM öffnet und feststellt, dass Verzeichnis- und Dateinamen aus dem Build-Prozess wortwörtlich ins Silizium eingebrannt wurden.
      Selbst in einer Zeit, in der buchstäblich jedes Byte Geld kostete, ist es schon komisch, dass die FAT-Einträge von Leuten in Cartridges mit eingebrannt wurden.
      https://forums.nesdev.org/viewtopic.php?t=17324
    • Vielleicht ist das eine etwas dumme Frage, aber ich frage mich, wie so etwas überhaupt passiert.
      Man hätte das Spiel doch fertiggestellt, eine Art Master-Diskette erstellt und sie dann an die Massenproduktionsstätte geschickt — wie ist dann ein gelöschtes komprimiertes Archiv auf dem Master gelandet? Vielleicht wurde es versehentlich mitkopiert und vor dem Release wieder gelöscht?
    • Das war mein zweites Multiplayer-Spiel, das ich damals auf dem Computer des Vaters eines Freundes gespielt habe, als ich ihn zu Hause besuchte.
      Das erste war ebenfalls auf demselben Computer eine DOS-Version von Spacewar!. Wenn ich mich richtig erinnere, fror das Spiel beim Boss ein, sodass ich Double Dragon II nie komplett durchspielen konnte, aber ich habe gute Erinnerungen daran

  • In letzter Zeit betreibe ich viel Reverse Engineering von Synthesizer-ROMs.
    Im ROM des Yamaha DX9 befanden sich in freiem Platz im Binärimage Reste einer Firmware-Symboltabelle[0], und außerdem ein größerer Block mit 6303-Code, der vermutlich aus dem Entwicklungssystem stammte. So etwas zufällig zu entdecken, ist wirklich ein erstaunliches Gefühl. Ich war so tief in diesem Thema drin, dass ich mich wie ein Software-Archäologe fühlte, der einen kleinen Blick in die Vergangenheit wirft, und ich bin in einen tiefen Kaninchenbau geraten, um herauszufinden, welche Entwicklungstools Yamaha verwendet hat. Eindeutig belegen konnte ich nichts, aber beim Lesen der Dokumentation damaliger Entwicklungstools ist meine Wertschätzung für moderne Workflows deutlich gewachsen.
    0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...

    • Ich mag Reverse Engineering im Synthesizer-Bereich auch, habe früher einmal einen Yamaha A-sampler analysiert und ein Verwaltungswerkzeug gebaut, mit dem Nutzer von Yamaha-A-sampler-Disketten grundlegende Aufgaben schneller erledigen konnten.
      Mit einem BeBox habe ich viel rohe I/O und rohe Disk-Sektoranalyse gemacht, und BeOS hatte gute Werkzeuge für Dateisystem-Hacking. Dadurch konnte ich einen Dateisystem-Treiber für Windows bauen, der gut genug funktionierte, um sogar Unterstützung von Yamaha zu bekommen. Falls du irgendwann die Motivation hast, Yamaha-ROMs für den A-sampler per Reverse Engineering zu untersuchen, melde dich gern. Ich interessiere mich sehr für diesen Bereich. Die DX9/DX7-Arbeit ist ebenfalls großartig und als jemand, der beide Synthesizer seit ihrer Veröffentlichung benutzt, macht das wirklich Spaß

  • Dieses Spiel hatte in meiner Kindheit ein so enormes Gewicht, dass es sich heute, wenn ich nach so langer Zeit daran denke, fast wie ein Traum anfühlt.
    Wenn ich mir vorstelle, heute noch dieselbe Art von Verbundenheit zu irgendeinem Spiel zu haben, wirkt das unmöglich. Alles um mich herum fühlt sich einfach nur wie ein Spiel, eine Show oder ein Gegenstand an, aber Space Quest 2, 3 und 4 sind mit einem grundlegenden Teil meiner DNA verwoben

    • Space Quest III war mein erstes Sierra-Spiel, und es hat definitiv diese Kraft.
      Sierra-Spiele aus dieser Zeit waren wirklich etwas Besonderes. Besonders Police Quest II, LSL III und Hero's Quest habe ich ungefähr zur gleichen Zeit viel gespielt. Diese textbasierten EGA-Sierra-Spiele hatten etwas Magisches, und für mich waren sie emotional und kreativ genau der richtige Punkt zwischen Infocom und den späteren Point-and-Click-VGA-Versionen
    • Ich habe mit Teil 6 angefangen, später aber 1 bis 5 nachgeholt, und es ist definitiv ein Teil meiner Kernpersönlichkeit geworden.
      Space Quest ist auch mit meinen liebsten Geschichten aus dem frühen Internet verwoben. Damals, als Websites vor allem auf Geocities und von gelangweilten College-Studenten gehostet wurden, gab es Fanseiten zu Space Quest, und ich schrieb dem Betreiber einer der großen SQ-Seiten per E-Mail, dass ich die Spiele und die Seite mochte. Ich war damals etwa 14, und er antwortete, dass er mir die Originalspiele für ungefähr 40 Dollar schicken könne. Es waren alle Originale mit den originalen Boxen und Disketten. Es war etwa 1997, also war ich ein bisschen nervös, 40 Dollar an einen Fremden auf der anderen Seite des Landes zu schicken und zu hoffen, dass er sie wirklich abschickt, aber er tat es tatsächlich. Ein paar Wochen später kamen alle Spiele genau wie beschrieben an, und ich war überglücklich. Über Nacht wurde ich zu einem echten Gläubigen, und es ist eine sonnenkernartige Erinnerung an den Optimismus, an der ich bis heute festhalte. Jess, falls du irgendwo da draußen bist: Du warst echt. Ich hoffe, wir treffen uns eines Tages wieder
    • Ich habe ein sehr ähnliches Gefühl.
      Mein Vater arbeitete in einem Stahlwerk und war mit dem zuständigen Computer-Mitarbeiter dort befreundet, und der gab ihm eine Kopie von SQ2 zum Ausprobieren für zu Hause. Ich spielte das Spiel wie besessen, aber weil ich noch ziemlich jung war, war vieles daran verwirrend. Wenn ich wirklich festhing, bat ich meinen Vater, den Computer-Mitarbeiter zu fragen, wie man an einer bestimmten Stelle weiterkommt, und statt mir die Lösung direkt zu geben, gab er wohl freundlicherweise Hinweise. Es sind ungefähr 35 Jahre vergangen, aber ich erinnere mich immer noch ziemlich detailliert an Träume, die ich im Zusammenhang mit diesem Spiel hatte. Es hat mich wirklich stark geprägt
    • Ich empfinde dasselbe, aber besonders bei Space Quest II.
      SQ I habe ich erst viel später gespielt, und SQ III hat mich nicht so stark getroffen. Die übrigen Teile waren außerdem keine EGA-Spiele mit Texteingabe mehr. SQ II ruft bei mir viele Erinnerungen wach, und bis zu einem gewissen Grad habe ich damit auch Englisch gelernt. Ich erinnere mich an die Zufriedenheit, als ich herausfand, dass man bei Roger Wilco „rub berries“ eingeben kann
    • Ich war so glücklich, als der free little dude gefressen wurde, als man das Wesen am Anfang des Spiels rettet.
      Das war das erste Spiel dieser Art, das ich je gespielt habe, und ich habe mich als etwa Zehnjähriger wochenlang daran festgebissen

  • Ich glaube nicht, dass es im AGI-Engine-Code irgendeinen besonderen Geheimcode gab, von dem ein Konkurrent durch ein Leak stark hätte profitieren können.
    Es mag weitere Beispiele geben, aber Hugo's House of Horrors war einige Jahre später ein AGI-artiges Spiel, das von einer einzelnen Person gemacht wurde. Sierra-Spiele waren über den anfänglichen Neuheitswert von Grafikadventures hinaus vor allem deshalb erfolgreich, weil enorm viel Arbeit in die Erstellung der Grafik und in das eigentliche Schreiben des Spiels floss. Das heißt nicht, dass die Technik bedeutungslos war, aber ihr Anteil am Endergebnis war eher klein.

    • Damals war es viel schwieriger, an Informationen und nützlichen Beispielcode zu kommen.
      Funktionierende Software zu verstehen und zu entwickeln war enorm viel schwerer als heute, und es gab fast nichts, worauf man aufbauen konnte. Für MS-DOS gab es kaum nennenswertes Open Source, und Open-Source-Spiel-Engines erst recht nicht. Wenn der AGI-Quellcode damals breit geleakt worden wäre, hätte er zumindest als Blaupause dafür, wie die damals populärsten PC-Spiele genau gebaut wurden, durchaus Bedeutung haben können.
    • Ich frage mich manchmal, ob geleakter Source Code wirklich so wertvoll ist.
      Das gilt besonders für Code, der keine Geheimnisse enthält, die Angreifer missbrauchen könnten, etwa Keys oder Backdoors. Geleakter Code hat natürlich keine Lizenz, also kann man ihn nicht einfach im eigenen Produkt wiederverwenden, wenn man Klagen vermeiden will. Am Ende muss man den Code lesen, die Techniken verstehen und sie so in die eigene Arbeit übertragen, dass es nicht nach Copyright-Verletzung riecht — und das ist meistens schwieriger, als es von Grund auf selbst zu bauen. Selbst wenn es Vorteile gibt, ist fraglich, wie oft das tatsächlich zu einem echten Wettbewerbsvorteil führt. Entwickler schreiben ja sogar dann neuen Code, wenn es gut dokumentiertes Open Source mit permissiver Lizenz gibt. Code zu lesen ist oft schwieriger als ihn zu schreiben, und schon bloß ein Rebuild kann schwierig sein. Vielleicht hätte es das Kopieren etwas erleichtert, aber Spiele wurden meist innerhalb weniger Tage gecrackt und verbreitet, und möglicherweise war der Kopierschutzcode gar nicht im Source enthalten.
    • Das klingt wie die Aussage von jemandem, der in einer Zeit aufgewachsen ist, in der man „auch ohne ASM oder C etwas bauen konnte“.
      Schon die Zahl der Leute, die diese Sprachen überhaupt sprechen konnten, war vermutlich um einige Größenordnungen kleiner, und die Zahl derer, die damit etwas Konsistentes bauen konnten, noch kleiner.
    • Damals war die Lernrate des internen neuronalen Netzes fast auf Maximum gestellt.
      Heute sinkt sie schnell, sodass die Dinge, denen man jetzt begegnet, nicht mehr annähernd so stark die internen Gewichte formen wie damals.

  • Die Änderungshistorien-Kommentare sind wirklich großartig.
    Sie zeigen ein hohes Maß an Sorgfalt und Handwerkskunst aus einer Zeit lange bevor Versionsverwaltungswerkzeuge so etwas klar sichtbar machten. Ehrlich gesagt war das selbst nach CVS/SVN/Git für viele Leute noch immer nicht selbstverständlich. Das erinnert mich auch an den berühmten Aufsatz No Silver Bullet [1], der 1986 vorhersagte, dass Software auch in Zukunft im Wesentlichen so entstehen werde wie damals: indem Programmierer sich Befehl für Befehl mühsam vorarbeiten. Dass der Game-Engine-Code und die Kommentare im Originalbeitrag dem ähneln, was ich heute schreiben würde, stützt diese Vorhersage meiner Meinung nach fast 40 Jahre später noch immer.
    [1] https://en.wikipedia.org/wiki/No_Silver_Bullet

    • Auch heute sieht man in git-Commit-Messages noch viel zu oft „fix“ oder „stuff“.

  • In der Famicom-Version von Air Fortress landete unbeabsichtigt absurd viel Zeug im ROM.
    Darunter nicht kompilierter ASM-Code, ein MS-DOS-Verzeichnislisting, Strings aus einer der für den Build des Spiels verwendeten EXE-Dateien und mehr. Das japanische Modul hatte 128+128 KB. Für die spätere US-NES-Version stellte sich heraus, dass der Großteil der 128 KB Grafikdaten aus doppelten oder unbenutzten Grafiken bestand und die tatsächlich einzigartigen Grafiken nur etwa 36 KB ausmachten. Man entfernte das Bild eines Planeten aus einem der Endings, reduzierte die Grafik so auf 32 KB und veröffentlichte das Spiel auf einem 128+32-KB-Modul statt auf einem 128+128-KB-Modul.
    Source: https://tcrf.net/Air_Fortress

  • So etwas passierte tatsächlich sehr häufig.
    The Cutting Room Floor listet ungefähr 500 Spiele auf, bei denen versehentlich Quellcode enthalten war, von ein bisschen bis hin zu fast allem.
    https://tcrf.net/Category:Games_with_uncompiled_source_code

    • Nach einer schnellen Prüfung scheint dieser spezielle Fall des unkompilierten AGI-Interpreter-Codes auf dieser Space-Quest-II-Diskette dort noch nicht aufgeführt zu sein.
      Ich bin neugierig, ob andere das genauso sehen. Dasselbe passierte auch auf einer King's Quest III-Diskette, und tatsächlich scheint das zeitlich fast genau mit dem Fall von Space Quest II zusammenzufallen.

  • Am besten gefällt mir daran, dass offenbar über eine ganze Generation hinweg niemand den auf der Diskette liegenden Quellcode entdeckt hat.
    „Erstaunlicherweise scheinen weder Sierra noch Konkurrenten noch Kunden bemerkt zu haben, dass das passiert war, und entdeckt wurde es erst Jahrzehnte später. Der erste bekannte Fund stammt aus dem Oktober 2016 durch den Online-Nutzer NewRisingSun.“ Das erinnert mich auch an die jüngsten Durchbrüche bei Tetris und Super Mario Bros.. Als ich diese Spiele als Kind spielte, dachte ich, sie würden Jahrzehnte später als vergessene Relikte enden, die außer den hingebungsvollsten Hobbyisten niemand mehr überhaupt ausführen könnte. Doch das Internet und Emulatoren haben diesen frühen Spielen und dem frühen Computing neues Leben eingehaucht.

    • Der letzte Satz scheint die Antwort zu geben.
      Es gab sicher Leute, die gelöschte Dateien gefunden haben, aber vor der weiten Verbreitung des Internets wurde so etwas wahrscheinlich weder breit bekannt noch dokumentiert.
    • Es gibt Leute, die alte Software mit modernen Flux-Imaging-Werkzeugen archivieren und dadurch perfekte Diskettenkopien möglich machen.
      Vielleicht hat jemand beim Imaging solcher Disketten die in freiem Speicher verbliebenen Daten entdeckt.

  • Zwischen 1987 und 1993 wurden für zwei Mac-Apps etwa neun Master-Disketten vorbereitet.
    Es wurden immer neue Disketten verwendet, und es gab eine lange Checkliste, um sicherzustellen, dass die richtige Diskette genutzt wurde. Zum Glück hat alles gut funktioniert, und einige davon wurden sogar verwendet, um 100.000 Disketten herzustellen. Zum Glück muss heute niemand mehr so etwas machen.

    • Im Grunde macht man heute noch etwas Ähnliches, nur heißt es jetzt Docker-Layer.
      Ich habe schon solche Layer gesehen: base, Tools hinzufügen, Quellcode hinzufügen, kompilieren, Quellcode löschen, zusätzliche Tools löschen, Release. Dann entsteht so eine Situation wie: „Warum ist das Docker-Image so groß? Naja, Speicherplatz ist billig ...“ Dabei gibt es einfache Lösungen wie Multi-Stage-Builds ( https://docs.docker.com/build/building/multi-stage/ ). Aber wenn man nicht weiß, dass die aktuelle Docker-Image-Ansicht alle vorherigen Layer enthält, passieren solche Fehler gelegentlich.

  • In der Zeit, als Release-Artefakte noch von Hand erstellt wurden, landeten oft Überreste darin, die gar nicht für die Veröffentlichung gedacht waren.
    Dinge wie geschnittener Inhalt[1] oder Debug-Symbole[2]. Als ich zufällig Debug-Symbole entdeckte, die in einem Datenarchiv einer Demo-Version des Videospiels versteckt waren, das ich gerade per Reverse Engineering untersuche, war das unerwartet, aber eine enorme Hilfe. Heute passiert so etwas dank CI/CD, automatisierten Builds und anderen modernen Entwicklungspraktiken vermutlich seltener.
    [1] https://tcrf.net
    [2] https://www.retroreversing.com/games/symbols

    • Ich habe den Verdacht, dass gute Praktiken wie CI/CD in der Spieleentwicklung nicht so verbreitet sind, wie man vielleicht denkt.
    • Eine CI/CD-Pipeline kann auch in die andere Richtung wirken.
      Wenn es keine Fehler gibt, schaut sich niemand Tausende Zeilen Konsolenausgabe an. Selbst wenn im finalen Release-Paket unnötig viele überflüssige Inhalte enthalten sind, werden die Tests wahrscheinlich trotzdem bestehen. Deshalb sagt mir mein Bauchgefühl eher das Gegenteil. Es könnte häufiger vorkommen, oder zumindest könnte CI/CD solche Dinge eher begünstigen als ein manueller Build. Es kann auch andere Faktoren geben.