Windows 95 guardaba un pequeño secreto que aceleraba el reinicio. La razón estaba en su arquitectura más caótica

Si antes de Windows 95 usaste otros sistemas operativos, es difícil no recordar la sensación de estar ante algo completamente nuevo. Aquella propuesta introdujo elementos que hoy damos por sentados, como el menú Inicio, la barra de tareas o el Plug and Play, y lo hizo en una época en la que arrancar un PC era casi un pequeño ritual. Pero bajo esa interfaz tan familiar se escondía una arquitectura compleja, fruto de la convivencia forzada entre herencias de DOS, Windows de 16 bits y las primeras capas de 32 bits. Ese diseño, tan poco elegante como eficaz, dio lugar a comportamientos inesperados que todavía hoy sorprenden.

Pocos usuarios sabían que Windows 95 escondía una ruta alternativa al reinicio clásico. Bastaba con mantener pulsada la tecla Shift durante el proceso iniciado desde la interfaz gráfica para que el sistema mostrara el aviso «Windows se está reiniciando», en lugar de seguir el camino de un reinicio en frío, tal y como describe Raymond Chen. La diferencia no era espectacular, pero sí perceptible en una época en la que cada minuto de arranque contaba. Ese pequeño gesto activaba un mecanismo interno pensado para evitar, siempre que fuera posible, empezar desde cero.

El atajo que no reiniciaba del todo

Detrás de ese comportamiento había una decisión técnica precisa. Chen detalla que Windows 95 utilizaba una bandera llamada EW_RESTARTWINDOWS al invocar la antigua función ExitWindows, todavía de 16 bits. Con esa instrucción, el sistema no ordenaba un reinicio en frío del ordenador, sino algo más limitado: cerrar Windows y volver a arrancarlo. El objetivo era ahorrar pasos, siempre que la situación interna lo permitiera, aunque esa optimización dependía de que todo encajara correctamente.

Una vez tomada esa ruta alternativa, el proceso seguía una secuencia muy concreta. Primero se cerraba el kernel de Windows de 16 bits. A continuación se apagaba el gestor de memoria virtual de 32 bits y el procesador volvía al modo real, el estado más básico del sistema. En ese punto, el control regresaba a win.com con una señal especial que pedía algo muy específico: volver a iniciar Windows en modo protegido sin pasar por un arranque completo del equipo.

Con el control de nuevo en win.com, comenzaba la parte más frágil del proceso. El programa debía simular un arranque limpio de Windows, como si acabara de ejecutarse desde cero, lo que implicaba, en palabras de Chen, resetear las opciones de la línea de comandos y devolver algunas variables globales a sus valores originales. Aunque el trabajo era en gran medida clerical, resultaba especialmente complejo porque win.com estaba escrito en ensamblador. No había abstracciones ni comodidades modernas.

El punto decisivo estaba en la memoria. Cuando win.com se ejecutaba, como cualquier archivo .com, recibía toda la memoria convencional disponible. Sin embargo, liberaba casi toda la memoria más allá de su propio código para que Windows pudiera cargar un gran bloque contiguo al entrar en modo protegido. Si durante la sesión algún programa reservaba memoria dentro del espacio que win.com había dejado libre, la memoria quedaba fragmentada. En ese escenario, win.com ya no podía recrear el mapa original que esperaba, y, según explica Chen, se veía obligado a abandonar el reinicio rápido y caer en un reinicio completo.

Cuando todo encajaba, el proceso continuaba sin volver atrás. win.com saltaba directamente al código encargado de arrancar Windows en modo protegido, recreando el gestor de máquinas virtuales y levantando de nuevo las capas de 32 bits. Desde ahí, la interfaz gráfica se cargaba como de costumbre y el usuario volvía al escritorio. La diferencia era sutil pero real: Windows no había tenido que reiniciar el sistema completo para llegar hasta ese punto.

Este tipo de atajos solo era viable en un sistema construido a base de compatibilidades cruzadas. Windows 95 tenía que convivir con software de DOS, programas de Windows de 16 bits y aplicaciones Win32, y esa mezcla obligó a aceptar soluciones poco elegantes pero muy prácticas. Los desarrolladores llegaron a aprovechar esa complejidad para introducir optimizaciones ocultas que podían acelerar el reinicio, aunque a veces podían terminar en cuelgue.

La obsesión por ahorrar memoria llevaba a soluciones muy imaginativas. Chen explica que en ensamblador era común reciclar código que ya no se iba a usar como si fuera memoria libre. En win.com, los primeros bytes del punto de entrada se reutilizaban como una variable global, bajo la premisa de que ese código solo se ejecutaba una vez. Dado que el reinicio rápido no regresaba a ese punto inicial, el sistema podía permitirse ese atajo sin que afectara al proceso.

Ese atajo también mostraba sus costuras. Chen recuerda que algunos usuarios detectaron fallos tras realizar varios reinicios rápidos consecutivos, algo que él no consiguió reproducir de forma sistemática. Su hipótesis es que algún controlador no se reiniciaba correctamente, dejaba el sistema en un estado extraño, y esa rareza terminaba pasando factura más tarde. No extraña que este tipo de comportamiento no se presentara como una función documentada, pero resume bien el espíritu de Windows 95: ingenioso, ambicioso y lleno de compromisos.

Imágenes | Microsoft

.

Javier Marquez

Fuente de esta noticia: https://www.xataka.com/aplicaciones/windows-95-guardaba-pequeno-secreto-que-aceleraba-reinicio-razon-estaba-su-arquitectura-caotica

También estamos en Telegram como @prensamercosur, únete aquí: https://t.me/prensamercosur Mercosur

Recibe información al instante en tu celular. Únete al Canal del Diario Prensa Mercosur en WhatsApp a través del siguiente link: https://www.whatsapp.com/channel/0029VaNRx00ATRSnVrqEHu1W