Os conflitos entre as versões 9x do Windows e o hardware «moderno» de cada época são muito mais profundos do que imaginamos. Mesmo quando os fabricantes insistiam em declarar que seus produtos haviam sido «otimizados» para os sistemas operacionais da Redmond, os erros que os usuários experimentavam eram crípticos e frustrantes. Esses erros se tornaram mais frequentes à medida que os processadores aumentaram sua velocidade, e hoje esses sistemas são muito complicados de executar, com ou sem virtualizador. Michal Necasek, do OS/2 Museum decidiu descobrir por quê…
O caso do AMD K6-2
Se você busca imagens de antigos processadores AMD K6-2, notará um detalhe muito particular: o logotipo do Windows 95 aparece gravado no spreader. Supostamente, isso é uma garantia de compatibilidade, a prova de que esses chips funcionam sem problemas no sistema operacional da Microsoft. Bem… digamos que «garantia» e «prova» são expressões muito otimistas. Os «Erros de Proteção do Windows» eram intermitentes nos K6-2 a 350 MHz, e semipermanentes em modelos mais rápidos.
O mais absurdo é que a Microsoft e a AMD quase entraram em guerra por isso: a Redmond queria obter 35 dólares adicionais pelo hotfix (embora o objetivo real fosse fazer os usuários adotarem o Windows 98), e a AMD respondeu publicando seu próprio patch, grátis. Os processadores Intel apresentaram certa resistência no início, mas sofreram problemas semelhantes mais tarde: as versões 9x do Windows falhavam com processadores «rápidos demais».
https://old.neoteo.com/mover-el-cursor-en-windows-95-lo-hacia-mas-rapido/A investigação de Michal Necasek
E assim chegamos ao portal do OS/2 Museum, onde Michal Necasek recebeu uma mensagem de um conhecido, anunciando que o Windows 3.11 for Workgroups não funcionava mais em máquinas virtuais. Os primeiros passos de sua investigação revelaram que um dos principais fatores para disparar o erro é o processador. Um Core i7-2600 apresentava-o em raras ocasiões, mas com um Ryzen 7 3800X tornou-se constante: Michal escrevia «win», aparecia o logotipo do Windows… e de volta ao DOS.
O resto da entrada é digna de Sherlock Holmes. Ao rastrear o kernel debug do 3.11 WFW, ele verificou que era um erro de divisão por zero em alguma parte da seção de rede. Essa «alguma parte» acabou sendo NDIS.386, com um problema específico: ao ler o tempo com o comando Get_System_Time seguido por 1.048.576 iterações de LOOP, a precisão máxima é de um milissegundo. Agora, se for mais rápido que isso… o início e o fim podem ser os mesmos, com uma diferença zero, à qual não se pode dividir. Em um processador de 100 MHz ou mais lento isso nunca seria problemático, mas em um chip de 350 MHz, puro caos.
No caso do Windows 95, o problema surge novamente com NDIS.VXD, e uma lógica semelhante aparecia em IOS.VXD, ESDI_506.PDR e SCSIPORT.PDR. Por que os chips Intel pareciam imunes? Em essência, por as diferenças na velocidade de execução do LOOP: um chip K6-2 de 350 MHz era seis vezes mais rápido que seu equivalente em Pentium II. À medida que os chips de Santa Clara ganharam velocidade, o erro se tornou mais frequente (por exemplo, Pentium 4).
A história continua com a Microsoft... sendo a Microsoft. O erro foi corrigido nos drivers de armazenamento do Windows 98 (primeira edição), mas no NDIS ainda estava lá, e o mesmo aconteceu com o patch para o Windows 95 OSR2. O hotfix do NDIS chegou em 2001 (ano em que o XP estreou) e somente para o Windows 98, porém, a famosa Segunda Edição resolveu todos esses problemas pela raiz.
https://old.neoteo.com/windows-98-online-y-en-tu-navegador/Michal encerra seu artigo com uma conclusão muito interessante: nenhuma avaliação teria sido capaz de detectar o bug quando o código foi escrito. «O que acontece se o LOOP executar em menos de um milissegundo?» não era algo que os engenheiros da época tivessem bem no topo de sua lista de prioridades.
E também há o risco de assumir. O mercado passou de um Pentium de 66 MHz para um K6-2 de 350 MHz em apenas cinco anos, reduzindo o LOOP de 100 milissegundos para menos de três. Os desenvolvedores de software assumiram que um salto de desempenho tão grande não seria possível, e os de hardware, que acelerar a execução de instruções sempre é algo bom.
Acesse o artigo: Clique aqui
