En octubre de 2026, el medio tecnológico Windows Latest sacó a la luz una curiosidad técnica fascinante: en lo más profundo del moderno sistema Windows 11 26H2 sigue descansando código de gestión de memoria escrito originalmente para Windows 95. Lejos de haber sido eliminado, Microsoft lo recompiló con herramientas modernas y lo integró en la capa de compatibilidad del sistema. Su único propósito es dar soporte a programas con tres décadas de antigüedad que gestionaban la memoria de forma incorrecta.
Para Microsoft, la compatibilidad hacia atrás se traduce a menudo en preservar de manera permanente copias de código fuente histórico. Al encapsular estos módulos antiguos dentro del sistema moderno, los fallos de programación del pasado quedan convertidos en contratos inmutables del sistema operativo. Cada ordenador que ejecuta hoy Windows 11 sigue asumiendo el coste de aquellos compromisos comerciales adoptados hace más de treinta años.
En la caja de herramientas de Windows 11: código vivo de Windows 95
Descubrir este fósil viviente en Windows 11 26H2 no exige conocimientos avanzados de ingeniería inversa. Basta con instalar el paquete oficial Windows ADK de Microsoft, marcar la opción «Application Compatibility Tools» y abrir el Administrador de Compatibilidad de 32 bits. En la amplia lista de correcciones del sistema destaca un ajuste denominado EmulateHeap.
Figura: La opción de compatibilidad EmulateHeap en el Administrador de Compatibilidad de Windows 11. Fuente: Windows Latest
El funcionamiento de EmulateHeap es directo y contundente: cuando se activa para una aplicación antigua, el sistema toma el control de sus llamadas a la memoria de montón (heap). Desde funciones de reserva como HeapCreate hasta bloqueos con LocalLock o reasignaciones mediante GlobalReAlloc, todas las instrucciones se redirigen a una implementación especial. El comportamiento de este módulo reproduce con absoluta fidelidad el funcionamiento de Windows 95.
Microsoft descartó simular este comportamiento mediante heurísticas modernas. Según los registros compartidos por el veterano ingeniero de Microsoft Raymond Chen, el equipo extrajo directamente el código fuente original del gestor de memoria de Windows 95, lo recompiló y lo empaquetó dentro de la capa de compatibilidad. Microsoft renunció a la emulación de conducta y optó por el código original para eliminar cualquier riesgo de incompatibilidad imprevista. De este modo, aquellas instrucciones de máquina escritas hace 31 años consiguieron un lugar permanente y legal dentro del sistema operativo moderno.
Salvar SimCity: cuando Microsoft asumió los errores de los desarrolladores
Este parche, aparentemente insólito, nació de una batalla comercial decisiva hace tres décadas. En 1995, con el lanzamiento de Windows 95 a la vuelta de la esquina, el exitoso juego de PC SimCity sufría cierres inesperados continuos en las máquinas de prueba. Si el nuevo sistema operativo no lograba ejecutar uno de los títulos más populares del mercado, los usuarios culparían irremediablemente al propio sistema, no al juego.
Figura: SimCity 2000, el simulador de gestión urbana que conquistó el mundo. Fuente: Nap’n’Retrogaming
Tras investigar a fondo, los ingenieros de Microsoft descubrieron que el problema residía por completo en el código del juego. El propio desarrollador de SimCity, Jon Ross, reconoció posteriormente que el programa sufría un clásico error de uso tras liberación (use-after-free): el juego liberaba un bloque de memoria devolviéndoselo al sistema operativo, pero acto seguido continuaba leyendo los datos residuales de esa misma dirección.
En la época de Windows 3.x, una arquitectura de memoria muy básica ocultaba este peligroso fallo. El sistema de 16 bits utilizaba multitarea cooperativa; cuando una aplicación liberaba memoria, el sistema no borraba ni reasignaba inmediatamente esas direcciones físicas. Los datos antiguos permanecían intactos y el juego funcionaba por pura casualidad. Sin embargo, Windows 95 introdujo la multitarea apropiativa y un gestor de memoria de 32 bits en el que la memoria liberada se marcaba o sobreescribía de inmediato, lo que provocaba el cierre fulminante del juego.
El antiguo director de programas de Microsoft Joel Spolsky desveló la historia en un célebre artículo en el año 2000: en lugar de exigir un parche urgente al estudio Maxis, Microsoft añadió una rutina específica de detección en el asignador de memoria del núcleo de Windows 95. En cuanto el sistema detectaba que el proceso en ejecución correspondía a SimCity, la memoria pasaba a gestionarse en un modo especial que retrasaba la liberación efectiva de los bloques. Para garantizar una transición comercial sin fricciones, el sistema operativo asumió voluntariamente los defectos del software de terceros.
Convertir vulnerabilidades en normas: de parche provisional a contrato inmutable
Fallos similares abundaban en el software de mediados de los años noventa. El auge del mercado del PC provocó la llegada masiva de aplicaciones de 32 bits desarrolladas a toda prisa y repletas de anomalías de memoria. Muchos programadores, acostumbrados a la permisividad de Windows 95, asumieron erróneamente que poder leer memoria liberada era una característica oficial del sistema operativo.
A medida que la arquitectura Windows NT sustituyó por completo a la línea 9x, Microsoft introdujo un sistema de memoria mucho más riguroso y seguro para entornos empresariales. Esto provocó que cientos de juegos antiguos y herramientas corporativas dejaran de funcionar. Resultaba inviable introducir condiciones especiales en el núcleo para cada aplicación del mercado. Ante la disyuntiva de mantener la pureza arquitectónica o preservar un ecosistema colosal, el equipo de ingeniería optó por un compromiso práctico.
Figura: El recorrido de preservación del código de memoria de Windows 95 en la capa moderna de compatibilidad. Fuente: Windows Latest
Los ingenieros aislaron por completo el componente de gestión de memoria del árbol de código fuente de Windows 95 y lo convirtieron en un complemento independiente de compatibilidad denominado EmulateHeap. Desde una perspectiva estricta de seguridad, el uso tras liberación es un fallo grave que puede facilitar la ejecución arbitraria de código. Sin embargo, ante la realidad comercial del mercado de escritorio, la retrocompatibilidad se impuso al rigor del diseño de sistemas. Microsoft convirtió así los defectos de antaño en un compromiso permanente de su sistema operativo.
Modernizar la interfaz con WinUI 3 sin soltar los módulos de 1995
Esta devoción por la compatibilidad da lugar a contrastes técnicos asombrosos. En la superficie, Microsoft renueva activamente el diseño visual de Windows: incluso los cuadros de diálogo de propiedades de archivo, casi inalterados durante décadas, están migrando al moderno marco WinUI 3. Asimismo, para atajar de raíz los fallos de seguridad en memoria, la compañía está introduciendo Rust en el núcleo de Windows.
No obstante, bajo esta moderna fachada, las cargas históricas se conservan intactas. Incluso en 2026, con la versión 26H2 de Windows 11, Microsoft sigue recurriendo a su infraestructura moderna de compilación para generar el binario del gestor de memoria de Windows 95 y distribuirlo en las imágenes oficiales del sistema. En cambio, programas tan queridos por los usuarios como el mítico juego Pinball 3D fueron eliminados sin miramientos.
El motivo por el cual Pinball 3D no dio el salto a los 64 bits fue puramente pragmático: su sistema de detección de colisiones estaba escrito íntegramente en ensamblador x86 de 32 bits y carecía de documentación sobre las operaciones de punto flotante. Al compilarlo en 64 bits, la bola atravesaba las palas de forma continua. Como depurar el problema habría requerido varios días de trabajo, Microsoft decidió descartarlo. La tolerancia de Microsoft hacia el código heredado tiene límites muy claros: las aplicaciones accesorias se pueden descartar, pero los cimientos de la compatibilidad son sagrados.
Tres décadas de concesiones: la factura que paga el hardware moderno
A pesar del esfuerzo de Microsoft por conservar este código antiguo, sus efectos empiezan a desvanecerse en el hardware moderno. A partir de Windows 11 22H2 y versiones posteriores, la comunidad del juego retro ha comprobado que EmulateHeap falla cada vez más a menudo. Al intentar ejecutar títulos clásicos como Grand Theft Auto: Vice City o Need for Speed: Most Wanted con esta opción activa, los juegos pierden habitualmente canales de sonido o se cierran con errores nada más arrancar.
La causa reside en que las arquitecturas de PC actuales están muy lejos de las suposiciones de 1995. Los ordenadores modernos cuentan con múltiples núcleos, complejas canalizaciones de ejecución fuera de orden y estrictos mecanismos de aislamiento de memoria por hardware. El gestor de memoria de Windows 95 fue concebido para una época de un solo núcleo y memoria plana; sencillamente, no puede interactuar con fluidez con controladores modernos y entornos multiproceso complejos.
La retrocompatibilidad sin límites otorgó a Windows una posición comercial casi inexpugnable, pero también acumuló una deuda técnica monumental. Con cada avance arquitectónico, Microsoft se ve obligada a cargar con el peso del pasado. Lo que hace treinta años empezó como un parche provisional se ha transformado en un fósil digital permanente. Cuando la tecnología evoluciona más allá de los supuestos originales, complacer indefinidamente al pasado termina por convertirse en una pesada carga para los usuarios actuales.
Enlaces de referencia:
- Reportaje de Windows Latest: Por qué Windows 11 aún incluye el gestor de memoria de Windows 95
- Joel on Software: Strategy Letter II: Chicken and Egg Problems
- Documentación técnica de Microsoft: Análisis de los mecanismos de EmulateHeap en la columna de compatibilidad de Windows
