- WSL9x ejecuta un kernel Linux 6.19 modificado dentro de Windows 95, 98 y ME sin virtualización clásica ni arranque dual.
- El proyecto se apoya en un kernel parcheado, un driver VxD y un cliente DOS que cooperan usando APIs de Windows 9x como si fueran syscalls de Linux.
- Se trata de un experimento open source inestable y sin interfaz gráfica, pensado para retrocomputing, aprendizaje y preservación digital.
- WSL9x ilustra el potencial de la interoperabilidad con sistemas legacy y el valor del conocimiento profundo de sistemas operativos.
Que alguien haya conseguido arrancar un kernel Linux moderno dentro de Windows 95 suena a chiste contado en una charla de hackers, pero es totalmente real, ejecutable y está publicado como proyecto de código abierto. WSL9x no es un juguete hecho con cuatro scripts, sino el resultado de seis años de trabajo intenso de una desarrolladora empeñada en llevar la idea de WSL a una familia de sistemas que Microsoft abandonó hace décadas.
Si alguna vez pensaste que sería imposible usar Linux en Windows 95, 98 o ME sin máquina virtual, WSL9x viene a demostrar justo lo contrario. Eso sí, no esperes una herramienta pulida para producción ni un sustituto de WSL2: estamos ante una hazaña de ingeniería retrocomputing, inestable por naturaleza, sin entorno gráfico y con muchos compromisos técnicos, pero fascinante para cualquiera a quien le gusten los sistemas operativos por dentro.
Qué es WSL9x y quién está detrás del proyecto
WSL9x, acrónimo de Windows 9x Subsystem for Linux, es un proyecto open source creado por la desarrolladora y hacker Hailey Somerville (también conocida como hails). Su objetivo es permitir que un kernel Linux 6.19 modificado se ejecute de forma cooperativa dentro de Windows 95, Windows 98 y Windows ME, reutilizando las APIs del viejo sistema de Microsoft como si fueran primitivas de sistema para Linux.
La propia autora lo presenta como uno de sus mejores hackeos, y con motivos: lograr que Linux y Windows 9x compartan el mismo procesador, el mismo nivel de privilegio y parte de la gestión de memoria, sin virtualización clásica ni arranque dual, es una auténtica locura técnica. No hablamos de emulación tipo DOSBox ni de una máquina virtual convencional, sino de un subsistema al estilo WSL adaptado a Windows 9x.
El código fuente está publicado en Codeberg, en el repositorio wsl9x, bajo licencia GPL-3. El árbol muestra unos 33 commits en la rama principal, con una combinación de C, ensamblador i386 y algunos ficheros de build. En el README, Hailey deja una frase que se viralizó por toda la comunidad: “Proudly written without AI”, una declaración de intenciones en plena era de programadores asistidos por modelos generativos.
WSL9x es, además, la evolución natural de otro experimento previo de Hailey llamado doslinux, donde ya había conseguido ejecutar binarios Linux sobre DOS mediante un intérprete de llamadas al sistema. Ese trabajo inicial sirvió como base conceptual y técnica para dar el salto desde DOS a Windows 9x y construir un subsistema mucho más ambicioso.
El lanzamiento del proyecto no vino arropado por ninguna gran empresa. Hailey lo anunció con un simple toot en su instancia de Mastodon, enlazando al repositorio de Codeberg. En pocas horas, la noticia llegó a la portada de Hacker News, acumulando más de 700 puntos y más de 160 comentarios, y convirtiéndose en el “proyecto retro del año” para muchos aficionados a los sistemas clásicos.
WSL frente a WSL9x: misma idea, contexto radicalmente distinto
Para entender por qué WSL9x ha generado tanto ruido, conviene comparar su enfoque con el del WSL oficial de Microsoft. En los Windows actuales (10 y 11), WSL nació en 2016 como una capa de compatibilidad que permitía ejecutar binarios Linux directamente sobre el kernel NT, primero traduciendo llamadas al sistema (WSL1) y más tarde integrando un kernel Linux completo vía Hyper-V (WSL2).
WSL se apoya en un ecosistema moderno: kernel NT robusto, memoria protegida decente, soporte de virtualización, drivers contemporáneos, seguridad razonable y un montón de APIs pensadas para interactuar con otros sistemas. Todo esto hace que hoy en día podamos lanzar distribuciones Linux completas en Windows 11, usar aplicaciones de consola, incluso entornos gráficos y herramientas de desarrollo complejas sin salir del escritorio.
En el caso de WSL9x, el escenario no puede ser más diferente. Windows 95, 98 y ME pertenecen a la rama Windows 9x, heredera de MS-DOS y del viejo Windows 3.1. Su diseño es híbrido 16/32 bits, con un modelo de privilegios cooperativo y una arquitectura de memoria bastante frágil. No hay una tabla de descriptores de interrupción tan extensa como en NT, ni mecanismos modernos de seguridad, ni aislamiento serio entre procesos.
A esto se suma que Windows 9x dejó de tener soporte oficial hace más de 20 años, no recibe parches, no tiene drivers recientes y, en general, se considera un fósil viviente en términos de seguridad y mantenimiento. Por eso, la propia idea de llevar un subsistema Linux a esta familia de sistemas parece a primera vista inviable, o como mínimo excesivamente compleja para un solo desarrollador.
Y, sin embargo, WSL9x consigue replicar el espíritu de WSL: un entorno de terminal integrado en Windows desde el cual se pueden ejecutar herramientas Linux, sin recurrir a una máquina virtual clásica ni a un arranque dual. El parecido está en la filosofía de “Linux conviviendo con Windows”; las diferencias, en el tipo de integración, en los trucos de bajo nivel empleados y en las importantes limitaciones prácticas.
Cómo funciona WSL9x por dentro: los tres componentes clave
La arquitectura de WSL9x se puede resumir en tres piezas principales, cada una resolviendo una parte del rompecabezas de meter Linux en Windows 9x sin virtualizar:
- Un kernel Linux 6.19 parcheado para hablar con las APIs de Windows 9x.
- Un driver VxD que hace de puente en modo kernel entre Linux y Windows.
- Un cliente en modo usuario (wsl.com), un pequeño programa DOS de 16 bits que te da la terminal.
El primer bloque es un kernel Linux 6.19 modificado a partir de User-Mode Linux (UML). UML es una variante del kernel que normalmente se ejecuta en espacio de usuario sobre un sistema POSIX, traduciendo sus syscalls a las del host. Hailey ha tomado ese enfoque y lo ha retorcido: en lugar de mapear a POSIX, las llamadas del kernel Linux se redirigen a las APIs propias de Windows 9x, sustituyendo el comportamiento esperado en un entorno moderno.
Ese kernel resultante se compila como vmlinux.elf, pero a diferencia de UML clásico, no se queda en espacio de usuario: acaba corriendo en ring 0, el mismo nivel de privilegio que el núcleo de Windows. Esto implica que no hay aislamiento real entre invitado y anfitrión, y que un fallo grave en cualquiera de los dos puede tumbar el sistema completo sin contemplaciones.
La segunda pieza es un controlador VxD, el formato de driver nativo de la época Windows 9x. Este driver se encarga de cargar el vmlinux.elf desde disco, inicializar el entorno necesario y gestionar la comunicación entre el kernel Linux y el propio Windows. Aquí se encuentra uno de los trucos más ingeniosos del proyecto: cómo lidiar con las llamadas al sistema de Linux en una plataforma que, en teoría, no sabe nada de ellas.
Linux en i386 ha usado tradicionalmente la interrupción 0x80 para disparar syscalls. El problema es que Windows 9x no dispone de una tabla de descriptores de interrupción (IDT) lo bastante grande como para incluir un manejador normal para esa interrupción. WSL9x resuelve este obstáculo aprovechando el controlador general de fallos de protección (GPF): se instala un handler especial que intercepta las instrucciones que provocan un fallo de protección, detecta cuándo se trata de un intento de int 0x80 y, en lugar de dejar que el sistema se caiga, redirige esa “falsa” interrupción al kernel Linux.
De ese modo, cuando un proceso Linux quiere hacer algo (abrir un fichero, reservar memoria, etc.), genera una syscall que en Windows 9x provocaría un fallo de protección general. El driver VxD lo captura, interpreta el contexto, avanza el puntero de instrucción para que la CPU no se quede atrapada, y lo traduce a una operación que el kernel Linux puede procesar realmente, usando por debajo las APIs de Win9x para hacer el trabajo duro.
Además, el VxD es responsable de manejar fallos de página y otros eventos propios del espacio de usuario que necesitan ser reenviados al kernel Linux. Como Windows 9x no tiene una gestión de memoria especialmente sofisticada, todo este mecanismo funciona casi como una especie de coreografía de errores controlados que el driver reconduce hacia el comportamiento esperado por Linux.
La tercera pieza de WSL9x es el cliente en espacio de usuario, wsl.com. Se trata de un pequeño programa DOS de 16 bits que se ejecuta en una ventana de comandos de Windows 95/98/ME y actúa como TTY para el kernel Linux. Es decir, es el encargado de pasar el prompt y la entrada/salida hacia el subsistema Linux, ofreciendo al usuario una experiencia similar al comando wsl.exe en los Windows modernos, pero sobre una consola DOS de toda la vida.
Experiencia de uso: Linux sin interfaz gráfica en un Windows de los 90
El resultado práctico de todo este tinglado es que puedes estar en tu escritorio clásico de Windows 95 o 98, abrir una ventana de MS-DOS y, a través de wsl.com, acceder a una terminal Linux real. No verás entornos de escritorio, ni GNOME, ni KDE, ni aplicaciones gráficas modernas; todo se hace mediante línea de comandos, como si estuvieras conectado a un servidor remoto minimalista.
La propia autora recalca que WSL9x no incluye interfaz gráfica de Linux, ni está pensado para ejecutar aplicaciones de escritorio. La interacción se realiza exclusivamente con la terminal, lo que implica que para sacarle partido necesitarás un mínimo de soltura con comandos, shells y herramientas clásicas de GNU. No es un proyecto para iniciarse en Linux, sino para quienes ya se mueven con comodidad por bash, ls, grep o make.
En estado actual, WSL9x permite trabajar con utilidades básicas y algún que otro programa de consola, siempre que la combinación de hardware, sistema anfitrión y cobertura de llamadas al sistema lo permitan. No está orientado a levantar contenedores, orquestadores ni servicios pesados; de hecho, la propia arquitectura i386 y la ausencia de características modernas hacen prácticamente inviable hacer funcionar Docker, Kubernetes o stacks similares encima.
La instalación y uso tampoco son sencillos: necesitas una imagen de Windows 95, 98 o ME ya instalada, un entorno de compilación con cross compiler i386-linux-musl y Open Watcom v2, y seguir cuidadosamente las indicaciones del README. No hay un instalador mágico ni una ISO preempaquetada lista para descargar y hacer clic, entre otras cosas por las implicaciones legales de redistribuir Windows 9x.
Lo más habitual es recurrir a emuladores y máquinas virtuales especializadas en sistemas antiguos, como 86Box, PCem o DOSBox-X con soporte adecuado para Windows 9x. Esta opción resulta más razonable que montar un PC físico de los 90 y, de paso, añade una capa de seguridad: si algo sale mal, lo único que se rompe es la máquina emulada, facilitando tareas de rescate con herramientas como Rescuezilla.
Estabilidad, seguridad y limitaciones de WSL9x
Desde el punto de vista práctico, WSL9x es, ante todo, un experimento de ingeniería. Hailey lo advierte de forma explícita: el kernel Linux invitado se ejecuta en ring 0, con los mismos privilegios que el kernel de Windows. Esto significa que si uno de los dos falla de forma catastrófica, es muy probable que el otro caiga con él, arrastrando todo el sistema operativo en un bonito pantallazo o cuelgue completo.
Windows 9x, además, no destaca precisamente por su robustez. Su modelo de memoria, su ausencia de aislamiento estricto entre procesos y su dependencia histórica de drivers VxD poco amistosos hacen que cualquier pieza nueva en modo kernel tenga potencial para provocar cuelgues, corrupción de datos o comportamientos imprevisibles. WSL9x no es una excepción; de hecho, añade una buena capa extra de complejidad.
En términos de seguridad, estamos hablando de un entorno sin soporte oficial, sin parches modernos y con un stack de red y drivers llenos de agujeros conocidos. Ejecutar ahí un kernel Linux moderno en modo cooperativo no lo convierte mágicamente en un sistema seguro. De hecho, abre vectores adicionales, porque ahora hay más código crítico corriendo con privilegios máximos.
Por eso, la recomendación obvia es usar WSL9x exclusivamente en entornos de prueba o educativos, nunca para tareas sensibles ni con datos importantes. Lo suyo es montarlo en una máquina virtual, jugar con él, aprender cómo se comporta, probar comandos y scripts, y darlo por bueno como demostración técnica, no como herramienta estable para el día a día.
Otra limitación clave es la cobertura parcial de llamadas al sistema. No todo lo que un Linux 6.19 estándar espera encontrar está implementado o traducido adecuadamente a las APIs de Windows 9x, y eso implica que muchos programas pueden no funcionar, fallar de formas extrañas o directamente negarse a arrancar. La propia naturaleza del proyecto hace que priorizar compatibilidad total no sea el objetivo principal.
Un poco de historia: Windows 95 y su obsesión por la retrocompatibilidad
Parte del encanto de WSL9x está en el contexto histórico al que se engancha. Windows 95 no era simplemente “otro Windows”; era un sistema diseñado para hacer de puente entre el mundo MS-DOS/Windows 3.1 y las nuevas aplicaciones de 32 bits con interfaz gráfica moderna. Microsoft tenía una obsesión clara: que todo lo anterior siguiera funcionando lo mejor posible.
Esto se nota incluso en el propio proceso de instalación de Windows 95, que no era tan directo como hoy. La instalación arrancaba en MS-DOS en modo texto, pasaba después por una versión muy limitada de Windows 3.1 que hacía de lanzadera, detectaba hardware, copiaba archivos y preparaba el entorno hasta que finalmente podía iniciar el nuevo Windows 95 con su escritorio y su menú Inicio. En la práctica, el sistema pasaba por varios mundos diferentes para adaptarse a máquinas muy antiguas y muy nuevas (para la época).
Ese diseño híbrido, que en su día era una solución pragmática a un parque informático caótico, es también la razón por la que hoy podemos plantear locuras como WSL9x. La mezcla de MS-DOS, entornos de 16 bits y capas de 32 bits junto a un modelo de drivers muy flexible (y poco seguro) creó un terreno fértil para hacks profundos que se meten en medio del kernel y hacen cosas que en sistemas más modernos serían impensables.
WSL9x explota precisamente esas características: el hecho de que Windows 9x tenga un manejo “relajado” de fallos de protección, la posibilidad de engancharse al GPF handler, la existencia de drivers VxD que pueden hacer prácticamente de todo en ring 0, y un ecosistema donde la separación entre sistema y aplicaciones no está tan claramente definida como en Windows actuales.
En cierto modo, el proyecto pone en evidencia la curiosa relación de Windows con la retrocompatibilidad: incluso en sistemas que Microsoft dio por muertos hace años, aún quedan suficientes piezas documentadas y maleables como para que una sola persona pueda construir un subsistema Linux encima.
Retrocomputing, open source y el auge de la tecnología vintage
WSL9x no solo llama la atención de frikis de bajo nivel; también encaja en una tendencia más amplia de resurgimiento de la tecnología retro. En los últimos años hemos visto un auge de productos que mezclan estética antigua y funcionalidades modernas: tocadiscos con Bluetooth, cámaras instantáneas con app móvil, consolas clásicas con librerías digitales, teléfonos tipo “concha” reeditados…
Este fenómeno no es pura nostalgia vacía. Los estudios de mercado señalan que las generaciones más jóvenes buscan experiencias más tangibles y menos saturadas que las que ofrece la hiperconectividad constante. Al mismo tiempo, usuarios de más edad encuentran en estos productos un cierto consuelo emocional: recuerdan “tiempos más sencillos” y se sienten cómodos con interfaces familiares, aunque por debajo haya tecnología actual.
En ese contexto, proyectos como WSL9x funcionan casi como artefactos de arqueología informática con esteroides. No tienen necesariamente un modelo de negocio detrás ni un caso de uso masivo, pero sí aportan valor cultural y técnico: preservan conocimientos, muestran hasta dónde se puede estirar la interoperabilidad y sirven de inspiración a nuevas generaciones de desarrolladores.
Además, el hecho de que WSL9x esté publicado como código abierto en una plataforma como Codeberg tiene un impacto claro en términos de comunidad. Abrir el código permite que otros contribuyan parches, reporten errores, propongan nuevas ideas o simplemente estudien la arquitectura para aprender. En Europa, plataformas como Codeberg o GitLab ganan terreno como alternativas a GitHub, reforzando un ecosistema más diverso de hosting de proyectos.
Para startups y empresas tecnológicas, la lección es doble: por un lado, la interoperabilidad con sistemas legacy sigue siendo una oportunidad real en entornos corporativos donde abundan infraestructuras de 10 o 20 años que no se pueden sustituir fácilmente. Por otro, la nostalgia bien gestionada puede convertirse en una forma de diferenciación, siempre que se combine con funcionalidad real y no se quede en una mera fachada estética.
Aplicaciones reales: más allá de la demostración técnica
Aunque WSL9x no tenga vocación de herramienta de producción, la ingeniería que hay detrás se puede aplicar a varios campos con usos muy concretos. Uno de ellos es la preservación digital: museos de informática, archivos históricos o departamentos de IT que mantienen sistemas antiguos pueden beneficiarse de tener herramientas GNU modernas disponibles dentro de entornos de época, sin tener que alterar demasiado la configuración original.
Otra área clara es el testing y control de calidad en productos enterprise que aún deben funcionar en sistemas legacy. Contar con mecanismos que integren componentes modernos en plataformas antiguas, aunque sea parcialmente, puede ayudar a validar compatibilidades, automatizar pruebas o recuperar datos de aplicaciones antiguas sin necesidad de reescribirlo todo desde cero.
En el ámbito educativo, WSL9x ofrece un ejemplo prácticamente perfecto para enseñar arquitectura de sistemas operativos. Permite hablar de llamadas al sistema, manejo de interrupciones, gestión de memoria, niveles de privilegio, drivers en modo kernel y mucho más, todo ello con un caso real y un repositorio navegable que muestra cómo se han solucionado problemas que hoy damos por sentado.
No menos importante es el potencial en consultoría enterprise. Muchas compañías medianas y grandes, especialmente en regiones como Latinoamérica o España, siguen dependiendo de sistemas desplegados hace décadas. Ofrecer soluciones de interoperabilidad, migraciones progresivas o “puentes” entre entornos legacy y modernos es un nicho menos saturado que el enésimo SaaS de moda, y requiere justo el tipo de conocimientos que proyectos como WSL9x ponen sobre la mesa.
Todo esto no convierte a WSL9x en una herramienta mágica para salvar infraestructuras obsoletas, pero sí lo sitúa como una excelente vitrina de lo que se puede hacer combinando ingeniería inversa, paciencia y obsesión por los sistemas. Sirve de recordatorio de que la innovación no siempre consiste en perseguir lo último, sino también en entender profundamente lo que ya existe.
En conjunto, WSL9x demuestra que Linux y Windows 9x pueden convivir de forma cooperativa en un mismo proceso de arranque, compartiendo ring 0 y hablando a través de APIs que nunca estuvieron pensadas para ello. Es un proyecto inestable, sin interfaz gráfica y bastante exigente con quien lo instala, pero también una muestra brillante de creatividad técnica, retrocompatibilidad llevada al extremo y pasión por destripar sistemas que muchos daban por enterrados hace tiempo.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.