Windows 11 ejecuta incluso binarios compilados hace 30 años

 (twitter.com/mikko)
1 puntos por GN⁺ 2023-08-20 | 1 comentarios | Compartir por WhatsApp
  • El más reciente Windows 11 ejecuta un binario compilado el 18 de agosto de 1993, lo que resalta la compatibilidad retroactiva de largo plazo de Microsoft
  • El programa en cuestión es un binario creado hace 30 años al momento de la publicación, y muestra que software antiguo de Windows puede seguir funcionando incluso en entornos modernos
  • El punto clave del caso está en la compatibilidad retroactiva: que una nueva versión del sistema operativo acepte sin cambios un ejecutable del pasado
  • No se puede confirmar solo con la información publicada si fue necesaria alguna conversión, recompilación o configuración adicional
  • La posibilidad de ejecutar binarios antiguos es una señal importante de estabilidad para empresas y usuarios individuales que manejan software archivado a largo plazo

Caso de ejecución de un binario de hace 30 años en Windows 11

  • Windows 11 ejecuta un binario compilado el 18 de agosto de 1993
  • Este caso se compartió junto con la valoración de que la compatibilidad retroactiva de Microsoft es muy sólida
  • La información confirmada se limita a la posibilidad de ejecución y la fecha de compilación
    • No se incluyen el nombre del binario, el lenguaje de desarrollo, la forma de ejecución ni si hubo configuración adicional

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-08-20
Opiniones de Hacker News

  • Como referencia, también está el artículo de Joel Spolsky: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    Según uno de los desarrolladores de SimCity, había un bug fatal que de casualidad funcionaba bien en DOS, pero se rompía en Windows. Era un bug que reutilizaba memoria ya liberada, y los testers del equipo de Windows, al probar apps populares, descubrieron que SimCity se cerraba constantemente. Dicen que los desarrolladores de Windows desensamblaron SimCity, lo siguieron con un debugger, encontraron el bug y luego agregaron código que verificaba si se estaba ejecutando SimCity para, solo en ese caso, hacer que el asignador de memoria funcionara en un modo especial que permitía seguir usando memoria incluso después de liberarla.

    • Como contraejemplo, Soldier of Fortune se rompe en Windows moderno por un hack de compatibilidad aplicado incorrectamente. Si cambias el nombre del ejecutable, funciona sin problemas.
      Este tipo de implementación de retrocompatibilidad no me gusta porque es opaca y es una solución improvisada. También se han usado herramientas similares para romper apps de la competencia. Normalmente termina siendo cuestión de ir probando con qué versión antigua de Windows ejecutarlo. Linux tampoco es mejor porque no tiene una ABI estable, y Mac es una mezcla de un Rosetta excelente con apps que se rompen sin razón. Me pregunto si FreeBSD lo hizo mejor. O si esos sistemas operativos “maduros” ya desaparecidos, como VMS, eran mejores.
    • Hoy en día, las actualizaciones de drivers de GPU también suelen ser así. En vez de que el desarrollador arregle el juego, Nvidia calculó que le conviene más corregir los bugs del juego a nivel del driver de GPU y distribuirlo así.
    • Esto más bien parece un gran argumento a favor de romper la retrocompatibilidad. Estos hacks absurdos se convierten en una carga de mantenimiento y depuración para alguien, y se suman como un impuesto sobre todo el sistema operativo. De hecho, creo que sus huellas se notan bastante.
    • Si buscas los capítulos extra de “The Old New Thing” de Raymond Chen, aparecen muchos casos de un equipo dedicado a hackear Windows que revisaba apps populares una por una para hacer que funcionaran en el nuevo sistema operativo.
    • Por otro lado, el driver de GPU de Asahi Linux revisa si la primera letra del nombre del proceso es X, y si lo es, simplemente lo rechaza.
      Algo así como: ¿por qué sigues ejecutando Xorg? Ya deberías haberte pasado a Wayland.
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen lleva décadas aportando una perspectiva interna sobre este tema: https://devblogs.microsoft.com/oldnewthing/

  • Es interesante que, gracias a la estabilidad general de la API de Windows, Win32/DX se haya convertido, mediante el enorme trabajo de Wine/Proton, en una API “universal” muy estable y confiable en Linux y otros sistemas operativos. Cada vez veo más juegos que abandonan los lanzamientos nativos para Linux y simplemente salen para Proton.

  • Esto no es una locura, es el nivel de expectativa normal que uno tiene de una herramienta. Mi martillo todavía funciona perfectamente con clavos que compré hace 30 años.
    No se puede construir algo sobre cimientos inestables que rompen la retrocompatibilidad constantemente. Al final terminas pasando más tiempo manteniendo que creando. Luego vuelves a reinventar la rueda, pero desde el punto de vista del usuario la rueda nueva y brillante no necesariamente es mejor. La mayoría del software que uso tiene más de 10 años; algunas cosas todavía se actualizan, otras no, o se fueron a la nube, y yo me quedé felizmente atrás.

    • Milwaukee todavía fabrica baterías NiCAD para sus herramientas, que ya llevan bastante tiempo rezagadas.
    • Por el contrario, también puedes quedar atado para siempre a este tipo de restricciones tontas: https://news.ycombinator.com/item?id=14286383

  • Antes creía eso, pero ya no.
    Los juegos de Steam que usaban el servicio Games for Windows – Live y que no se actualizaron después de que el servicio cerró en 2014 no se ejecutan en Windows 10 en adelante. Eso se debe a que se eliminaron las DLL de ese servicio. Durante un tiempo la gente lo solucionaba descargando las DLL de sitios de terceros, pero ahora ni eso funciona.

    • Algunos juegos antiguos sin DRM ni servicios de red también pueden no funcionar por compatibilidad gráfica. Aunque cnc-ddraw rescata a bastantes de ellos: https://github.com/FunkyFr3sh/cnc-ddraw
    • Aun así, creo que las copias piratas de esos juegos todavía funcionan ;)

  • Hay casos todavía más “locos”.
    z/OS (también conocido como OS360 o MVS) soporta programas desde la década de 1960, y un DE de IBM dijo que todavía usa un programa compilado alrededor de la época de la misión Apollo 11.

    • En el mundo de los mainframes es algo común. Unisys (antes Univac) todavía tiene mainframes Dorado con compatibilidad binaria con el Univac 1100, que salió en 1962.
    • ¿Qué es un DE? ¿Y contó qué hace ese programa?
      También hay otros sistemas que ejecutan o convierten automáticamente binarios de más de 30 años. IBM i on POWER (i5/AS400) probablemente pueda ejecutar programas de la época de System/38 (1980), y HPE NonStop (también conocido como Tandem Guardian) on X86-64 puede ejecutar o convertir binarios del sistema TNS propietario original de fines de los 70 y del sistema MIPS de 1991.

  • Es bien sabido que Windows se obsesiona con la compatibilidad hacia atrás, pero las apps de CLI para DOS no se sienten como un desafío tan grande porque el subsistema DOS está prácticamente congelado. Me da curiosidad qué pasaría al ejecutar programas estilo DOS más exigentes o apps Win16 tempranas. Por ejemplo, ¿funcionarían cosas como Zortech C++ de 1986 con el extensor DOS Phar Lap, o Minesweeper de Windows 3.1?

    • Eso no es una app de DOS, sino una app de consola Win32. Las apps de DOS (sean de 16 o 32 bits) o las apps Win16 no se ejecutan de forma nativa.
    • Zortech C++ fue mi herramienta de trabajo durante un tiempo y le tengo buenos recuerdos. Creo que Phar Lap se metía demasiado a bajo nivel como para correr en Windows actual, pero valdría la pena probarlo. Probablemente la mayoría de las funciones relacionadas con memoria extendida/expandida ya no funcionen.

  • Esto no debería considerarse algo impresionante en absoluto. Debería verse como algo cotidiano y obvio; si no funciona, debería verse como un fracaso muy vergonzoso e inaceptable.
    No quiero decir que no sea impresionante según los estándares del caos de 2023. Me refiero a que esa debería ser la norma a la que aspiramos.

    • De acuerdo. No hay ninguna razón para que la mayoría de los binarios compilados estáticamente dejen de funcionar.

  • Alguien dirá que Linux también es así, y técnicamente es cierto, pero en la práctica es bastante difícil.
    La ABI del kernel es estable, pero el resto se acerca al caos puro, y eso se debe a la forma en que normalmente se empaquetan las aplicaciones en Linux. Aunque la app en sí pueda cargarse (si no está en formato a.out), es muy probable que falle al cargar la mayoría de las bibliotecas. Al final terminas necesitando un chroot completo de la distribución Linux de referencia u otro runtime, y ni siquiera es seguro que puedas encontrar un archivo de una distribución de hace 30 años. Además, hay que asumir que la ABI del kernel realmente no cambió ni un bit y que otras interfaces como /proc o /sys tampoco cambiaron. Creo que /sys ni siquiera existía hace 30 años. Si fuera una app de Xorg, no apostaría mi almuerzo a la compatibilidad a nivel de protocolo.

    • En Linux funciona de la misma manera que en Windows. Si no tienes las bibliotecas dinámicas y la configuración necesarias, no corre.
      Me cuesta entender por qué esto se considera un punto en contra para Linux y no para Windows.

  • Siempre me dio pena que el software viejo de Mac simplemente dejara de funcionar. Puede que Apple no tuviera opción al migrar a nuevas arquitecturas. Pero el problema es cuando, unos años después, se rompe el emulador.
    No debería sorprender tanto este nivel de compromiso que Microsoft muestra hacia sus clientes. Todas las empresas deberían comportarse así.

    • Apple también tuvo una época en la que permitía instalar la versión más reciente de Mac OS X incluso en los iMac de primera generación (¿300 MHz?). Quizá había que ampliar la RAM al máximo, pero con eso alcanzaba y en realidad era bastante usable.