si antes Windows 95 Si utilizaste otros sistemas operativos, es difícil no recordar la sensación de estar ante algo completamente nuevo. Aquella propuesta introducía elementos que hoy damos por sentados, como el menú Inicio, la barra de tareas o el Plug and Play, y lo hacía en una época en la que arrancar un PC era casi un pequeño ritual. Pero debajo de esa interfaz familiar se escondía una arquitectura compleja, resultado de la convivencia forzada entre herencias de DOS, Windows de 16 bits y las primeras capas de 32 bits. Aquel diseño, tan poco elegante como eficaz, dio lugar a comportamientos inesperados que aún hoy sorprenden.
Pocos usuarios sabían que Windows 95 escondía una ruta alternativa al reinicio clásico. Bastaba mantener presionada 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 la ruta de un reinicio en frío, como lo describe Raymond Chen. La diferencia no fue espectacular, pero sí se notó en un momento en el que cada minuto de salida contaba. Ese pequeño gesto activó un mecanismo interno diseñado para evitar, siempre que sea posible, empezar de cero.
El atajo que no se reiniciaba por completo
Detrás de este comportamiento hubo una precisa decisión técnica. Chen detalla que Windows 95 usaba un indicador llamado EW_RESTARTWINDOWS al invocar la antigua función ExitWindows, todavía de 16 bits. Con esa instrucción, el sistema no ordenó un reinicio en frío del ordenador, sino algo más limitado: cierra Windows y reinícialo. El objetivo era ahorrar pasos, siempre que la situación interna lo permitiera, aunque esta optimización dependía de que todo encajara correctamente.
Una vez que se tomó esa ruta alternativa, el proceso siguió una secuencia muy específica. Primero se cerró el kernel de Windows de 16 bits. Luego se apagó el administrador de memoria virtual de 32 bits y el procesador volvió al modo real, el estado más básico del sistema. En ese momento, el control volvió a win.com con una señal especial que pedía algo muy específico: reiniciar Windows en modo protegido sin realizar un arranque completo de la computadora.
Con el control nuevamente en win.com, comenzó la parte más frágil del proceso. El programa tenía que simular un arranque limpio de Windows, como si acabara de ejecutarse desde cero, lo que implicaba, en palabras de Chen, restablecer las opciones de la línea de comandos y devolver algunas variables globales a sus valores originales. Aunque el trabajo era en gran parte administrativo, era especialmente complejo porque win.com Fue escrito en asamblea.. No había abstracciones ni comodidades modernas.
El punto decisivo estuvo en la memoria. Cuando se ejecutó win.com, como cualquier archivo .com, recibió toda la memoria convencional disponible. Sin embargo, liberó casi toda la memoria más allá de su propio código para que Windows pudiera cargar un bloque contiguo grande al ingresar al modo protegido. Si durante la sesión un programa reservaba memoria dentro del espacio que win.com había dejado libre, la memoria se fragmentaba. En ese escenario, win.com ya no pudo recrear el mapa original que esperaba y, explica Chen, se vio obligado a abandonar el reinicio rápido y caer en un reinicio completo.
Cuando todo encajó, el proceso continuó sin vuelta atrás. win.com saltó directamente al código responsable de iniciar Windows en modo protegido, recrear el administrador de la máquina virtual y llevantando las capas de 32 bits nuevamente. A partir de 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 todo el sistema para llegar a ese punto.
Este tipo de atajo sólo era viable en un sistema basado en compatibilidades cruzadas. Windows 95 tuvo que coexistir con software DOS, programas Windows de 16 bits y aplicaciones Win32, y esa combinación nos obligó a aceptar soluciones poco elegantes pero muy prácticas. Los desarrolladores aprovecharon esta complejidad para introducir optimizaciones ocultas que podían acelerar los reinicios, aunque en ocasiones podían provocar fallos.
La obsesión por salvar la memoria llevó a soluciones muy imaginativas. Chen explica que en ensamblador era común reciclar código que ya no se iba a utilizar como si fuera memoria libre. En win.com, los primeros bytes del punto de entrada fueron reutilizados como variable globalbajo la premisa de que este código solo se ejecutó una vez. Dado que el reinicio rápido no volvió a ese punto inicial, el sistema podría permitir ese atajo sin afectar el proceso.
Ese atajo también mostró sus costuras. Chen recuerda que algunos usuarios detectaron errores tras realizar varios reinicios rápidos consecutivos, algo que no pudo reproducir de forma consistente. Su hipótesis es que algún controlador no se reiniciaba correctamente, dejando el sistema en un estado extraño, y esa rareza terminó pasando factura más tarde. No sorprende que este tipo de comportamiento no se haya presentado como una característica documentada, pero resume bien el espíritu de Windows 95: inventivo, ambicioso y lleno de compromisos.
Imágenes | microsoft
En | La Oficina de Schrödinger: a estas alturas es imposible saber si Microsoft la mantiene viva o si todo es IA y Copilot