Windows 9x Subsystem for Linux: lo instalé, lo rompí y entendí por qué importa más de lo que parece

¿Por qué alguien en 2025 invierte tiempo real en hacer correr Linux dentro de Windows 95? No me refiero a una VM, no me refiero a emulación. Me refiero a un subsistema nativo — el mismo concepto arquitectónico que Microsoft patentó en 2016 con WSL, pero corriendo sobre un kernel de 1995 con 4MB de RAM convencionales y sin protección de memoria real. Llevaba semanas pensando en eso desde que vi el thread en Hacker News con 699 puntos — el post más votado del día — y no me salía de la cabeza.

La pregunta de fondo no es técnica. Es esta: ¿qué dice sobre cómo pensamos la compatibilidad cuando alguien reconstruye, décadas después, una capa de abstracción que el sistema operativo original nunca tuvo?

Windows 9x Subsystem for Linux: qué es y por qué HN lo votó hasta arriba

El proyecto se llama W9xSL y hace exactamente lo que dice en el nombre: permite correr binarios Linux ELF dentro de Windows 95/98/Me. No es WINE al revés. Es una capa de traducción de syscalls que mapea llamadas POSIX a las APIs Win32 disponibles en aquella época — con todas las limitaciones que eso implica.

El post de HN explotó, mi tesis es, porque tocó dos nervios al mismo tiempo: la nostalgia técnica con profundidad real (no el "mirá, Doom en una calculadora") y la pregunta más incómoda del ecosistema actual — ¿cuánta de nuestra infraestructura moderna es, en el fondo, compatibilidad apilada sobre compatibilidad?

Yo tengo credencial editorial directa para hablar de esto. Mi post De DOS a Cloud: 33 años con la tecnología fue uno de los más leídos del blog, y no fue por el click-bait. Fue porque hay algo visceral en nombrar lo que viviste en primera persona. Yo usé una Amiga a los 5 años, en 1994. Windows 95 llegó a mi casa cuando tenía 6. La pantalla de inicio con el logo de nubes y el sonido de Brian Eno no es nostalgia abstracta para mí — es una memoria sensorial concreta.

Entonces cuando vi W9xSL, no pensé "qué curioso proyecto de museo". Pensé: esto me explica algo sobre cómo funciona la compatibilidad que nunca terminé de articular.

Instalación real: comandos, errores y el momento en que todo se rompió

Lo primero que intenté fue correrlo en una VM de Windows 98 SE que armé con VirtualBox. El repo tiene instrucciones pero están pensadas para alguien que ya sabe exactamente qué stack tiene abajo. Acá el proceso honesto:

REM Dentro de Windows 98 SE, VirtualBox, 128MB RAM asignados
REM Primer intento — directo desde el README

COPY W9XSL.DLL C:\WINDOWS\SYSTEM\
COPY W9XSL.EXE C:\WINDOWS\

REM Esto falla silenciosamente en Win98 sin la versión correcta de MSVCRT
REM Spoiler: el error no aparece en pantalla, simplemente no pasa nada

El primer problema no fue técnico. Fue epistemológico: Windows 9x no te dice por qué algo no funciona. No hay stderr meaningful, no hay logs estructurados, no hay event viewer útil. Hay un pantalla azul eventual o silencio. Estuve 40 minutos convencido de que el problema era mi VM hasta que recordé que así era la depuración en los noventa — era así de opaca, siempre.

El segundo intento, con las dependencias correctas:

REM Dependencias necesarias (que el README menciona de pasada):
REM - MSVCRT 6.0 (el que viene con IE 5.5 o Visual C++ 6 Redistributable)
REM - Controlador DPMI activo (CWSDPMI o el de EMM386)

REM Copiá primero el runtime correcto
COPY MSVCRT.DLL C:\WINDOWS\SYSTEM\

REM Después el subsistema
COPY W9XSL.DLL C:\WINDOWS\SYSTEM\
REGSVR32 W9XSL.DLL

REM Ahora sí, intentar correr un binario ELF de prueba (ls estático, compilado para x86 Linux)
W9XSL ls -la C:\

Y acá pasó algo interesante: funcionó parcialmente. El ls listó el directorio. Pero con nombres de archivo en mayúsculas (FAT32, obvio), sin permisos reales (no existen en ese filesystem), y con timestamps que correspondían a la zona horaria del sistema Windows sin conversión. No es un bug del proyecto — es la brecha irreducible entre dos modelos de mundo completamente distintos.

Ahí es donde el proyecto se pone filosófico.

El problema real: compatibilidad es siempre una mentira piadosa

Lo que W9xSL revela, y lo que los 699 puntos de HN votaron sin necesariamente articularlo, es esto: la compatibilidad entre sistemas operativos no es una propiedad binaria. Es una escala de mentiras acordadas.

WSL 1 hacía lo mismo que W9xSL pero al revés: mapeaba syscalls Linux a NT. WSL 2 abandonó ese enfoque y metió un kernel Linux real dentro de Hyper-V porque la mentira se volvió insostenible — había syscalls que simplemente no tenían equivalente semántico en NT. Ahora tenemos WSL 2, que es técnicamente más correcto pero arquitectónicamente más honesto sobre lo que siempre fue: dos sistemas distintos corriendo en paralelo, no uno absorbido por el otro.

W9xSL en Windows 9x enfrenta el mismo problema pero con menos recursos para esconder la costura. No hay memoria protegida real en Win9x (todo corre en Ring 0 efectivamente). No hay permisos de filesystem. No hay fork() real. El proyecto trabaja esto con emulación parcial — fork() se implementa como CreateProcess() con estado copiado, los file descriptors se mapean a HANDLES, los signals se simulan con mensajes de Windows.

Que funcione en absoluto es el logro. Que no sea transparente es la lección.

Esto conecta con algo que venía pensando cuando medí el costo semántico de las abstracciones en mis agentes: cada capa de compatibilidad tiene un costo que no aparece en el benchmark feliz. Aparece en el edge case de las 11pm cuando el local está lleno y la conexión se cortó. Yo aprendí eso a los 16 en un cyber café, diagnosticando cortes con clientes mirándome. La compatibilidad siempre falla en el peor momento y siempre por la razón que no documentaron.

Errores comunes y gotchas reales al instalar W9xSL

1. El silencio como único feedback Win9x no tiene mecanismo de error útil para DLLs mal registradas. Si REGSVR32 no devuelve el dialog de éxito, el problema casi siempre es MSVCRT versión incorrecta. Verificá con:

REM Chequeá qué versión de MSVCRT tenés
VER
REM Después buscá el archivo
DIR C:\WINDOWS\SYSTEM\MSVCRT.DLL
REM El tamaño importa: MSVCRT 6.0 pesa ~270KB, la versión 5.x ~240KB
REM Con la versión incorrecta, W9XSL falla sin decirte nada

2. Binarios ELF estáticos solamente (al principio) El subsistema no resuelve dependencias dinámicas de Linux. Los binarios tienen que ser compilados estáticamente contra musl o diet libc para tener chances reales. Un binario compilado normalmente contra glibc va a buscar libc.so.6 y no la va a encontrar nunca.

# Compilar un binario de prueba adecuado para W9xSL
# (hacerlo desde Linux/WSL moderno, después transferirlo a la VM)
gcc -static -o hello_w9x hello.c
file hello_w9x
# Debe decir: ELF 32-bit LSB executable, Intel 80386, statically linked
# Si dice "dynamically linked", no va a funcionar en W9xSL

3. El problema del path separator Linux usa /, Windows usa \. W9xSL hace traducción pero no es perfecta. Hardcodear paths en los binarios de prueba es la forma más rápida de confundirse sobre si el problema es el subsistema o el binario.

4. Memoria: 128MB no es opcional Con menos de 64MB asignados a la VM, el sistema entra en swap constante y W9xSL se vuelve inutilizable. No es un bug — es que Win98 + cualquier cosa extra simplemente no entra en 32MB de forma usable.

5. Fecha del sistema y compilación W9xSL tiene un check de fecha que puede fallar si el reloj de la VM está muy desincronizado. Sincronizá el reloj de la VM antes de instalar.

Lo que este proyecto dice sobre la deuda técnica que no vemos

Acá viene mi postura real, la que no aparece en el thread de HN aunque debería:

La deuda técnica más peligrosa no es el código viejo que tenés. Es la capa de compatibilidad que alguien construyó para no reescribir ese código viejo, y que ahora es parte de la infraestructura.

W9xSL es un experimento académico y eso está bien — es honesto sobre lo que es. Pero WSL 1 no lo era. WSL 1 era una capa de compatibilidad en producción que Microsoft usó para no perder developers frente a macOS, y duró exactamente hasta que las costuras se volvieron insostenibles. WSL 2 es la confesión de que la abstracción era insuficiente.

Yo viví esto en pequeño cuando migré de Vercel a Railway en 2024. No era deuda técnica de décadas, pero el patrón era el mismo: los cold starts eran la "capa de compatibilidad" entre mi modelo mental de "servidor siempre activo" y la realidad de serverless. Podría haber seguido parchando timeouts, agregando warmup requests, optimizando bundles. En cambio, moví la infra. La migración duró un fin de semana y aprendí más sobre producción real que en meses de documentación.

W9xSL me recuerda ese fin de semana: a veces el proyecto más valioso no es el que funciona perfecto sino el que te muestra exactamente dónde está la costura.

Esto tiene eco directo en cómo pienso los agentes IA también. Cuando analicé los logs de publicidad en LLMs o cuando miré el criterio imposible de moderación de r/programming, el patrón es el mismo: capas de compatibilidad entre lo que el sistema fue diseñado para hacer y lo que le estamos pidiendo ahora. En algún momento, alguien va a tener que reescribir, no parchear.

La identidad de un sistema operativo no es su kernel. Es el contrato que mantiene con el software que corre arriba. Windows 9x tenía un contrato implícito: "todo corre con acceso total al hardware, no hay aislamiento real, la velocidad es la prioridad". Linux tiene un contrato distinto: "todo pasa por el kernel, los procesos están aislados, los permisos importan". W9xSL intenta que un contrato simule al otro. Funciona parcialmente. Eso es exactamente lo que podés esperar.

Y si estás construyendo algo hoy que va a durar — un sistema, una API, una plataforma — preguntate qué contrato estás firmando con el software que va a correr arriba. Porque en 30 años, alguien lo va a instalar, lo va a romper, y va a entender exactamente dónde pusiste la mentira piadosa.

FAQ: Windows 9x Subsystem for Linux

¿W9xSL es un emulador o un subsistema real? Es un subsistema de traducción de syscalls, no un emulador completo. No emula la CPU ni el hardware. Traduce llamadas al sistema POSIX (open, read, fork, exec, etc.) a sus equivalentes Win32, de manera similar a como funcionaba WSL 1 pero en la dirección opuesta y sobre un sistema operativo mucho más limitado. La diferencia con emulación completa (como QEMU) es que los binarios corren nativamente en la CPU x86 — no hay interpretación de instrucciones.

¿Para qué sirve en 2025? ¿Es solo nostalgia? Tiene valor pedagógico real. Si querés entender por qué WSL 2 necesitó un kernel Linux completo en lugar de seguir con traducción de syscalls, W9xSL te muestra los límites del enfoque anterior de forma muy concreta. También es útil para investigadores de sistemas operativos y para entender cómo se diseñan capas de compatibilidad. Nostalgia pura sería correr Doom. Esto es más interesante que eso.

¿Qué binarios Linux puedo correr con W9xSL? Principalmente binarios ELF 32-bit compilados estáticamente. Las herramientas de línea de comando simples (ls, cat, grep, sed) compiladas contra musl o diet libc son las más estables. Los programas que usan threading complejo, fork() intensivo, o networking avanzado van a tener comportamiento impredecible o van a fallar. No esperés correr un servidor web completo.

¿Tiene algo que ver con el WSL de Microsoft actual? Comparte el concepto arquitectónico (traducción de syscalls para compatibilidad entre ecosistemas) pero no tiene relación directa con el código ni el equipo de Microsoft. Es un proyecto independiente, open source, creado décadas después. Lo interesante es que el mismo problema — hacer que dos modelos de proceso/filesystem/permisos coexistan — lleva a soluciones estructuralmente similares independientemente de quién lo implementa.

¿Vale la pena instalarlo si no tengo hardware vintage? Sí, funciona perfectamente en VirtualBox o VMware con una imagen de Windows 98 SE. El proceso de armar la VM lleva más tiempo que instalar W9xSL en sí. Asigná al menos 128MB de RAM a la VM y usá un disco virtual de al menos 2GB para tener margen cómodo. La parte más difícil es conseguir una imagen de Windows 98 SE legítima — Microsoft ya no las vende pero hay vías legales para recuperarlas si tenés licencia original.

¿Por qué Windows 9x y no Windows NT/2000 como base? Windows NT ya tenía una arquitectura de subsistemas nativamente — el subsistema POSIX de NT existe desde NT 3.1 (1993). Hacer un subsistema Linux sobre NT sería técnicamente más fácil y menos interesante. El desafío de W9xSL es precisamente hacerlo sobre Win9x, que no tiene protección de memoria real, no tiene separación kernel/user space funcional, y tiene un modelo de procesos completamente distinto. Es el experimento más difícil y por eso es más revelador.

Conclusión: instalé Windows 95 en 2025 y aprendí algo sobre producción

No me arrepiento de haber pasado un sábado con una VM de Windows 98 SE y un proyecto de GitHub con 699 votos en HN. Lo que encontré no fue nostalgia — fue un espejo raro que me mostró algo sobre las decisiones de arquitectura que tomo hoy.

Mi postura, después de todo esto: la compatibilidad hacia atrás no es una virtud técnica por defecto. Es una deuda que a veces vale la pena pagar y a veces hay que admitir que no se puede pagar. Microsoft pagó esa deuda con WSL 1 durante años, hasta que no pudo más y construyó WSL 2. W9xSL muestra el límite inferior del enfoque — hasta dónde podés estirar la traducción de syscalls antes de que la mentira se haga insostenible.

La próxima vez que alguien te proponga "agregar una capa de compatibilidad" en lugar de refactorizar, preguntale: ¿esto es WSL 1 o WSL 2? ¿Estamos comprando tiempo o estamos aceptando que el problema no tiene solución limpia con este approach?

Yo aprendí eso a los 16 en un cyber café con la conexión cortada y veinte personas esperando. A veces la solución es cambiar el cable, no resetear el router por quinta vez. W9xSL, paradójicamente, me lo recordó.

Si te interesa profundizar en cómo los agentes IA tienen el mismo problema de "capas de compatibilidad" entre lo que prometemos y lo que entregamos, este post sobre los gaps de MCP va por ese camino. Y si te preguntás si el contenido que construís hoy va a sobrevivir a los filtros editoriales de mañana, el criterio imposible de r/programming tiene algo que decirte.