Subsistema de Windows 9x para Linux

 (social.hails.org)
12 puntos por GN⁺ 2026-04-23 | 2 comentarios | Compartir por WhatsApp
  • Proyecto experimental que ejecuta cooperativamente un kernel Linux moderno (6.19) dentro del kernel de Windows 9x, permitiendo aprovechar al mismo tiempo todas las funciones de ambos sistemas operativos
  • A diferencia de WSL, no usa virtualización por hardware, así que puede ejecutarse incluso en un 486
  • Permite usar funciones modernas de SO en el entorno de Windows 9x, como paginación, protección de memoria y planificación preventiva, y ejecutar aplicaciones lado a lado sin reiniciar
  • Está compuesto por tres elementos: un kernel Linux parcheado, un controlador VxD y el cliente wsl.com, adaptando User-Mode Linux para usar llamadas a la API del kernel de Win9x
  • Las llamadas al sistema se despachan mediante el manejador de error general de protección (GPF) en lugar de int 0x80, debido a la limitación de Win9x con una tabla de descriptores de interrupción demasiado corta
  • "Escrito con orgullo sin IA (Proudly written without AI)", licencia GPL-3

WSL9x - codeberg.org/hails/wsl9x

Descripción general

  • WSL9x es un subsistema Linux para Windows 9x que ejecuta cooperativamente un kernel Linux moderno dentro del kernel de Windows 9x (6.19 al momento de redactarse)
  • Permite aprovechar simultáneamente todas las funciones de ambos sistemas operativos, como paginación, protección de memoria y planificación preventiva
  • Permite ejecutar aplicaciones de ambos SO lado a lado sin reiniciar
  • Fue escrito directamente, sin IA

Estructura técnica

  • WSL9x está compuesto por tres elementos
    • Kernel Linux parcheado (rama win9x-um-6.19)
    • Controlador VxD
    • Programa cliente wsl.com

Controlador VxD

  • Se encarga de la inicialización de WSL9x, y su punto de entrada está en vxd/wsl9x.asm
  • Configura el mapeo inicial del código del kernel y carga vmlinux.elf desde disco mediante interrupciones de DOS (vxd/loader.c, vxd/fs.asm)
  • El kernel se compila con la dirección base fija 0xd0000000
  • Inicia un nuevo hilo dentro del System VM y asigna una pila de 16 KiB para usarla en la entrada de Linux
  • Después entra en un bucle de eventos que maneja la entrada al kernel, el despacho de IRQ, el retorno al espacio de usuario y el estado inactivo (vxd/entry.c)

Manejo de llamadas al sistema y fallos de página

  • El controlador maneja fallos de página y llamadas al sistema, que son eventos del espacio de usuario que deben despacharse al kernel
  • Las llamadas al sistema se procesan mediante el manejador de error general de protección (GPF)
    • Win9x no tiene una tabla de descriptores de interrupción lo bastante larga como para instalar un manejador adecuado para int 0x80, la interrupción de llamadas al sistema de Linux i386
    • El manejador GPF inspecciona la instrucción que provocó el fallo y, si es int 0x80, avanza el puntero de instrucción como si la interrupción hubiera tenido éxito y la despacha como una llamada al sistema de Linux (vxd/fault.c)

Modificaciones al kernel Linux

  • Está basado en User-Mode Linux, pero fue modificado para llamar a la API del kernel de Windows 9x en lugar de la API POSIX
  • Se ejecuta en ring 0 (modo supervisor/kernel), no en modo usuario (ring 3)
  • Gran parte de la integración con el kernel de Win9x, incluido el cambio de contexto, existe del lado del kernel Linux
    • Ubicación del código principal: linux/arch/um/os-Win95
    • Punto de entrada: _start en main.c; archivos clave: process.c, mmu.c

Cliente wsl.com

  • Es un programa DOS de 16 bits implementado en wsl/wsl.asm
  • Permite usar el prompt de MS-DOS como ventana TTY sin una implementación TTY separada
  • Al ejecutarse, llama a la API V86 de WSL9x (vxd/v86_api.asm) para obtener una consola libre y avisar que la salida de esa consola debe despacharse hacia él
  • Luego entra en un bucle de eventos esperando IRQ e intentando leer el teclado cuando ocurre una interrupción
  • También actúa como punto de sincronización del controlador de consola (vxd/console.c)
    • Cuando la salida de Linux está lista, programa un evento y ejecuta int 0x29 en el contexto de la VM de MS-DOS para imprimir caracteres en la ventana de DOS
    • Esta interrupción también es el punto donde controladores ANSI para DOS como NNANSI interceptan la salida del terminal para implementar códigos de escape ANSI

Requisitos de compilación y ejecución

  • Se necesita una toolchain cruzada para el objetivo i386-linux-musl (se recomienda usar musl-cross-make)
  • Se necesita la toolchain Open Watcom v2 para compilar los componentes de Windows
  • Se debe compilar el kernel Linux parcheado desde la rama win9x-um-6.19
  • Configurar adecuadamente las variables de entorno WATCOM y LINUX (ver .envrc.example como ejemplo)
  • Se requiere una imagen de disco duro hdd.base.img con Windows 9x preinstalado
  • Al ejecutar make, se genera hdd.img con WSL9x preparado
  • Ejecutar wsl desde el prompt de MS-DOS para abrir el pty; si se usan colores ANSI, se recomienda cargar antes un controlador como nnansi.com

Licencia

  • GPL-3

Lecturas relacionadas

2 comentarios

 
GN⁺ 2026-04-23
Comentarios de Hacker News
  • Antes de WSL, creo que las formas más representativas de ejecutar binarios de Linux sin modificar dentro de Windows eran CoLinux y flinux
    http://www.colinux.org/
    https://github.com/wishstudio/flinux
    flinux en realidad se parecía más a la arquitectura de WSL1, y CoLinux me daba más vibra de WSL2 por eso de cargar el kernel de Linux al lado
    Técnicamente, sentía que Cygwin era más la vía canónica. En vez de forzar tuberías externas de Linux, el enfoque era ejecutar binarios POSIX nativos sobre Windows, y además me gustaba que todo terminara con un simple enlace de DLL liviano, sin tocar ring 0
    Aun así, en ese tiempo faltaba la comodidad de los administradores de paquetes para CLI, y cuando realmente trabajaba en Windows, terminé bastante enganchado con CoLinux
    • Recuerdo que Cygwin es mucho más viejo que CoLinux. CoLinux salió en 2004 y Cygwin en 1995
      El problema clave que recuerdo era el infierno de DLL. Por ejemplo, si un port de OpenSSH para Windows traía su propio cygwin1.dll, los choques de versión eran frecuentes
      Aun así, en una época con poca RAM y swapping pesado, el menor overhead sí importaba
      En esos tiempos predominaban las apps nativas más que cosas como Web 2.0 o NodeJS, y Java tampoco tenía buena fama
      Al final, como siempre, se sentía como avanzar dos pasos y retroceder uno
    • Que Cygwin fuera la opción canónica puede ser cierto según algunos criterios, pero para mí siempre fue un enfoque bastante extraño
      A pesar de la insinuación de que no era lento, en la práctica sí lo era, tenía peor compatibilidad que otros métodos, requería recompilar, y sentía que durante gran parte de su vida no fue una herramienta especialmente querida
      Dentro de cygwin1.dll estaba ocurriendo una enorme magia de compatibilidad, y al final era como meter tuberías externas de Linux dentro del proceso. Eso se nota aún más si piensas en cómo implementaba fork() sin soporte del sistema
      Cygwin ni siquiera funciona dentro del aislamiento de Windows AppContainer. MSYS2 también sigue usando esa base, así que los binarios de MSYS2 tampoco corren en AppContainer
      Por eso en el sandboxing de Claude Code tuvimos que tomar un camino completamente distinto. Claude Code quiere Git for Windows, y Git for Windows distribuye cosas como bash.exe compiladas con MSYS2
      En cambio, los builds verdaderamente nativos de Windows no necesitan ese tipo de hacks raros que exige cygwin1.dll, así que los builds non-MSYS2 que encontré sí funcionaban bien en AppContainer
    • Hoy en día, creo que MSYS2 depende internamente de Cygwin pero sí ofrece un administrador de paquetes
      Como puedes usar pacman de Arch Linux, ahora es bastante amigable manejar binarios POSIX nativos en Windows sin necesidad de una VM de Linux
    • En experiencia real de desarrollo, trabajar sobre Cygwin era verdaderamente doloroso
      Si la biblioteca de C que querías usar no tenía una versión para Cygwin ya compilada, te tocaba recorrer a mano todo el árbol de dependencias con configure y make
      Además, si mal no recuerdo, como en dos tercios de las veces había que corregir algo a mano, porque POSIX no encajaba de forma completamente perfecta
    • Básicamente, Cygwin implementaba la API POSIX sobre Win32 y mezclaba algunas llamadas Nt para mejorar la compatibilidad
      Aun así, para conseguir la semántica correcta hacían falta todo tipo de rodeos y hacks; por ejemplo, fork no era copy-on-write
      Yo usé Cygwin más o menos desde 1999 hasta 2022, probé un poco WSL2 y todavía lo uso en la laptop
      Pero en la desktop me pasé por completo a Linux desde el año pasado
  • Me dio bastante gusto porque esto se siente como una versión pre-NT de colinux para Windows
    Hace tiempo, cuando usaba Windows en la era de XP, corrí Colinux y era una herramienta realmente fascinante
    Era mucho más fácil montar el stack LAMP del lado Linux, y podías armar un entorno de desarrollo local bastante decente editando con herramientas de Windows
    Incluso se podía experimentar conectando un servidor X11 para Windows y levantar encima un escritorio Linux
    Viéndome apilar cada vez más entorno tipo Unix sobre Windows, al final terminé cambiándome a macOS
    Dejando aparte el puro valor hacker, si pienso en usos reales, en una máquina clase 486 esto probablemente chocaría muy rápido con el límite de memoria
    http://colinux.org/
    • Creo que Colinux fue realmente una hazaña técnica
      Solo que no mucha gente supo apreciarla
  • La persona que hizo esto me parece casi un mago
    A mis ojos era una tarea casi imposible
    Aunque sí me da curiosidad cómo se verá para alguien que entienda bien la arquitectura
    Por eso me acordé de ese chiste en el que dos matemáticos dicen que un teorema es trivial, y solo después de dos horas de explicación terminas aceptando que sí, era trivial
    • A mí también me pasó en primer año de CS: una vez estaba al frente del pizarrón en clase de teoría de conjuntos haciendo una demostración y me salté la parte que no lograba ver diciendo simplemente que era trivial
      El profesor dijo que sí y seguimos con lo siguiente
    • Yo normalmente sí entiendo la arquitectura, y esto no me parece magia
      Más bien me impresiona muchísimo que la autora o el autor haya ido descubriendo uno por uno esa larga lista de detalles digna de una vision quest que hace posible algo así
    • Entiendo que la función central de un sistema operativo moderno es permitir que varios programas corran al mismo tiempo sin interferir entre sí
      Por eso cada programa solo puede leer una parte de la memoria, y el CPU también se le presta por un tiempo limitado antes de pasar al siguiente
      Windows empezó a usar esto en serio a partir de Windows NT, y XP también es de esa familia
      En cambio, hasta Windows 98, los programas podían hacer casi cualquier cosa y esas funciones de protección del hardware estaban prácticamente sin uso
      El Windows de esa época se sentía menos como un sistema operativo y más como un paquete de bibliotecas de funciones para mostrar la UI y hablar con periféricos
      El CPU tiene hardware especial para limitar acceso a memoria y tiempo de ejecución, y Windows 9x no lo aprovechaba lo suficiente
      Por eso creo que había espacio para que un subsistema Linux para Windows 9x fingiera ser su propio sistema operativo, tomara ese hardware y corriera encima un sistema operativo moderno
    • Viendo la página del proyecto, siento que la explicación está bastante bien hecha
      Para mí, la parte más difícil de un trabajo así sería descifrar la API de drivers de Microsoft
      En la era de 9x la documentación no era lo bastante detallada ni fácil de conseguir, y aun hoy no me parece precisamente un terreno agradable
    • El kernel de win9x era famoso justamente por no hacer tantas cosas
      Por eso parecía haber bastante espacio para injertarle parte de las funciones de bajo nivel de Linux
  • Me alegró ver que este artículo y otro similar llegaron a la portada el mismo día
    Por un lado, se hablaba de que los Show HN se habían triplicado y de la cantidad de apps con una vibra de vibe coding bastante parecida; por el otro, alguien llevaba seis años metiéndose en las entrañas de Win9x para correr ahí dentro un kernel Linux moderno
    Comparado con hilos llenos de apps hechas con prompts de 20 minutos, publicaciones como esta de verdad se sienten felices
    • Vi que en el README decía Proudly written without AI
      Me gustó bastante ver una frase así
    • Hasta el prompt mismo probablemente lo hizo una IA
      Siento que ya se volvió común pedir no “create me an owl app”, sino un prompt integral para crear una owl app y luego pegar eso en otra sesión de IA
  • La frase del README > Proudly written with zero AI me pareció un poco ambigua
    Porque existe un producto llamado Zero AI, así que también se podía leer de esa manera
    • Ahora parece que lo cambiaron a > Proudly written without AI, que es mucho más claro
      La expresión quedó bastante más precisa, y el proyecto en sí me parece realmente asombroso
    • Creo que aquí la diferencia entre mayúsculas y minúsculas sí importa
  • Dejo un enlace directo sin pasar por redes sociales
    https://codeberg.org/hails/wsl9x
  • Me da curiosidad cuáles serían buenos materiales para entender bien la arquitectura de Windows 3.x y 9x
    Sé de forma fragmentaria que existía el VM Monitor y que había soporte de este tipo, pero siento que las explicaciones detalladas están muy dispersas
    Mucha gente resume Windows como si simplemente corriera sobre DOS, pero claramente eso no es exacto
    Obviamente no es una máquina virtual en el sentido actual, pero ahí había una estructura técnica bastante interesante, y siento que la mayoría de los materiales la tratan solo por encima
    También me pregunto qué tan parecido es este proyecto a BSD on Windows
    Y conozco Architecture of Windows 9x, pero para mi gusto le falta profundidad
  • Siguiendo el estilo de nombres de Microsoft, ¿esto no debería ser Linux Subsystem for Windows en vez de Windows Subsystem for Linux?
    • No necesariamente
      Como WSL significa Linux on Windows, esto también parece leerse como W9xSL en el sentido de Linux sobre Windows 9x
    • Yo también siempre he sentido que ese nombre no es intuitivo
    • También estoy de acuerdo
      No puedo citar la fuente ahora mismo, pero recuerdo haber leído hace tiempo que esto tenía que ver con un tema de marca registrada
      La idea era llamarlo originalmente Linux Subsystem for Windows, pero desde la Linux Foundation no permitían que un proyecto no autorizado usara un nombre que empezara con Linux, algo así
  • Supongo que esto debió de haber sido más fácil que https://github.com/haileys/doslinux
    • Aun así, quiero decir que llegar al siguiente nivel tomó seis años
  • Entiendo que el kernel NT, desde NT 3.1 pasando por 2000 y XP, y más adelante incluso con cierta continuidad en WSL de Windows 10/11, fue diseñado desde 1993 pensando en un subsistema POSIX
    La filosofía central era tener múltiples personalities y traducir las llamadas al sistema de cada entorno a llamadas del kernel NT
    Así que WSL1 en 2016 fue, en esencia, volver a aplicar el mismo truco para Linux
    En cambio, Windows 9x venía de la línea DOS, así que para correr Linux ahí dentro seguramente hacían falta hacks mucho más sucios y fundamentalmente distintos
    Supongo que esa es también la razón por la que nadie lo hizo en su momento
    Por eso, el simple hecho de que esto realmente funcione me hace pensar en lo adelantada a su época que estaba la arquitectura NT
    En cuanto a utilidad práctica, me vienen a la mente entornos atados a Windows 98, como software médico o industrial antiguo
    Aun así, si en 2026 tienes un 486 en las manos, probablemente te sirva mucho más correr Linux nativo que meter Linux dentro de un derivado de DOS de hace 30 años
 
plumpmath 2026-04-24

Ah, coLinux jaja -_- qué nombre tan nostálgico. Jaja, pero ahora ni aunque exista WSL lo uso; aun así, esto de Windows 95 + Linux sí me llama.