Windows 11 executa até binários compilados há 30 anos

 (twitter.com/mikko)
1 pontos por GN⁺ 2023-08-20 | 1 comentários | Compartilhar no WhatsApp
  • O Windows 11 mais recente executa um binário compilado em 18 de agosto de 1993, destacando a compatibilidade retroativa de longo prazo da Microsoft
  • O programa em questão é um binário criado há 30 anos na data da publicação, mostrando que softwares antigos do Windows ainda podem funcionar em ambientes atuais
  • O ponto central do caso está na compatibilidade retroativa, em que uma nova versão do sistema operacional aceita executáveis antigos sem alterações
  • Pelas informações divulgadas, não é possível confirmar se foram necessárias conversão, recompilação ou configurações adicionais
  • A possibilidade de executar binários antigos é um importante sinal de estabilidade para empresas e usuários que lidam com softwares arquivados por longos períodos

Caso de execução de um binário de 30 anos no Windows 11

  • O Windows 11 executa um binário compilado em 18 de agosto de 1993
  • O caso foi compartilhado junto da avaliação de que a compatibilidade retroativa da Microsoft é extremamente forte
  • As informações confirmadas se limitam à possibilidade de execução e à data de compilação
    • Não foram incluídos o nome do binário, a linguagem de desenvolvimento, a forma de execução nem a necessidade de configurações adicionais

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-20
Opiniões no Hacker News

  • Para referência, há também um texto de Joel Spolsky: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    Um dos desenvolvedores de SimCity contou que havia um bug fatal que, por acaso, funcionava bem no DOS, mas quebrava no Windows. Era um bug de reutilização de memória já liberada, e os testadores da equipe do Windows, ao rodarem apps populares, perceberam que SimCity continuava travando. Dizem que os desenvolvedores do Windows desassemblaram SimCity, rastrearam o problema com um debugger, encontraram o bug e então inseriram código para verificar se SimCity estava sendo executado; nesse caso específico, o alocador de memória passava a operar em um modo especial que permitia continuar usando a memória mesmo depois de liberada

    • Como contraexemplo, Soldier of Fortune quebra em versões modernas do Windows por causa de um hack de compatibilidade aplicado incorretamente. Se você renomear o executável, ele funciona sem problemas
      Esse tipo de implementação de compatibilidade retroativa é ruim por ser opaco e improvisado. Ferramentas parecidas também foram usadas para quebrar apps de concorrentes. Em geral, acaba virando uma tentativa manual de descobrir em qual versão antiga do Windows o programa deve ser executado. O Linux também não é melhor, por não ter uma ABI estável, e o Mac é uma mistura de um Rosetta excelente com apps quebrando sem motivo. Fico pensando se o FreeBSD se saiu melhor. Ou se sistemas operacionais “maduros” desaparecidos, como o VMS, eram melhores
    • Hoje em dia, atualizações de drivers de GPU também costumam funcionar mais ou menos assim. Em vez de o desenvolvedor corrigir o jogo, a Nvidia calculou que é mais vantajoso para ela corrigir bugs dos jogos no nível do driver da GPU e distribuir isso
    • Isso, na verdade, parece um ótimo argumento para quebrar a compatibilidade retroativa. Hacks absurdos como esses viram um fardo de manutenção e depuração para alguém, e são acrescentados como um imposto sobre todo o sistema operacional. Na prática, acho que esses vestígios aparecem bastante
    • Se você procurar os capítulos bônus de “The Old New Thing”, de Raymond Chen, encontrará muitos casos de uma equipe dedicada a hackear o Windows para verificar apps populares um por um e fazê-los rodar no novo sistema operacional
    • Enquanto isso, o driver de GPU do Asahi Linux verifica se a primeira letra do nome do processo é X e, se for, simplesmente recusa
      Algo na linha de: por que você ainda está rodando Xorg? Já deveria ter migrado para Wayland
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen vem oferecendo uma perspectiva interna sobre esse assunto há décadas: https://devblogs.microsoft.com/oldnewthing/

  • Graças à estabilidade geral da API do Windows, é interessante ver que Win32/DX, por meio do enorme trabalho do Wine/Proton, virou uma API “universal” muito estável e confiável no Linux e em outros sistemas operacionais. Continuo vendo jogos desistirem de lançamentos nativos para Linux e simplesmente saírem mirando o Proton

  • Isso não é loucura; é o nível de expectativa óbvio para uma ferramenta. Meu martelo ainda funciona perfeitamente com pregos que comprei há 30 anos
    Não dá para construir nada sobre uma base instável que vive quebrando a compatibilidade retroativa. No fim, você passa mais tempo fazendo manutenção do que construindo. Aí acaba reinventando a roda, mas, do ponto de vista do usuário, a roda nova e brilhante não é necessariamente melhor. A maior parte do software que uso tem mais de 10 anos; alguns ainda recebem atualizações, outros não, ou foram para a nuvem, e eu fiquei feliz para trás

    • A Milwaukee ainda fabrica baterias NiCAD para suas ferramentas, que já estão muito defasadas
    • Por outro lado, você também pode ficar preso para sempre a essas limitações idiotas: https://news.ycombinator.com/item?id=14286383

  • Eu acreditava nisso antigamente, mas não mais
    Jogos do Steam que usavam o serviço Games for Windows – Live e que não foram atualizados depois do encerramento do serviço em 2014 não rodam no Windows 10 ou posterior. Isso porque a DLL do serviço foi removida. Por um tempo, as pessoas resolviam baixando a DLL de sites de terceiros, mas hoje nem isso funciona

    • Jogos antigos sem DRM nem serviços de rede também podem não rodar por causa de compatibilidade gráfica. Ainda assim, o cnc-ddraw salva boa parte deles: https://github.com/FunkyFr3sh/cnc-ddraw
    • Mesmo assim, acho que as versões piratas desses jogos ainda rodam ;)

  • Há casos ainda mais “malucos”
    z/OS (também chamado de OS360, MVS) dá suporte até a programas dos anos 1960, e um DE da IBM disse que ainda usa um programa compilado por volta da missão Apollo 11

    • No mundo dos mainframes, isso é comum. A Unisys (antiga Univac) ainda tem mainframes Dorado compatíveis em binário com o Univac 1100, lançado em 1962
    • O que é DE? E ele contou o que esse programa faz?
      Há outros sistemas que executam ou convertem automaticamente binários com mais de 30 anos. O IBM i em POWER (i5/AS400) provavelmente consegue executar programas da época do System/38 (1980), e o HPE NonStop (também chamado de Tandem Guardian) em X86-64 consegue executar ou converter binários do sistema TNS original proprietário do fim dos anos 1970 e do sistema MIPS de 1991

  • É famosa a obsessão do Windows por compatibilidade retroativa, mas apps de CLI para DOS não parecem um desafio tão grande, já que o subsistema DOS está praticamente congelado. Fico curioso para saber como seria rodar programas no estilo DOS com mais requisitos, ou apps Win16 iniciais. Por exemplo, será que coisas como o Zortech C++ de 1986 com o extensor DOS Phar Lap, ou o Minesweeper do Windows 3.1, funcionariam?

    • Isso não é um app DOS, e sim um app de console Win32. Apps DOS (sejam de 16 ou 32 bits) ou apps Win16 não rodam nativamente
    • Zortech C++ foi a ferramenta que usei por um tempo, e tenho boas lembranças dela. Acho que o Phar Lap se intrometia em níveis profundos demais para rodar no Windows atual, mas valeria experimentar. Provavelmente a maior parte dos recursos ligados a memória estendida/expandida já não funciona

  • Isso não deveria ser visto como algo impressionante de jeito nenhum. Deveria ser considerado algo cotidiano e óbvio; se não funcionar, deveria ser visto como uma falha muito vergonhosa e inaceitável
    Não quero dizer que não seja impressionante pelos padrões do caos de 2023. Quero dizer que essa é a norma à qual deveríamos aspirar

    • Concordo. Não há motivo nenhum para a maioria dos binários compilados estaticamente deixar de funcionar

  • Alguém vai dizer que o Linux também é assim, e tecnicamente está certo, mas na prática é bem difícil
    A ABI do kernel é estável, mas o resto é quase puro caos, por causa da forma como aplicações costumam ser empacotadas no Linux. O app em si pode até carregar (se não for no formato a.out), mas é bem provável que falhe ao carregar a maioria das bibliotecas. No fim, você precisa de um chroot da distribuição Linux inteira que sirva de referência, ou de outro runtime, e nem dá para ter certeza de que ainda será possível encontrar arquivos de uma distribuição de 30 anos atrás. Além disso, é preciso assumir que a ABI do kernel realmente não mudou nem um bit, e que outras interfaces como /proc ou /sys também não mudaram. Acho que /sys nem existia 30 anos atrás. Se for um app Xorg, eu não apostaria meu almoço na compatibilidade em nível de protocolo

    • No Linux, funciona do mesmo jeito que no Windows. Se não houver as bibliotecas dinâmicas e configurações necessárias, não roda
      É difícil entender por que isso conta contra o Linux, mas não contra o Windows

  • Sempre achei uma pena que softwares antigos de Mac simplesmente não rodem mais. Talvez fosse inevitável a Apple migrar para novas arquiteturas. Mas o problema é que, alguns anos depois, o emulador quebra
    Não deveria ser tão surpreendente ver a Microsoft demonstrar esse compromisso com os clientes. Todas as empresas deveriam agir assim

    • Houve uma época em que a Apple também permitia instalar o Mac OS X mais recente até no iMac de primeira geração (300 MHz?). Talvez fosse preciso colocar o máximo de RAM, mas isso bastava, e na prática era bem usável