Windows 11 führt auch vor 30 Jahren kompilierte Binärdateien aus

 (twitter.com/mikko)
1 Punkte von GN⁺ 2023-08-20 | 1 Kommentare | Auf WhatsApp teilen
  • Das aktuelle Windows 11 führt eine am 18. August 1993 kompilierte Binärdatei aus und unterstreicht damit Microsofts langfristige Abwärtskompatibilität
  • Das Programm ist eine Binärdatei, die zum Zeitpunkt der Veröffentlichung vor 30 Jahren erstellt wurde, und zeigt, dass alte Windows-Software auch in modernen Umgebungen funktionieren kann
  • Im Kern geht es bei diesem Beispiel darum, dass eine neue Betriebssystemversion frühere ausführbare Dateien unverändert akzeptiert: Abwärtskompatibilität
  • Ob eine separate Konvertierung, Neukompilierung oder zusätzliche Konfiguration erforderlich war, lässt sich anhand der veröffentlichten Informationen nicht bestätigen
  • Die Möglichkeit, alte Binärdateien auszuführen, ist für Unternehmen und private Nutzer ein wichtiges Stabilitätssignal beim Umgang mit langfristig archivierter Software

Beispiel: Windows 11 führt eine 30 Jahre alte Binärdatei aus

  • Windows 11 führt eine am 18. August 1993 kompilierte Binärdatei aus
  • Das Beispiel wurde als Beleg für Microsofts sehr starke Abwärtskompatibilität geteilt
  • Die bestätigten Informationen beschränken sich auf die Ausführbarkeit und das Kompilierdatum
    • Name der Binärdatei, Programmiersprache, Ausführungsweise und etwaige zusätzliche Einstellungen sind nicht enthalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-20
Meinungen auf Hacker News

  • Zur Einordnung gibt es auch einen Artikel von Joel Spolsky: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    Einer der SimCity-Entwickler sagte, es habe einen fatalen Bug gegeben, der unter DOS zufällig gut funktionierte, unter Windows aber kaputtging. Es war ein Bug, bei dem freigegebener Speicher erneut verwendet wurde, und Tester des Windows-Teams entdeckten beim Ausprobieren beliebter Apps, dass SimCity ständig abstürzte. Die Windows-Entwickler hätten SimCity disassembliert und mit dem Debugger nachverfolgt, den Bug gefunden und dann Code eingebaut, der prüfte, ob SimCity ausgeführt wird, und nur in diesem Fall den Speicher-Allokator in einem Spezialmodus laufen ließ, in dem der Speicher auch nach dem Freigeben weiter genutzt werden konnte.

    • Als Gegenbeispiel geht Soldier of Fortune auf modernen Windows-Versionen wegen eines falsch angewendeten Kompatibilitäts-Hacks kaputt. Wenn man den Namen der ausführbaren Datei ändert, läuft es problemlos.
      Diese Art der Abwärtskompatibilität ist undurchsichtig und improvisiert und daher nicht besonders gut. Ähnliche Werkzeuge wurden auch genutzt, um Apps von Wettbewerbern kaputtzumachen. Üblicherweise läuft es darauf hinaus, der Reihe nach auszuprobieren, mit welcher alten Windows-Version man es starten soll. Linux ist mangels stabiler ABI auch nicht besser, und beim Mac gibt es eine Mischung aus großartigem Rosetta und grundlos kaputten Apps. Vielleicht hat FreeBSD es besser gemacht? Oder verschwundene „ausgereifte“ Betriebssysteme wie VMS?
    • Heutige GPU-Treiber-Updates laufen im Großen und Ganzen ebenfalls so. Statt dass der Entwickler das Spiel repariert, rechnet Nvidia offenbar damit, dass es für sie vorteilhafter ist, Spiele-Bugs auf Ebene des GPU-Treibers zu beheben und auszuliefern.
    • Das wirkt eher wie ein hervorragendes Argument dafür, Abwärtskompatibilität zu brechen. Solche absurden Hacks werden für irgendwen zu einer Wartungs- und Debugging-Last und liegen wie eine Steuer auf dem gesamten Betriebssystem. Ich denke, diese Spuren sind tatsächlich ziemlich sichtbar.
    • Wenn man die Bonuskapitel von Raymond Chens „The Old New Thing“ sucht, findet man viele Beispiele dafür, dass es ein dediziertes Team gab, das Windows hackte, um beliebte Apps einzeln zu prüfen und sie auf dem neuen Betriebssystem lauffähig zu machen.
    • Der Asahi-Linux-GPU-Treiber hingegen prüft, ob der erste Buchstabe des Prozessnamens X ist, und lehnt ihn dann einfach ab.
      Nach dem Motto: Warum läuft bei euch immer noch Xorg? Ihr hättet längst zu Wayland wechseln sollen.
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen liefert seit Jahrzehnten eine Insiderperspektive zu diesem Thema: https://devblogs.microsoft.com/oldnewthing/

  • Interessant ist, dass Win32/DX dank der allgemeinen Stabilität der Windows-API und der enormen Arbeit an Wine/Proton zu einer sehr stabilen und verlässlichen „universellen“ API für Linux und andere Betriebssysteme geworden ist. Man sieht immer wieder, dass Spiele auf native Linux-Releases verzichten und einfach für Proton veröffentlichen.

  • Das ist nicht verrückt, sondern genau das, was man von einem Werkzeug erwarten sollte. Mein Hammer funktioniert auch mit Nägeln, die ich vor 30 Jahren gekauft habe, immer noch perfekt.
    Auf einem wackligen Fundament, das ständig die Abwärtskompatibilität bricht, kann man nichts aufbauen. Am Ende verbringt man mehr Zeit mit Wartung als mit dem Bauen. Danach erfindet man das Rad neu, aber aus Nutzersicht ist das glänzende neue Rad nicht zwingend besser. Die meiste Software, die ich nutze, ist über zehn Jahre alt; manches davon wird noch aktualisiert, manches nicht oder ist in die Cloud abgewandert, und ich bin glücklich zurückgeblieben.

    • Milwaukee stellt immer noch NiCAD-Akkus für seine längst veralteten eigenen Werkzeuge her.
    • Umgekehrt kann man dadurch auch dauerhaft an solche unsinnigen Einschränkungen gebunden sein: https://news.ycombinator.com/item?id=14286383

  • Früher habe ich das geglaubt, heute nicht mehr.
    Steam-Spiele, die den Dienst Games for Windows – Live nutzten und nach dessen Einstellung 2014 nicht aktualisiert wurden, laufen seit Windows 10 nicht mehr. Der Grund ist, dass die betreffende Dienst-DLL entfernt wurde. Eine Zeit lang lösten Leute das, indem sie die DLL von Drittanbieter-Websites herunterluden, aber inzwischen funktioniert auch das nicht mehr.

    • Auch alte Spiele ohne DRM oder Netzwerkdienst können wegen Grafikkompatibilität nicht laufen. Allerdings rettet cnc-ddraw einen erheblichen Teil davon: https://github.com/FunkyFr3sh/cnc-ddraw
    • Ich vermute trotzdem, dass die Raubkopien dieser Spiele noch laufen ;)

  • Es gibt noch „verrücktere“ Beispiele.
    z/OS (auch bekannt als OS360, MVS) unterstützt sogar Programme aus den 1960er-Jahren, und ein DE bei IBM sagte, man nutze immer noch ein Programm, das ungefähr zur Zeit der Apollo-11-Mission kompiliert wurde.

    • In der Mainframe-Welt ist das üblich. Unisys (früher Univac) hat immer noch Dorado-Mainframes, die binärkompatibel mit dem Univac 1100 von 1962 sind.
    • Was ist ein DE? Und wurde auch gesagt, was dieses Programm macht?
      Es gibt auch andere Systeme, die über 30 Jahre alte Binaries ausführen oder automatisch konvertieren. IBM i auf POWER (i5/AS400) dürfte Programme aus der Zeit von System/38 (1980) ausführen können, und HPE NonStop (auch bekannt als Tandem Guardian) auf X86-64 kann Binaries der ursprünglichen proprietären TNS-Systeme aus den späten 1970ern und der MIPS-Systeme von 1991 ausführen oder konvertieren.

  • Windows ist bekannt dafür, geradezu verbissen auf Abwärtskompatibilität zu achten, aber DOS-CLI-Apps fühlen sich nicht nach einer besonders großen Herausforderung an, weil das DOS-Subsystem praktisch eingefroren ist. Ich frage mich, wie es wäre, anspruchsvollere DOS-artige Programme oder frühe Win16-Apps auszuführen. Würden zum Beispiel Zortech C++ von 1986 mit dem Phar-Lap-DOS-Extender oder Minesweeper aus Windows 3.1 laufen?

    • Das ist keine DOS-App, sondern eine Win32-Konsolen-App. DOS-Apps (ob 16- oder 32-Bit) und Win16-Apps werden nicht nativ ausgeführt.
    • Zortech C++ war eine Zeit lang meine Arbeitsumgebung, und ich habe gute Erinnerungen daran. Phar Lap greift sehr tief ein, deshalb dürfte es unter aktuellem Windows schwer laufen, aber ein Experiment wäre es wert. Vermutlich funktionieren die meisten Features rund um Expanded/Extended Memory heute nicht mehr.

  • Das sollte überhaupt nicht als beeindruckend gelten. Es sollte alltäglich und selbstverständlich sein; wenn es nicht funktioniert, sollte man das als sehr peinlichen und inakzeptablen Fehlschlag betrachten.
    Damit meine ich nicht, dass es gemessen am Chaos von 2023 nicht beeindruckend wäre. Ich meine, dass dies die Norm sein sollte, auf die wir hinarbeiten.

    • Stimme zu. Es gibt überhaupt keinen Grund, warum die meisten statisch kompilierten Binärdateien plötzlich nicht mehr funktionieren sollten.

  • Manche würden sagen, bei Linux sei es genauso, und technisch stimmt das, aber in der Praxis ist es ziemlich schwierig.
    Das Kernel-ABI ist stabil, aber der Rest ist nahezu reines Chaos, und das liegt daran, wie Anwendungen unter Linux üblicherweise paketiert werden. Die App selbst lässt sich vielleicht laden (sofern sie nicht im a.out-Format vorliegt), aber beim Laden der meisten Bibliotheken dürfte sie scheitern. Am Ende braucht man ein komplettes chroot der Referenz-Linux-Distribution oder eine andere Runtime, und es ist nicht einmal sicher, ob man noch ein 30 Jahre altes Distributionsarchiv findet. Außerdem müsste man annehmen, dass sich das Kernel-ABI wirklich um kein einziges Bit geändert hat und auch andere Schnittstellen wie /proc oder /sys unverändert geblieben sind. /sys gab es vor 30 Jahren meines Wissens noch gar nicht. Bei Xorg-Apps würde ich auf Protokollebene nicht mein Mittagessen auf Kompatibilität verwetten.

    • Unter Linux funktioniert es auf dieselbe Weise wie unter Windows. Wenn die nötigen dynamischen Bibliotheken und Konfigurationen fehlen, läuft es nicht.
      Ich verstehe schwer, warum das bei Linux ein Minuspunkt sein soll und bei Windows nicht.

  • Ich fand es immer schade, dass alte Mac-Software einfach nicht mehr läuft. Dass Apple auf neue Architekturen umgestiegen ist, mag unvermeidlich gewesen sein. Problematisch ist aber, wenn ein paar Jahre später der Emulator kaputtgeht.
    Microsofts sichtbares Engagement gegenüber seinen Kunden sollte nicht so erstaunlich sein. Alle Unternehmen sollten so handeln.

    • Auch Apple hatte einmal eine Zeit, in der man das neueste Mac OS X sogar auf einem iMac der ersten Generation (300 MHz?) installieren konnte. Vielleicht musste man den RAM bis zum Maximum aufrüsten, aber das reichte, und es war tatsächlich ziemlich brauchbar.