Los conflictos entre las versiones 9x de Windows y el hardware «moderno» de cada época son mucho más profundos de lo que imaginamos. Aún cuando los fabricantes insistían en declarar que sus productos habían sido «optimizados» para los sistemas operativos de Redmond, los errores que experimentaban los usuarios eran crípticos y frustrantes. Dichos errores se volvieron más frecuentes a medida que los procesadores incrementaron su velocidad, y hoy esos sistemas son muy complicados de ejecutar, con o sin virtualizador. Michal Necasek del OS/2 Museum decidió averiguar por qué…
Si buscas imágenes de viejos procesadores AMD K6-2, notarás un detalle muy particular: El logo de Windows 95 aparece grabado en el spreader. Se supone que esa es una garantía de compatibilidad, la prueba de que esos chips funcionan sin inconvenientes en el sistema operativo de Microsoft. Bueno… digamos que «garantía» y «prueba» son expresiones muy optimistas. Los «Errores de Protección de Windows» eran intermitentes en los K6-2 a 350 MHz, y semipermanentes en modelos más veloces.
Lo más absurdo es que Microsoft y AMD casi terminan en guerra por eso: Redmond quería obtener 35 dólares adicionales por el «hotfix» (aunque el objetivo real era que los usuarios adoptaran a Windows 98), y AMD respondió publicando su propio parche, gratis. Los procesadores Intel presentaron cierta resistencia al principio, pero sufrieron problemas similares más tarde: Las versiones 9x de Windows fallaban con procesadores «demasiado rápidos».
Y así llegamos al portal del OS/2 Museum, donde Michal Necasek recibió un mensaje de un conocido, anunciando que Windows 3.11 for Workgroups ya no funcionaba en máquinas virtuales. Los primeros pasos en su investigación revelaron que uno de los principales factores para disparar el error es el procesador. Un Core i7-2600 lo presentaba en raras ocasiones, pero con un Ryzen 7 3800X se volvió constante: Michal escribía «win», aparecía el logo de Windows… y de regreso a DOS.
El resto de la entrada es digna de Sherlock Holmes. Al rastrear el kernel debug de 3.11 WFW, comprobó que era un error de división por cero en alguna parte de la sección de red. Esa «alguna parte» resultó ser NDIS.386, con un problema específico: Al leer el tiempo con el comando Get_System_Time seguido por 1.048.576 iteraciones de LOOP, la precisión máxima es de un milisegundo. Ahora, si es más rápido que eso… el principio y el fin podría ser el mismo, con una diferencia cero, a la que no se puede dividir. En un procesador de 100 MHz o más lento esto jamás sería conflictivo, pero en un chip de 350 MHz, puro caos.
En el caso de Windows 95, el inconveniente surge de nuevo con NDIS.VXD, y una lógica similar aparecía en IOS.VXD, ESDI_506.PDR y SCSIPORT.PDR. ¿Por qué los chips Intel parecían inmunes? En esencia, por las diferencias en la velocidad de ejecución del LOOP: Un chip K6-2 de 350 MHz era seis veces más rápido que su equivalente en Pentium II. A medida que los chips de Santa Clara ganaron velocidad, el error se volvió más frecuente (ej., Pentium 4).
La historia sigue con Microsoft… siendo Microsoft. El error fue corregido en los controladores de almacenamiento de Windows 98 (primera edición), pero en NDIS seguía allí, y lo mismo sucedió con el parche para Windows 95 OSR2. El hotfix NDIS llegó en 2001 (año en el que debutó XP) y sólo para Windows 98, sin embargo, la famosa Segunda Edición arrancó todos esos problemas de raíz.
Michal cierra su artículo con una conclusión muy interesante: Ninguna evaluación hubiera sido capaz de detectar el bug cuando el código fue escrito. «¿Qué sucede si LOOP se ejecuta en menos de un milisegundo?» no era algo que los ingenieros de la época tuvieran muy arriba en su lista de prioridades.
Y también está el riesgo de asumir. El mercado pasó de un Pentium de 66 MHz a un K6-2 de 350 MHz en apenas cinco años, bajando el LOOP de 100 milisegundos a menos de tres. Los desarrolladores de software asumieron que semejante salto de rendimiento no sería posible, y los de hardware, que acelerar la ejecución de instrucciones siempre es algo bueno.
Accede al artículo: Haz clic aquí
