En la década de 1990, encender una computadora era un ritual que requería paciencia. Los usuarios de la época recuerdan con nostalgia el sonido característico del disco duro y la pantalla de inicio que anunciaba la llegada de Windows 95. Este sistema operativo no solo introdujo elementos revolucionarios como el menú Inicio y la barra de tareas, sino que también escondía peculiaridades técnicas que, décadas después, siguen sorprendiendo a expertos y entusiastas.
La arquitectura de Windows 95 era un mosaico de tecnologías heredadas y nuevas. Por un lado, mantenía compatibilidad con DOS y aplicaciones de 16 bits; por otro, daba sus primeros pasos hacia los 32 bits. Esta convivencia forzada generó un diseño complejo y, en ocasiones, caótico, pero también permitió optimizaciones ingeniosas. Una de ellas era un mecanismo oculto que aceleraba el proceso de reinicio, algo invaluable en una época donde cada segundo de arranque contaba.
Según Raymond Chen, experto en sistemas operativos y antiguo desarrollador de Microsoft, Windows 95 incluía una ruta alternativa para reiniciar sin necesidad de un “reinicio en frío”. Los usuarios que mantenían presionada la tecla Shift durante el proceso iniciado desde la interfaz gráfica veían un mensaje diferente: “Windows se está reiniciando”. Este pequeño gesto activaba un procedimiento interno diseñado para evitar comenzar desde cero siempre que fuera posible.
Detrás de esta funcionalidad había una decisión técnica precisa. Windows 95 utilizaba una bandera llamada EW_RESTARTWINDOWS al invocar la función ExitWindows, heredada de versiones anteriores de 16 bits. Esta instrucción no ordenaba un reinicio completo del hardware, sino algo más limitado: cerrar Windows y volver a iniciarlo. El objetivo era ahorrar pasos, optimizando el tiempo siempre que la situación interna lo permitiera.
El proceso de reinicio rápido seguía una secuencia meticulosa. Primero, se cerraba el kernel de Windows de 16 bits. Luego, se apagaba el gestor de memoria virtual de 32 bits y el procesador regresaba al modo real, el estado más básico del sistema. En este punto, el control volvía a win.com con una señal especial que solicitaba reiniciar Windows en modo protegido sin pasar por un arranque completo del equipo.
Con el control nuevamente en win.com, comenzaba la parte más delicada del proceso. Este programa, escrito en ensamblador, debía simular un arranque limpio de Windows, como si acabara de ejecutarse desde cero. Esto implicaba resetear las opciones de la línea de comandos y devolver algunas variables globales a sus valores originales. La ausencia de abstracciones modernas hacía que esta tarea fuera especialmente compleja.
La memoria jugaba un papel crucial en este mecanismo. Cuando win.com se ejecutaba, recibía toda la memoria convencional disponible, pero liberaba casi todo el espacio 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 se veía obligado a abandonar el reinicio rápido, cayendo en un reinicio completo.
Cuando todo encajaba perfectamente, el proceso continuaba sin contratiempos. win.com saltaba directamente al código encargado de arrancar Windows en modo protegido, recreando el gestor de máquinas virtuales y levantando nuevamente las capas de 32 bits. Desde ahí, la interfaz gráfica se cargaba como de costumbre y el usuario regresaba 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 aprovecharon esta complejidad para introducir optimizaciones ocultas que podían acelerar el reinicio, aunque a veces conllevaban riesgos de inestabilidad.
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 afectar el proceso.
Sin embargo, este 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, dejando el sistema en un estado extraño que terminaba pasando factura más tarde.
No es extraño que este comportamiento no se presentara como una función documentada. Windows 95 era un producto de su tiempo: ingenioso, ambicioso y lleno de compromisos. Su arquitectura, aunque caótica, permitió innovaciones que sentaron las bases para sistemas operativos modernos. Hoy, en la era de los reinicios instantáneos y las actualizaciones en segundo plano, recordar estos detalles técnicos nos ayuda a apreciar el largo camino recorrido en la evolución de la informática.
La historia de Windows 95 es un testimonio de cómo la necesidad de compatibilidad puede impulsar soluciones creativas, incluso cuando estas implican asumir ciertos riesgos. Aunque hoy sus mecanismos parecen arcaicos, en su momento representaron un avance significativo en la búsqueda de eficiencia y velocidad, valores que siguen siendo centrales en el desarrollo tecnológico actual.
