Windows 11 exécute aussi des binaires compilés il y a 30 ans

 (twitter.com/mikko)
1 points par GN⁺ 2023-08-20 | 1 commentaires | Partager sur WhatsApp
  • Le tout dernier Windows 11 exécute un binaire compilé le 18 août 1993, ce qui met en lumière la compatibilité descendante de long terme de Microsoft
  • Le programme en question est un binaire créé il y a 30 ans au moment de la publication, montrant que d’anciens logiciels Windows peuvent encore fonctionner dans un environnement moderne
  • Le point central de cet exemple réside dans la compatibilité descendante qui permet au nouveau système d’exploitation d’accepter tel quel des exécutables du passé
  • Les informations publiées ne permettent pas de confirmer s’il a fallu une conversion, une recompilation ou une configuration supplémentaire
  • La possibilité d’exécuter d’anciens binaires constitue un signal de stabilité important pour les entreprises et les particuliers qui gèrent des logiciels archivés sur le long terme

Exemple d’exécution sous Windows 11 d’un binaire vieux de 30 ans

  • Windows 11 exécute un binaire compilé le 18 août 1993
  • Cet exemple a été partagé comme une illustration de la très forte compatibilité descendante de Microsoft
  • Les informations confirmées se limitent à l’exécution possible et à la date de compilation
    • Le nom du binaire, le langage de développement, le mode d’exécution et l’éventuelle nécessité de réglages supplémentaires ne sont pas précisés

À lire aussi

1 commentaires

 
GN⁺ 2023-08-20
Avis de Hacker News

  • À titre de référence, il y a aussi l’article de Joel Spolsky : https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    Selon l’un des développeurs de SimCity, le jeu avait un bug critique qui, par hasard, fonctionnait bien sous DOS mais cassait sous Windows. C’était un bug de réutilisation de mémoire déjà libérée, et les testeurs de l’équipe Windows, en lançant des apps populaires, ont constaté que SimCity plantait sans cesse. Les développeurs Windows auraient désassemblé SimCity, l’auraient suivi au débogueur pour trouver le bug, puis ajouté du code qui vérifiait si SimCity était en cours d’exécution et, uniquement dans ce cas, faisait fonctionner l’allocateur mémoire dans un mode spécial permettant de continuer à utiliser la mémoire après libération.

    • Comme contre-exemple, Soldier of Fortune est cassé sur les Windows modernes à cause d’un hack de compatibilité mal appliqué. Si l’on renomme l’exécutable, il fonctionne sans problème.
      Ce genre d’implémentation de la rétrocompatibilité est opaque et bricolée, donc peu satisfaisante. Des outils similaires ont aussi été utilisés pour casser les apps de concurrents. En général, on finit par essayer une à une les anciennes versions de Windows dans lesquelles lancer le programme. Linux ne fait pas mieux, faute d’ABI stable, et Mac mélange un excellent Rosetta avec des apps qui cassent sans raison. Je me demande si FreeBSD s’en est mieux sorti. Ou si des systèmes d’exploitation « mûrs » disparus, comme VMS, faisaient mieux.
    • De nos jours, les mises à jour de pilotes GPU fonctionnent aussi largement comme ça. Plutôt que de laisser les développeurs corriger les jeux, Nvidia a calculé qu’il était dans son intérêt de corriger les bugs des jeux au niveau du pilote GPU et de distribuer ces correctifs.
    • Cela ressemble plutôt à un excellent argument pour dire qu’il faut casser la rétrocompatibilité. Ces hacks absurdes deviennent une charge de maintenance et de débogage pour quelqu’un, et s’ajoutent comme une taxe sur tout le système d’exploitation. À mon avis, leurs traces sont d’ailleurs assez visibles.
    • Si vous cherchez les chapitres bonus de “The Old New Thing” de Raymond Chen, vous trouverez de nombreux exemples d’une équipe dédiée à hacker Windows pour vérifier les apps populaires une par une et les faire fonctionner sur le nouvel OS.
    • À l’inverse, le pilote GPU d’Asahi Linux vérifie si la première lettre du nom du processus est X, et si c’est le cas, il refuse tout simplement.
      Du genre : pourquoi utilisez-vous encore Xorg ? Vous auriez déjà dû passer à Wayland.
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen fournit depuis des décennies un point de vue interne sur ce sujet : https://devblogs.microsoft.com/oldnewthing/

  • Ce qui est amusant, c’est que grâce à la stabilité générale de l’API Windows, Win32/DX est devenu, via l’immense travail de Wine/Proton, une API « universelle » très stable et fiable sur Linux et d’autres systèmes d’exploitation. On voit de plus en plus de jeux abandonner une sortie native Linux et sortir simplement pour Proton.

  • Ce n’est pas fou, c’est le niveau qu’on devrait naturellement attendre d’un outil. Mon marteau fonctionne toujours parfaitement avec des clous achetés il y a 30 ans.
    On ne peut rien construire sur des fondations mouvantes qui cassent sans cesse la rétrocompatibilité. Au final, on passe plus de temps à maintenir qu’à créer. Et ensuite on réinvente la roue, mais du point de vue de l’utilisateur, la nouvelle roue brillante n’est pas forcément meilleure. La plupart des logiciels que j’utilise ont plus de 10 ans ; certains sont encore mis à jour, d’autres non, ou sont partis dans le cloud, et moi je suis très content d’être resté en arrière.

    • Milwaukee fabrique encore des batteries NiCAD pour ses outils, pourtant largement dépassées.
    • À l’inverse, on peut aussi rester définitivement coincé avec ce genre de limitations idiotes : https://news.ycombinator.com/item?id=14286383

  • J’y croyais autrefois, mais plus maintenant.
    Les jeux Steam qui utilisaient le service Games for Windows – Live et qui n’ont pas été mis à jour après l’arrêt du service en 2014 ne se lancent plus depuis Windows 10. C’est parce que la DLL de ce service a été supprimée. Pendant un temps, les gens réglaient le problème en téléchargeant la DLL depuis des sites tiers, mais aujourd’hui ça ne marche même plus.

    • Même de vieux jeux sans DRM ni service réseau peuvent ne pas fonctionner à cause de la compatibilité graphique. Cela dit, cnc-ddraw en sauve un bon nombre : https://github.com/FunkyFr3sh/cnc-ddraw
    • Les versions pirates de ces jeux, elles, doivent probablement encore fonctionner ;)

  • Il existe des exemples encore plus « fous ».
    z/OS (aussi appelé OS360, MVS) prend en charge des programmes remontant aux années 1960, et un DE chez IBM disait utiliser encore aujourd’hui un programme compilé à l’époque de la mission Apollo 11.

    • Dans le monde des mainframes, c’est courant. Unisys (ex-Univac) dispose encore de mainframes Dorado compatibles au niveau binaire avec l’Univac 1100, sorti en 1962.
    • C’est quoi, un DE ? Et a-t-il dit ce que faisait ce programme ?
      Il existe aussi d’autres systèmes qui exécutent ou convertissent automatiquement des binaires de plus de 30 ans. IBM i sur POWER (i5/AS400) devrait pouvoir exécuter des programmes de l’époque du System/38 (1980), et HPE NonStop (aussi appelé Tandem Guardian) sur X86-64 peut exécuter ou convertir des binaires des systèmes TNS propriétaires originels de la fin des années 1970 et des systèmes MIPS de 1991.

  • Windows est connu pour son obsession de la rétrocompatibilité, mais pour les applications CLI DOS, le sous-système DOS est en quelque sorte figé, donc ça ne semble pas être un si grand défi. Je me demande ce que ça donnerait avec des programmes façon DOS plus exigeants, ou avec les premières applications Win16. Par exemple, est-ce que des choses comme Zortech C++ de 1986 avec l’extendeur DOS Phar Lap, ou Minesweeper de Windows 3.1, fonctionneraient ?

    • Ce n’est pas une application DOS, mais une application console Win32. Les applications DOS (16 bits ou 32 bits) et les applications Win16 ne s’exécutent pas nativement.
    • Zortech C++ a été mon environnement pendant un temps et j’en garde de bons souvenirs. Phar Lap s’implique trop en profondeur, donc je pense qu’il serait difficile de le faire tourner sur Windows actuel, mais ça vaut la peine d’essayer. La plupart des fonctions liées à la mémoire étendue/expansée ne fonctionneront probablement plus.

  • Cela ne devrait absolument pas être considéré comme impressionnant. Il faudrait voir ça comme quelque chose de courant et d’évident ; si ça ne marche pas, ce devrait être considéré comme un échec très embarrassant et inacceptable.
    Je ne veux pas dire que ce n’est pas impressionnant au regard du chaos de 2023. Je veux dire que c’est la norme vers laquelle nous devrions tendre.

    • D’accord. Il n’y a aucune raison pour que la plupart des binaires compilés statiquement cessent de fonctionner.

  • Certains diront que Linux fait pareil, et techniquement c’est vrai, mais en pratique c’est assez difficile.
    L’ABI du noyau est stable, mais le reste relève presque du chaos pur, à cause de la manière dont les applications sont généralement packagées sous Linux. L’application elle-même peut se charger (si elle n’est pas au format a.out), mais elle risque très probablement d’échouer au chargement de la plupart des bibliothèques. Au final, il faut un chroot complet de la distribution Linux de référence, ou un autre runtime, et on n’est même pas sûr de pouvoir retrouver les archives d’une distribution vieille de 30 ans. En plus, il faut supposer que l’ABI du noyau n’a réellement pas changé d’un bit, et que d’autres interfaces comme /proc ou /sys n’ont pas changé non plus. Il me semble que /sys n’existait pas il y a 30 ans. S’il s’agit d’une application Xorg, je ne parierais pas mon déjeuner sur la compatibilité au niveau du protocole.

    • Sous Linux aussi, ça fonctionne de la même manière que sous Windows. Sans les bibliothèques dynamiques et la configuration nécessaires, ça ne tourne pas.
      J’ai du mal à comprendre pourquoi ce serait un point négatif pour Linux et pas pour Windows.

  • J’ai toujours trouvé dommage que les vieux logiciels Mac ne fonctionnent tout simplement plus. Le passage d’Apple à de nouvelles architectures était peut-être inévitable. Mais le problème, c’est quand les émulateurs cessent de fonctionner quelques années plus tard.
    L’engagement que Microsoft montre envers ses clients ne devrait pas être une chose aussi surprenante. Toutes les entreprises devraient agir ainsi.

    • Apple aussi a eu une époque où l’on pouvait installer le dernier Mac OS X même sur un iMac de première génération (300 MHz ?). Il fallait peut-être pousser la RAM au maximum, mais ça suffisait, et c’était en fait tout à fait utilisable.