Por qué las viejas versiones de Windows no funcionan en CPUs modernas: son demasiado rápidas

Una persona llamada Michal Necasek investigó la causa del problema después de que un conocido le comentara que [no podía ejecutar Windows 3.11 en una máquina virtual sobre un sistema con un CPU AMD Ryzen 7 3800X (lanzado en 2019)]. (En inglés)

Según la investigación, la causa estaba en la lógica de calibración del retardo por bucle dentro del módulo NDIS (Network Driver Interface Specification). Esa lógica funcionaba de la siguiente manera.

1. Al iniciar, obtiene la hora actual en milisegundos.

2. Ejecuta la instrucción LOOP 2^20 (=1,048,576) veces.

3. Vuelve a obtener la hora actual en milisegundos y le resta la hora inicial para calcular el tiempo transcurrido.

4. Calcula [2^20 / tiempo transcurrido] para obtener cuántos bucles se ejecutan por milisegundo.

El problema era que, si el bucle de 2^20 iteraciones terminaba en menos de 1 milisegundo, el tiempo transcurrido se calculaba como 0 milisegundos, lo que provocaba un error de [división entre cero]. Por eso fallaba el arranque. En 1993, cuando Windows 3.11 estaba siendo desarrollado y lanzado, el CPU más rápido de la plataforma PC era el Intel Pentium de 66 MHz. Si se hace el cálculo, incluso en el mejor de los casos ese procesador habría tardado más de 94 milisegundos en completar esa cantidad de bucles. Esto también se debía a que los procesadores de la época no podían ejecutar la instrucción LOOP en un solo ciclo. Pero los CPU modernos, considerando tanto la velocidad de reloj como los ciclos por instrucción y otros factores, son simplemente demasiado rápidos para ejecutar estos sistemas operativos antiguos.

En el texto original también aparecen otros detalles interesantes. Se explica, por ejemplo, que en Windows 95 la lógica anterior fue modificada un poco y se usó en más lugares, y que en procesadores Intel la ejecución de esa lógica todavía tardaba 6 milisegundos incluso en un Pentium III de 1 GHz, mientras que en procesadores AMD el problema aparecía ya en un K6-2 de 350 MHz, lo que muestra que la aparición del fallo variaba según diferencias en el funcionamiento interno del CPU. Como referencia, este problema no quedó completamente resuelto sino hasta Windows 98 SE, lanzado en 1999.