Subsystem do Windows 9x para Linux

 (social.hails.org)
12 pontos por GN⁺ 2026-04-23 | 2 comentários | Compartilhar no WhatsApp
  • Projeto experimental que executa cooperativamente o kernel Linux mais recente (6.19) dentro do kernel do Windows 9x, permitindo usar ao mesmo tempo todos os recursos dos dois sistemas operacionais
  • Ao contrário do WSL, não usa virtualização de hardware, então pode rodar até em um 486
  • Recursos modernos de SO como paginação, proteção de memória e escalonamento preemptivo podem ser usados no ambiente Windows 9x, com suporte para executar aplicativos lado a lado sem reiniciar
  • É composto por três elementos: kernel Linux com patches, driver VxD e cliente wsl.com; o User-Mode Linux foi adaptado para chamadas à API do kernel Win9x
  • As chamadas de sistema são despachadas pelo manipulador de erro geral de proteção (GPF) em vez de int 0x80, devido ao limite curto da tabela de descritores de interrupção do Win9x
  • "Orgulhosamente escrito sem IA", licença GPL-3

WSL9x - codeberg.org/hails/wsl9x

Visão geral

  • O WSL9x é um subsistema Linux para Windows 9x que executa cooperativamente o kernel Linux mais recente dentro do kernel do Windows 9x (na época da escrita, 6.19)
  • Permite aproveitar simultaneamente todos os recursos de ambos os sistemas operacionais, incluindo paginação, proteção de memória e escalonamento preemptivo
  • Permite executar aplicativos dos dois sistemas lado a lado sem reiniciar
  • Foi escrito manualmente, sem IA

Estrutura técnica

  • O WSL9x é composto por três componentes
    • Kernel Linux com patches (branch win9x-um-6.19)
    • Driver VxD
    • Programa cliente wsl.com

Driver VxD

  • É responsável pela inicialização do WSL9x, com ponto de entrada em vxd/wsl9x.asm
  • Configura o mapeamento inicial do código do kernel e carrega vmlinux.elf do disco por meio de interrupções do DOS (vxd/loader.c, vxd/fs.asm)
  • O kernel é compilado com endereço base fixo em 0xd0000000
  • Inicia uma nova thread dentro da System VM e aloca uma pilha de 16 KiB para a entrada do Linux
  • Depois entra em um loop de eventos que trata a entrada no kernel, o despacho de IRQ, o retorno ao espaço do usuário e o estado ocioso (vxd/entry.c)

Tratamento de chamadas de sistema e page fault

  • O driver trata page faults e chamadas de sistema, que são eventos do espaço do usuário e precisam ser despachados para o kernel
  • As chamadas de sistema são tratadas pelo manipulador de erro geral de proteção (GPF)
    • O Win9x não tem uma tabela de descritores de interrupção longa o suficiente para instalar um manipulador adequado para int 0x80, a interrupção de chamadas de sistema do Linux i386
    • O manipulador de GPF inspeciona a instrução que causou a falha e, se for int 0x80, avança o ponteiro de instrução como se a interrupção tivesse sido bem-sucedida e despacha para a chamada de sistema do Linux (vxd/fault.c)

Modificações no kernel Linux

  • É baseado em User-mode Linux, mas foi modificado para chamar a API do kernel do Windows 9x em vez da API POSIX
  • Roda em ring 0 (modo supervisor/kernel), não em modo usuário (ring 3)
  • Grande parte da integração com o kernel Win9x, incluindo troca de contexto, fica do lado do kernel Linux
    • Principais arquivos: linux/arch/um/os-Win95
    • Ponto de entrada: _start em main.c; arquivos principais incluem process.c e mmu.c

Cliente wsl.com

  • É um programa DOS de 16 bits implementado em wsl/wsl.asm
  • Permite usar o prompt do MS-DOS como janela TTY sem implementar um TTY separado
  • Ao ser executado, chama a API V86 do WSL9x (vxd/v86_api.asm) para receber um console não utilizado e informar que a saída desse console deve ser despachada para ele
  • Depois entra em um loop de eventos aguardando IRQ e tenta ler o teclado quando uma interrupção ocorre
  • Também funciona como ponto de sincronização do driver de console (vxd/console.c)
    • Quando a saída do Linux está pronta, agenda um evento e executa int 0x29 no contexto da VM do MS-DOS para imprimir caracteres na janela do DOS
    • Essa interrupção também é o ponto em que drivers ANSI para DOS, como o NNANSI, interceptam a saída do terminal para implementar códigos de escape ANSI

Requisitos para build e execução

  • É necessário um toolchain cross para o alvo i386-linux-musl (recomendado usar musl-cross-make)
  • É necessário o toolchain Open Watcom v2 para compilar os componentes Windows
  • É necessário compilar o kernel Linux com patches na branch win9x-um-6.19
  • Defina corretamente as variáveis de ambiente WATCOM e LINUX (veja o exemplo em .envrc.example)
  • É necessária uma imagem de disco rígido hdd.base.img com o Windows 9x pré-instalado
  • Ao executar make, será gerada a imagem hdd.img com o WSL9x preparado
  • Execute wsl no prompt do MS-DOS para abrir o pty; para usar cores ANSI, recomenda-se carregar antes um driver como nnansi.com

Licença

  • GPL-3

Leituras relacionadas

2 comentários

 
GN⁺ 2026-04-23
Comentários do Hacker News
  • Antes do WSL, as formas mais conhecidas de rodar binários Linux sem modificação dentro do Windows eram CoLinux e flinux
    http://www.colinux.org/
    https://github.com/wishstudio/flinux
    O flinux era, na prática, mais próximo da arquitetura do WSL1, enquanto o CoLinux lembrava mais o WSL2 por carregar um kernel Linux ao lado
    Tecnicamente, eu achava o Cygwin uma abordagem mais ortodoxa. Em vez de forçar um encanamento Linux externo, ele rodava binários POSIX nativos sobre o Windows, e eu gostava do fato de terminar só com um link leve de DLL, sem mexer no ring 0
    Só que, na época, faltava a praticidade de um gerenciador de pacotes de linha de comando, e na prática eu usava bastante o CoLinux quando trabalhava no Windows
    • Lembro que o Cygwin é bem mais antigo que o CoLinux. O CoLinux é de 2004, e o Cygwin foi lançado em 1995
      O principal problema de que me lembro era o DLL hell. Por exemplo, quando um port do OpenSSH para Windows trazia sua própria cygwin1.dll, conflitos de versão eram frequentes
      Ainda assim, na época em que RAM era escassa e swap era pesado, o menor overhead fazia diferença
      Naqueles tempos, antes de Web 2.0 ou NodeJS dominarem, o foco era em apps nativos, e Java também não tinha boa reputação
      No fim, parecia aquele movimento de sempre: dois passos para a frente e um para trás
    • Dizer que o Cygwin era a abordagem ortodoxa pode fazer sentido sob alguns critérios, mas para mim ele sempre pareceu uma abordagem bem estranha
      Apesar da insinuação de que não era lento, na prática era lento, tinha menos compatibilidade que outras opções, exigia recompilação e, durante a maior parte da sua vida, não foi uma ferramenta amplamente adorada
      Dentro da cygwin1.dll acontecia uma enorme mágica de compatibilidade, e no fim das contas isso também era uma forma de puxar um encanamento Linux externo para dentro do processo. Isso fica ainda mais claro quando se pensa em como eles implementavam fork() sem suporte do sistema
      O Cygwin simplesmente não funciona dentro do isolamento do Windows AppContainer. O MSYS2 também usa essa base até hoje, então binários do MSYS2 não rodam em AppContainer
      Por isso, no sandboxing do Claude Code, tivemos que seguir um caminho totalmente diferente. O Claude Code depende do Git for Windows, e o Git for Windows distribui bash.exe e outros componentes compilados com MSYS2
      Já builds realmente nativos para Windows não precisam daqueles hacks peculiares exigidos pela cygwin1.dll, então os builds non-MSYS2 que encontrei rodaram bem no AppContainer
    • Hoje em dia, o MSYS2 oferece um gerenciador de pacotes, mesmo dependendo internamente do Cygwin
      Como dá para usar o pacman do Arch Linux, ficou bem mais amigável lidar com binários POSIX nativos no Windows sem precisar de uma VM Linux
    • Pela experiência prática de desenvolvimento, trabalhar sobre o Cygwin era realmente sofrido
      Se a biblioteca C que você queria usar não tivesse uma versão para Cygwin já pronta, era preciso sair rodando configure e make manualmente por toda a árvore de dependências
      E, se não me falha a memória, em uns dois terços das vezes ainda era necessário corrigir alguma coisa na mão, porque a compatibilidade POSIX não era perfeita
    • O Cygwin basicamente implementava a API POSIX sobre Win32 e misturava algumas chamadas Nt para aumentar a compatibilidade
      Mesmo assim, era preciso recorrer a todo tipo de gambiarra e hack para acertar a semântica correta; por exemplo, fork não era copy-on-write
      Eu usei Cygwin de mais ou menos 1999 até 2022, experimentei um pouco o WSL2 e ainda uso isso no notebook
      Mas no desktop migrei totalmente para Linux no ano passado
  • Fiquei bem feliz de ver isso; parece uma versão pré-NT do colinux para Windows
    Lá atrás, na era do XP, eu rodava Colinux no Windows, e era uma ferramenta realmente fascinante
    Era muito mais fácil subir uma stack LAMP no lado Linux, e dava para montar um ambiente de desenvolvimento local bem decente editando com ferramentas do Windows
    Também dava para experimentar ligar um servidor X11 para Windows e exibir um desktop Linux por cima
    Em algum momento, vendo que eu estava empilhando cada vez mais um ambiente estilo Unix sobre o Windows, acabei migrando para macOS
    Fora o puro valor de hacking, pensando em utilidade prática, imagino que em máquinas da classe 486 isso bateria rápido no limite de memória
    http://colinux.org/
    • O Colinux foi realmente um feito técnico
      Só faltou mais gente perceber isso
  • A pessoa que fez isso me parece quase um mago
    Para mim, isso soa como um trabalho quase impossível
    Mas fiquei curioso sobre como isso pareceria aos olhos de quem entende a arquitetura
    Aí me veio aquela piada sobre dois matemáticos dizendo que um teorema é trivial e, depois de duas horas explicando, finalmente admitindo que ele realmente é trivial
    • Eu mesmo, no primeiro ano de CS, durante uma prova de teoria dos conjuntos, já fiquei na frente do quadro tentando fazer uma demonstração e acabei simplesmente chamando de trivial uma parte que eu não conseguia enxergar
      O professor concordou e seguimos em frente
    • Eu geralmente sou alguém que entende arquitetura, e isso não me parece magia
      O que realmente impressiona é que a autora ou autor foi identificando, um por um, todos os itens daquela longa lista de detalhes digna de um grimório que tornam isso possível
    • Entendo que o papel central de um sistema operacional moderno é permitir que vários programas rodem ao mesmo tempo sem interferirem uns nos outros
      Por isso, cada programa só pode ler uma parte da própria memória, e a CPU também só fica disponível por um tempo limitado antes de passar para o próximo programa
      O Windows passou a usar isso de forma séria a partir do Windows NT, e o XP também faz parte dessa linhagem
      Já até o Windows 98, os programas podiam fazer praticamente qualquer coisa, e aqueles mecanismos de proteção do hardware ficavam quase sem uso
      Naquela época, o Windows parecia mais um conjunto de bibliotecas utilitárias para exibir a UI e conversar com periféricos do que um sistema operacional no sentido moderno
      A CPU tem hardware especial para limitar acesso à memória e tempo de processamento, mas o Windows 9x não aproveitava isso plenamente
      Por isso, existia espaço para um subsistema Linux para Windows 9x fingir que era ele mesmo o sistema operacional, tomar posse desse hardware e rodar um sistema moderno ali dentro
    • Pela página do projeto, me parece que a explicação está muito boa
      Na minha visão, a parte mais difícil num trabalho desses é descobrir a API de drivers da Microsoft
      A documentação da era 9x não era detalhada o suficiente, nem fácil de acessar, e até hoje isso não é uma área muito agradável
    • O kernel do Win9x era famoso justamente por não fazer tanta coisa assim
      Então parecia haver bastante espaço para encaixar ali parte das funcionalidades de baixo nível do Linux
  • Fiquei feliz de ver algo assim na front page no mesmo dia
    De um lado, havia discussão sobre como os Show HN triplicaram e como está cheio de apps com uma vibezinha parecida de vibe coding; do outro, alguém estava há 6 anos fuçando as entranhas do Win9x para rodar um kernel Linux moderno ali dentro
    Comparando com threads cheias de apps feitos com prompt de 20 minutos, posts assim dão uma alegria genuína
    • Vi que no README está escrito Proudly written without AI
      Gostei bastante de ver isso
    • E provavelmente até o próprio prompt foi criado por IA
      Em vez de pedir create me an owl app, muita gente agora pede um prompt abrangente para criar um owl app e depois cola isso em outra sessão de IA
  • A expressão do README, > Proudly written with zero AI, me pareceu um pouco ambígua
    Porque existe mesmo um produto chamado Zero AI, então também dá para ler assim
    • Agora parece que mudaram para > Proudly written without AI, o que ficou bem mais claro
      A formulação ficou muito melhor, e o projeto em si também é realmente impressionante
    • Aqui, a diferença entre maiúsculas e minúsculas faz diferença
  • Deixando o link direto, sem passar por rede social
    https://codeberg.org/hails/wsl9x
  • Tenho curiosidade sobre quais seriam bons materiais explicando a arquitetura do Windows 3.x e 9x
    Eu conheço pedaços soltos, como a existência do VM Monitor e esse tipo de suporte, mas sinto que as explicações detalhadas estão espalhadas por toda parte
    Muita gente resume o Windows como se ele simplesmente rodasse sobre o DOS, mas isso claramente não é exato
    Claro, não é uma máquina virtual no sentido atual, mas havia ali uma estrutura técnica bem interessante, e a maior parte do material parece tratar isso só superficialmente
    Também tenho curiosidade sobre o quanto este projeto se parece com BSD on Windows
    E também conheço Architecture of Windows 9x, mas para o meu gosto achei pouco profundo
  • Pelo estilo de nomenclatura da Microsoft, isto não deveria ser Windows Subsystem for Linux, e sim Linux Subsystem for Windows?
    • Não necessariamente
      Como WSL significa Linux on Windows, isto aqui também parece ser lido como W9xSL no sentido de Linux sobre Windows 9x
    • Eu também sempre achei esse nome pouco intuitivo
    • Também concordo
      Não consigo citar a fonte agora, mas lembro de ter lido que isso tinha relação com questões de marca
      A ideia original seria chamar de Linux Subsystem for Windows, mas a Linux Foundation não permitiria que um projeto não autorizado usasse um nome começando com Linux, algo nessa linha
  • Imagino que isto tenha sido mais fácil do que https://github.com/haileys/doslinux
    • Mesmo assim, quero dizer que levou 6 anos para chegar ao próximo nível
  • Entendo que o kernel NT, do NT 3.1 passando por 2000 e XP até chegar mais tarde ao WSL do Windows 10/11, manteve parte dessa linhagem e foi projetado desde 1993 com um subsistema POSIX em mente
    A filosofia central era ter múltiplas personalities, com cada ambiente traduzindo suas chamadas de sistema para chamadas do kernel NT
    Então o WSL1, em 2016, foi basicamente uma reimplementação do mesmo truque, só que para Linux
    Já o Windows 9x vinha da linhagem do DOS, então rodar Linux ali dentro provavelmente exigia hacks muito mais sujos e fundamentalmente diferentes
    Imagino que esse seja o motivo de ninguém ter feito isso na época
    Por isso, o simples fato de isso funcionar já parece mostrar o quanto a arquitetura NT estava à frente do seu tempo
    Em termos práticos, penso em ambientes presos ao Windows 98, como softwares médicos ou industriais antigos
    Ainda assim, se alguém estiver com um 486 nas mãos em 2026, provavelmente será muito mais útil simplesmente rodar Linux nativo do que enfiar Linux dentro de um derivado de DOS com 30 anos
 
plumpmath 2026-04-24

Ah, coLinux kkk -_- que nome nostálgico. kkk Mas hoje em dia nem uso o WSL mesmo tendo ele, porém esse win95+linux me chama a atenção.