Vamos construir Win32/Linux juntos: o projeto loss32

• loss32 tem como objetivo ser uma distribuição Linux que usa um ambiente Win32 como desktop padrão, aproveitando componentes do WINE e do ReactOS
• Os usuários podem baixar e executar arquivos .exe diretamente, e o sistema é projetado como um sistema operacional totalmente open source
• Diferentemente da abordagem do ReactOS, que tenta reimplementar o kernel Windows NT, o loss32 busca garantir estabilidade e compatibilidade sobre o kernel Linux
• As principais motivações do projeto são melhorar o WINE, restaurar a experiência de desktop baseada em Win32 e ampliar a acessibilidade a softwares de criação
• Um protótipo inicial está previsto para janeiro de 2026, com melhorias graduais depois disso

---

Conceito de Win32/Linux

• O Linux é descrito não como um sistema operacional autônomo, mas como parte de um sistema completo composto por elementos como o WINE e o espaço de usuário do ReactOS
  • Essa combinação é chamada de “Win32/Linux” ou “Win32 plus Linux”
• Com base no conceito de sistema operacional completo definido pela Microsoft, a proposta é combinar o kernel Linux com o ambiente Win32

Visão geral do projeto

• O objetivo é construir um ambiente de desktop completo formado por software Win32 sobre o WINE
  • Os usuários podem executar arquivos .exe diretamente
  • A proposta é um SO livre e aberto acessível mesmo para quem não é um usuário voltado a Unix
• Ao contrário do ReactOS, não reimplementa o kernel, usando em vez disso o kernel Linux e componentes já validados
  • Inclui partes do espaço de usuário do ReactOS para melhorar a usabilidade
  • Como é baseado em Linux, também pode executar softwares para Linux, uma vantagem que o ReactOS não tem

Escopo da substituição do espaço de usuário

• A direção é substituir o máximo possível de todo o espaço de usuário pelo WINE
• Não são mencionadas limitações ou exceções específicas

Motivação da criação

• O projeto quer preservar a experiência de desktop de PC do fim dos anos 1990 ao início dos anos 2010
• Busca melhorar as partes incompletas do WINE para que todos os usuários possam ter melhor compatibilidade
• O Win32 é visto como uma “ABI estável do Linux”
• Também há uma motivação experimental simples: “porque é possível”

Alegação de estabilidade do Win32

• A ABI Win32 tem um histórico de compatibilidade mantido por décadas
  • Por meio do WINE, é possível executar até softwares Win16
• Em áreas como softwares de criação e jogos, onde o ecossistema GNU/Linux é mais limitado, o Win32 oferece ampla acessibilidade
• É descrito como a “ABI estável do mundo”, com papel importante para ampliar o acesso ao patrimônio cultural

Capturas de tela e estado atual

• As capturas de tela divulgadas mostram a tela real do WINE rodando no Debian 13
• Atualmente, ainda existem elementos incômodos e partes inacabadas
• O objetivo é estabilizar esse ambiente e empacotá-lo em um formato fácil de instalar

Como participar

• O projeto foi escrito por hikari_no_yume durante o evento 39C3 em 29 de dezembro de 2025 e atualizado em 30 de dezembro
• Participação ou dúvidas podem ser encaminhadas por e-mail ([e-mail]) ou pelo canal IRC #loss32 (irc.libera.chat)
• Áreas em que colaboração é desejada:
  • Melhorar a integração entre compositores Wayland e o WINE (atualmente usando standalone mutter)
  • Trabalhos relacionados a explorer.exe, shell32.dll, escalonamento HiDPI e empacotamento no WINE
  • explorer.exe, shell32.dll do ReactOS e problemas de compatibilidade com o WINE
  • A estrutura detalhada da stack de desktop GNU/Linux como um todo

Próximos passos

• O protótipo inicial está previsto para janeiro de 2026
  • Em um formato instalável após adicionar a /etc/apt/sources.list e executar sudo apt install
  • Deve incluir vários elementos inacabados e com falhas, seguidos por um processo iterativo de melhoria

[GN⁺]

Comentários do Hacker News

• Até o próprio Linus Torvalds disse que a compatibilidade de ABI não é suficiente. Acho que esse é um dos principais motivos pelos quais o Linux não é popular no desktop
  Vídeo relacionado

  • Como diria um amigo meu, “a glibc está desperdiçando um ABI de kernel perfeitamente estável”
  • Formatos como AppImage e FlatPak resolvem esse problema em teoria, mas o problema prático é que não há quem empacote softwares antigos
  • Esse argumento ainda faz sentido, mas também vale notar que isso foi dito há 12 anos
  • Concordo totalmente com o Linus. No Windows, um exe feito para WinXP quase sempre roda no Win10 e 11, mas no Linux eu sofro com problemas de compatibilidade sempre que muda a versão do Mint ou do Ubuntu
  • Por isso o OpenBSD pode parecer atraente. Kernel e aplicativos são totalmente integrados e, graças à simplicidade, há mais segurança e estabilidade.
    Mas é irônico que o mundo open source ainda construa sistemas operacionais instáveis em cima de conceitos tão antigos.
    A confusão dos sistemas de empacotamento, atualizações que quebram coisas, glibc instável e ambientes desktop em constante mudança continuam sendo problemas

• É surpreendente que, graças ao Wine e ao Proton, o Linux tenha melhor compatibilidade com jogos antigos de Windows. Jogos dos anos 90 e 2000 são difíceis de rodar no Windows, mas na Steam funcionam no Linux com um clique

  • Na verdade, o Wine também funciona no Windows. O projeto Shorthorn o usa para rodar software moderno no XP
  • Meu PC gamer não era compatível com o Windows 11, então mudei para Linux, e a sensação de ganho de desempenho foi imediata. O Windows tinha muitos downloads desnecessários e travamentos, mas no Linux quase tudo funciona bem. Ainda assim, alguns jogos continuam com problemas de som no Proton
  • Queria exemplos concretos de quais jogos são difíceis de rodar no Windows
  • Por outro lado, já aconteceu de a versão nativa para Linux de um jogo não funcionar, e eu ter que rodar a versão Windows via Proton

• Criar utilitários de GUI com base em VB6 pode ser mais estável e produtivo do que as tecnologias web atuais

  • Eu escolheria Delphi. Delphi oferece suporte a Windows, Linux, macOS, Android e iOS.
    Além disso, o Elements da RemObjects é um ambiente RAD para várias plataformas e várias linguagens
  • Eu também comecei com VB6 e tenho nostalgia, mas não dá para negar os avanços trazidos pelo modelo declarativo de UI do React. O desaparecimento da distinção entre renderização inicial e rerenderização, com a UI sendo atualizada só por mudanças de estado, foi revolucionário
  • Eu votaria em Delphi ou FreePascal, mas concordo com o sentimento básico
  • Além disso, software feito para 2005 roda absurdamente rápido nos sistemas de hoje
  • Mas isso só vale quando se usam os widgets e efeitos básicos do Win32. Se você quiser ir além, um ambiente maduro e bem documentado como um runtime web é mais produtivo

• Queria entender concretamente o problema de ABI no Linux. Uso Linux há mais de 20 anos, mas nunca senti isso em apps instalados via gerenciador de pacotes.
  Se alguém conhecer bem toda a história, seria ótimo ver isso organizado em um blog

  • O kernel é estável, mas as bibliotecas de sistema necessárias para apps gráficos quebram com frequência. GTK, Qt, X11 e outros componentes principais continuam mudando, e isso causa rupturas de compatibilidade
  • O problema real não é ABI, e sim a falta de padronização. A Linux Standard Base tentou resolver isso, mas desapareceu por falta de interesse.
    A CADT (cultura de reescrita) continua por acharem manutenção algo sem graça. Ex.: Wayland, reescritas em Rust
    Nesse ambiente, é difícil apps comerciais crescerem, e até apps open source levam anos para portar (ex.: a transição do GIMP de GTK2→3)
  • O Linux não cobre toda a stack como o Windows. Há bibliotecas de vários desenvolvedores misturadas, e elas continuam mudando com o tempo
  • Fico curioso se você nunca teve problemas com versão de GLIBC
  • O modelo de aplicar patches e recompilar tudo a cada release do SO é terrível.
    Desenvolvedores sofrem por causa dos intermediários das distribuições, e usuários acabam presos a versões antigas de apps.
    Um bom sistema operacional deveria conseguir rodar aplicativos antigos sem mudanças.
    O Windows é muito melhor nisso do que o Linux, e o Linux tem uma estrutura socialista sem um responsável claro.
    Docker é uma solução no lado dos servidores, mas não se aplica ao desktop

• Se existisse um desktop Linux com a interface clássica do Windows 7 ou XP, eu seria muito fã.
  A elegância daquilo é muito mais atraente do que o Windows 10

  • É incrível que ainda não exista um ambiente desktop clone 1:1 realmente bem-acabado do XP/7.
    Copiar um ambiente fixo assim ajudaria a evitar excesso de recursos e permitiria focar em correções de bugs e otimização
  • Recomendo testar o tema Aero para KDE. Pelas capturas de tela, parece mesmo o Windows 7
  • Mas a maioria dessas tentativas fracassa. Sem ser vendido junto com hardware, como o Linspire ou o BeOS PC, é inviável manter
  • O SerenityOS é um SO completo no estilo Win2k e pode ter potencial se conseguir suporte a hardware.
    Ou então resta esperar o ReactOS ficar pronto
  • Se você colocar um tema de Windows no XFCE, dá para chegar bem perto. Com algumas configurações do Wine, já basta

• O WikidPad quebrou por causa das mudanças de versão do Python e do WxWindows, e no fim voltei para o Windows.
  O exe de 2012 ainda funciona perfeitamente. Pessoalmente, acho que o Windows 2000 Server SP4 foi o melhor SO desktop de todos

  • Minha escolha seria o Server 2003, a última versão supervisionada por Cutler. Tecnicamente, até há acesso ao código-fonte
  • Também tive um problema parecido no Debian, mas resolvi com debootstrap e snapshots.debian.org.
    A aceleração por GPU pode quebrar, mas o X11 ainda mantém uma retrocompatibilidade fortíssima
  • Em 2025, ainda ouvir que “o Task Manager consome 15% de CPU” mostra que o Windows 11 continua ineficiente

• Acho que chegou a hora de a Microsoft provar do próprio remédio da estratégia embrace, extend, extinguish

  • Na minha opinião, o Windows 13 pode até migrar para um kernel Linux.
    Na prática, a Microsoft vem adotando Linux e open source ativamente nos últimos 10 anos

• As ideias do Linux são boas, mas ainda falta suporte de hardware. Com a expansão do ARM, isso pode piorar.
  Fico me perguntando por que o Google não transforma o Android em um verdadeiro SO de desktop. O ChromeOS é limitado demais

  • Na verdade, dependendo do dispositivo, o Linux às vezes tem compatibilidade melhor que o Windows.
    O Google está levando a sério a desktopização do Android a partir do Android 16.
    O ChromeOS também é excelente para certos tipos de trabalho.
    Só que o Google não é muito bom em ouvir os clientes.
    Ainda assim, é preciso reconhecer a contribuição dele para a evolução das tecnologias web
  • O ChromeOS não é brinquedo de forma alguma. Como ambiente de desenvolvimento, em alguns aspectos ele é melhor que o macOS.
    Se a última vez que você usou foi em 2013, hoje é algo totalmente diferente
  • Hoje em dia, na verdade, já existe muito hardware com suporte só a Linux
  • Em ambiente desktop, a maior parte do hardware funciona direto. A menos que seja algo muito incomum, não há problema

• Seria bom se as principais distribuições registrassem o Wine por padrão usando binfmt_misc.
  Se apps Windows pudessem ser executados isoladamente dentro dos mecanismos de segurança do Linux, com logs e relatórios de falha integrados,
  isso abriria um caminho realista para um SO substituto do Windows

  • Esse tipo de recurso é justamente o que tornaria o Linux realmente amigável para iniciantes

• O projeto Longene me veio à mente de novo.
  Foi uma tentativa de integrar a API do Windows ao kernel Linux, e é um caso histórico interessante como referência