- WSL9x adapta la idea del Subsistema de Windows para Linux a Windows 95, 98 y ME con un enfoque experimental
- El proyecto modifica el kernel de Linux y usa un controlador VxD para comunicarse con las APIs de Windows 9x
- No ofrece entorno gráfico, solo terminal, y opera con privilegios de máximo nivel, con impacto en estabilidad y seguridad
- Es una pieza de arqueología informática que ilustra el potencial de la interoperabilidad y la preservación de sistemas legacy
La idea de mezclar Linux con el vetusto Windows 95 o 98 sonaba hasta hace nada a fantasía de laboratorio. Sin embargo, un proyecto de código abierto llamado WSL9x se ha propuesto precisamente eso: llevar la filosofía del actual Subsistema de Windows para Linux a los sistemas Windows de finales de los noventa.
Hablamos de una iniciativa abiertamente experimental, lejos de las soluciones pulidas que ofrece hoy Microsoft con WSL2 en Windows 10 y 11. Aun así, el proyecto ha despertado mucho interés en la comunidad técnica europea porque combina arqueología informática, ingeniería de bajo nivel y una reflexión de fondo sobre hasta dónde puede estirarse la retrocompatibilidad de Windows.
Qué es exactamente WSL9x y quién está detrás del proyecto
WSL9x, siglas de Windows 9x Subsystem for Linux, es un desarrollo independiente que busca reproducir el concepto de WSL en los antiguos Windows 95, 98 y ME, una familia de sistemas que Microsoft abandonó hace más de dos décadas. Su autora principal, conocida como Hailey o hails en la red, se define como aficionada a la informática y hacker, y ha ido documentando los avances en plataformas como Codeberg y redes sociales descentralizadas.
La idea central es permitir que un kernel de Linux moderno conviva dentro de Windows 9x sin recurrir a una máquina virtual tradicional ni a un arranque dual. En lugar de eso, se integra como un subsistema que coopera con el sistema anfitrión, muy en la línea conceptual de lo que hace WSL en Windows 10 y 11, pero adaptado a unas bases técnicas mucho más rudimentarias.
En la práctica, WSL9x pretende que quien siga aferrado a entornos Windows 95 o 98 por motivos de estudio, preservación o simple curiosidad, pueda disponer de un entorno de herramientas Linux accesible desde la propia sesión de Windows. Eso sí, hablamos siempre de un uso muy especializado, nada orientado al usuario doméstico medio.
El repositorio del proyecto, publicado bajo una licencia de código abierto, contiene una mezcla de C y ensamblador que deja ver el grado de ingeniería inversa necesario para encajar Linux en una arquitectura que nunca estuvo pensada para algo así.
Del WSL oficial a WSL9x: misma filosofía, tiempos muy distintos
Para entender por qué WSL9x resulta tan llamativo conviene recordar qué es el Windows Subsystem for Linux oficial. Microsoft lanzó WSL en 2016 como una capa de compatibilidad que permite ejecutar binarios de Linux dentro de Windows 10 y 11, sin máquinas virtuales al uso y con acceso directo al sistema de archivos y a las herramientas de desarrollo.
Con el tiempo, WSL evolucionó hasta WSL2, que en 2019 incorporó un kernel de Linux completo y de código abierto integrado en Windows 10. Esa decisión acercó a muchos desarrolladores al ecosistema Windows, ya que podían usar utilidades, scripts y entornos típicamente Linux sin abandonar el escritorio habitual de Microsoft.
WSL9x intenta trasladar la misma lógica a un contexto radicalmente distinto: Windows 95, 98 y ME no se basan en el kernel NT que sustenta a los Windows modernos, sino en una arquitectura híbrida de 16 y 32 bits con importantes limitaciones de memoria, protección y gestión de procesos.
Mientras WSL aprovecha infraestructuras de virtualización modernas y APIs bien definidas, WSL9x se ve obligado a reconstruir desde cero buena parte del comportamiento esperado por Linux, incluyendo la gestión de llamadas al sistema y el manejo de memoria. Es aquí donde aparece el componente más creativo del proyecto.
Esta comparación deja claro que, aunque WSL y WSL9x compartan espíritu, solo el primero tiene vocación de herramienta de uso diario. El segundo se sitúa más bien en el terreno del experimento técnico y de la demostración de que las ideas de interoperabilidad se pueden llevar mucho más atrás en el tiempo de lo que cabría esperar.
Cómo consigue WSL9x ejecutar un kernel de Linux en Windows 95 y 98
La documentación de WSL9x describe una arquitectura apoyada en tres componentes clave. El primero es un kernel de Linux modificado de forma específica para Windows 9x, capaz de invocar las APIs del sistema anfitrión en lugar de apoyarse en el comportamiento POSIX estándar.
El segundo pilar es un controlador VxD (Virtual Device Driver), un tipo de driver típico de aquella generación de Windows que opera en anillo 0, con privilegios de máximo nivel. Este componente se encarga de la inicialización del subsistema y de gestionar eventos desde el espacio de usuario que deben ser reenrutados al kernel de Linux, como fallos de página o llamadas al sistema.
El tercer elemento es un cliente muy ligero, descrito como un programa DOS de 16 bits, que actúa como puente entre la consola de Windows y el subsistema Linux. Su función principal es ofrecer una terminal que hace de TTY para el kernel, de manera que el usuario pueda introducir comandos y recibir la salida dentro del entorno de Windows 9x.
El truco más llamativo está en cómo se implementa el manejo de syscalls de Linux en una arquitectura tan limitada. Windows 9x no dispone de una tabla de descriptores de interrupción lo bastante extensa como para instalar un controlador estándar, así que WSL9x recurre al manejador general de fallos de protección (GPF).
Cuando el sistema detecta una instrucción concreta asociada a la interrupción 0x80 —la llamada clásica de Linux para invocar funciones del kernel—, el controlador GPF de WSL9x intercepta la situación, adelanta el puntero de instrucción y redirige la supuesta “falla” como una llamada legítima al kernel Linux. A efectos prácticos, Windows trata esa instrucción como si hubiese sido procesada correctamente, aunque por debajo quien responde es Linux.
Experiencia de uso: terminal integrada, sin escritorio gráfico
Desde el punto de vista del usuario, lo que ofrece WSL9x se parece a una ventana de terminal integrada en Windows 95 o 98. No hay entorno de escritorio de Linux, ni gestor de ventanas ni aplicaciones gráficas: todo se reduce a comandos de consola, tal y como ocurría en las primeras versiones de WSL antes de la llegada masiva de soporte gráfico.
Esto implica que para sacar partido a WSL9x hay que sentirse cómodo con operar Linux desde la línea de comandos, algo que puede resultar natural a administradores de sistemas, entusiastas de la retroinformática o estudiantes de ingeniería, pero que de entrada excluye al grueso de usuarios domésticos.
Hailey ha explicado que el objetivo nunca ha sido producir un subsistema listo para el día a día, sino construir una demostración funcional de convivencia entre ambos kernels. El propio cliente de WSL9x, al ser un sencillo ejecutable DOS de 16 bits, deja claro que estamos más cerca de un experimento académico que de una solución de productividad.
Pese a todo, la posibilidad de escribir comandos Linux y ver su resultado directamente en un Windows 95 ejecutándose en hardware antiguo o en una máquina virtual resulta especialmente sugerente para quienes investigan sistemas operativos o quieren comprender cómo se articula la compatibilidad entre plataformas que, sobre el papel, no deberían entenderse entre sí.
Además, el proyecto sirve de recordatorio de hasta qué punto el ecosistema Windows ha favorecido, a veces por decisión de Microsoft y a veces por presión de la comunidad, una retrocompatibilidad casi obsesiva con software y APIs de otra época.
Limitaciones, riesgos y carácter puramente experimental
Uno de los puntos en los que más insiste la propia desarrolladora es en las limitaciones de seguridad y estabilidad del invento. El kernel de Linux que se ejecuta bajo WSL9x opera con privilegios ring 0, los mismos que utiliza el núcleo de Windows 9x, lo que significa que cualquier fallo grave en uno puede arrastrar al otro y provocar cuelgues completos del sistema.
A eso se suma que Windows 95, 98 y ME nunca destacaron precisamente por su robustez en comparación con el posterior Windows 2000 o con los Windows NT modernos. La gestión de memoria de 32 bits, las restricciones de los controladores VxD y la ausencia de mecanismos avanzados de aislamiento hacen que cualquier experimento a tan bajo nivel deba tratarse con cautela.
Por todo ello, WSL9x está pensado para ejecutarse preferentemente en entornos de prueba controlados, como máquinas virtuales o equipos dedicados a la experimentación, y no sobre instalaciones críticas con datos importantes. No hay garantías de que el sistema responda bien ante cargas intensivas, software poco habitual o combinaciones de hardware exóticas.
Otro freno importante es el ecosistema extremadamente reducido de usuarios de Windows 9x a estas alturas. Aunque exista una comunidad activa de retroinformática en Europa y España, la mayoría de entornos empresariales migraron hace años a versiones más modernas de Windows o a otros sistemas, de modo que WSL9x no aspira a cubrir una necesidad masiva.
Aun así, desde la óptica de la ingeniería de sistemas, el proyecto aporta valor como laboratorio para entender qué ocurre cuando se mezclan código contemporáneo, como un kernel Linux 6.x, con plataformas diseñadas en plena década de 1990.
Un ejemplo extremo de interoperabilidad y preservación de sistemas legacy
Aunque WSL9x no sea una solución práctica para el día a día, sí ilustra hasta qué punto la interoperabilidad entre sistemas antiguos y modernos se ha convertido en un tema relevante, sobre todo en empresas europeas con infraestructura heredada y en instituciones que trabajan en preservación digital.
En museos, archivos y organizaciones que mantienen equipos de los 90 y 2000 por motivos de conservación, la posibilidad de crear puentes hacia herramientas contemporáneas es más que una excentricidad. La ingeniería desarrollada para WSL9x, aunque extrema, comparte principios con proyectos que buscan mantener operativo software histórico sin renunciar a funcionalidades actuales.
También es un caso útil para quienes se dedican al testing y la validación de compatibilidad en entornos empresariales. Entender cómo se canalizan llamadas al sistema, cómo se gestionan los fallos de página o cómo interactúan drivers de anillo 0 en plataformas obsoletas puede ayudar a diseñar soluciones más seguras en contextos donde convivir con sistemas legacy es inevitable.
En el ámbito educativo, WSL9x puede convertirse en una herramienta llamativa para enseñar arquitectura de sistemas operativos. Permite mostrar, con ejemplos tangibles, las diferencias entre modelos de protección de memoria, la evolución de los controladores de dispositivo y los distintos enfoques de compatibilidad entre kernels.
Para quienes trabajan en consultoría o desarrollo B2B, el mensaje de fondo es claro: la verdadera oportunidad no está tanto en replicar WSL9x, sino en identificar qué sistemas heredados siguen siendo críticos en sectores concretos y construir soluciones que conecten esos entornos con herramientas modernas sin exigir un reemplazo total.
En un ecosistema tecnológico donde abundan las propuestas similares en torno a la inteligencia artificial, proyectos como WSL9x recuerdan que todavía hay margen para trabajos de ingeniería profunda sobre nichos muy específicos, vinculados a interoperabilidad, preservación y compatibilidad a largo plazo.
Todo lo que rodea a WSL9x muestra que, incluso cuando un proyecto no persigue una adopción masiva ni una aplicación directa en producción, puede aportar una comprensión muy valiosa sobre cómo dialogan distintas generaciones de software y hardware, y sobre el papel que juega la comunidad técnica a la hora de prolongar la vida útil de plataformas que muchos daban por enterradas.