rou2exOS - um OS de hobby estilo DOS escrito em Rust e assembly x86

 (github.com/krustowski)
7 pontos por GN⁺ 2025-06-24 | 1 comentários | Compartilhar no WhatsApp
  • Sistema operacional estilo DOS de 64 bits desenvolvido em Rust, com um pouco de assembly x86 também usado no carregamento do kernel
  • Implementa modo texto VGA (80x25), sistema de arquivos FAT12 e pilha de rede IPv4 via SLIP (ICMP/UDP/TCP/HTTP)
  • Execução e desenvolvimento em máquina virtual baseada em QEMU, com suporte também a parte de mídia floppy física
  • Inclui utilitários básicos como editor de texto simples, autocompletar de arquivos/diretórios com TAB, jogo Snake etc.

Arquitetura e bootloader

  • A CPU-alvo é x86_64, com suporte futuro planejado para a arquitetura ARM (aarch)
  • As versões iniciais carregavam e executavam o kernel com um bootloader escrito manualmente
  • No kernel de 64 bits, usa o bootloader GRUB2 para tratar a entrada em Long Mode e a transição para Protected Mode
  • O bootloader stage2 executa tarefas como configuração de GDT, IDT e paginação, além da atribuição do ponteiro Multiboot2
  • O kernel é composto por um processador de comandos de shell e vários componentes customizados

Emulação e imagens no QEMU

  • O desenvolvimento e os testes são feitos em ambiente de máquina virtual por meio do QEMU
  • Criação de imagem ISO: uso de grub2-mkrescue e xorriso
  • Suporte à criação e montagem de imagem de floppy FAT12, podendo ser usada em dispositivo real ou com a flag do QEMU (-fda fat.img)

Procedimento de inicialização

  • Ao entrar no kernel, verifica Long Mode, tags Multiboot2, sistema de arquivos FAT12, estado do VGA etc.
  • Após exibir um logo em ASCII art, transfere o controle para o loop do shell

Sistema de arquivos

  • Suporte ao sistema de arquivos FAT12: leitura/gravação/busca/exclusão de arquivos, criação/exclusão de diretórios etc.
  • Suporta criação e sobrescrita de arquivos de texto, além de subdiretórios
  • Inclui um utilitário fsck para verificação da consistência do sistema de arquivos
  • Há também planos para suporte a FAT32 no futuro

Pilha de rede

  • Envio e recebimento de pacotes IPv4 com base no protocolo SLIP
  • Suporte ao processamento de quadros Ethernet (testes ainda incompletos)
  • Suporta ICMP Echo (Request/Reply), UDP e TCP (máquina de estados SYN/SYNACK)
  • Servidor HTTP simples: fornece páginas HTML estáticas

Jogo Snake

  • Jogo Snake embutido, com versão futura de multiplayer (P2P TCP) também planejada
  • Os dados do jogo (níveis, pontuação) podem ser salvos e carregados em arquivos de texto
  • ESC encerra o jogo, e o High Score é salvo de acordo com a pontuação

Valor do projeto e pontos de uso

  • Como exemplo de sistema operacional escrito em Rust, permite perceber os ganhos de segurança e produtividade no desenvolvimento de software de baixo nível
  • Com testes de SLIP/ICMP, implantação simples e suporte a hardware real, é adequado para experimentar sistemas operacionais e aprender implementações customizadas
  • É possível vivenciar diretamente a estrutura de um sistema semelhante ao DOS que combina Rust e assembly x86

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-24
Comentários do Hacker News
  • Uso de uma linguagem com segurança de memória garantida, base em x86_64 com suporte a Arm também planejado, pilha de rede própria, inicialização por CD e multiboot, um projeto hobby que oferece uma experiência que supera o DOS
    • Para competir com o DOS, é essencial suportar Doom e BASIC; isso oficialmente serve como linha de base do estilo DOS
    • Combinação de Rust com assembly x86, então fica a dúvida se isso realmente tem valor prático quando o objetivo é segurança de memória; hoje em dia Rust dá a sensação de estar sendo promovido em excesso como já aconteceu com impressão 3D, com ganhos práticos limitados no processo de popularização, e o projeto seria legal se tivesse compatibilidade com software legado, mas, se não tiver, parece mais algo educacional ou de nicho para entusiastas, ainda distante de uso real
  • Gostei muito do uso de SLIP e slattach(1) na pilha de rede; quando fiz uma pilha TCP/IP simples por conta própria, também já conectei via SLIP usando pty no Linux para integrar com o kernel; antigamente o macOS também tinha slattach(1), mas parece que foi removido, então fico curioso se alguém já usou SLIP no macOS para criar uma API de rede multiplataforma; como alternativas existem tun/tap no Linux e utun no macOS, mas SLIP é muito mais simples
  • Fiquei curioso sobre por que escolheram x86: por haver mais recursos, pelo formato peculiar das instruções, pela complexidade da sequência de boot, ou talvez por ser uma estratégia de seguir o DOS de perto; também disseram que o suporte à arquitetura ARM virá em breve, então fico imaginando como funciona dar suporte a várias arquiteturas quando o próprio DOS era tão fortemente acoplado ao hardware e ao software
    • Não olhei este projeto diretamente, mas meu palpite é que a plataforma x86 historicamente traz muitas interfaces embutidas graças à compatibilidade legada, o que facilita implementar um “OS tipo DOS” bem fino e simples; dá para começar sem precisar lidar com parsing de device tree, configuração de MMU, nem barramentos complexos como PCI(e); no ARM o bootstrap em si já é mais difícil, e para manter a simplicidade é preciso aceitar mais restrições, além de que sem MMU o que se pode fazer é limitado, e não há interfaces de BIOS, então não é tão fácil quanto no x86 fazer coisas simples como ler setores ou esperar entrada do teclado
    • A razão para escolher x86 é que este sistema deriva de uma primeira versão feita em Turbo C com base em interrupções de BIOS e assembly inline; não é uma tentativa de imitar apenas o MS-DOS, embora tenha sido bastante inspirado por ele; o suporte a várias arquiteturas é viável graças ao recurso do compilador Rust de definir a arquitetura de destino, então basta escolher o target antes do build e isso já é aplicado no processo de compilação
  • No ambiente atual de UEFI, em vez de UEFI e shell, algo assim, uma solução em formato DOS de 64 bits baseada em FLOSS, talvez tivesse sido melhor; parece ótimo para um gerenciador de boot retrô ou uma ferramenta de diagnóstico de sistema; fiquei curioso se isso pode rodar a partir da EFI System Partition, vi que há suporte a FAT12, mas como fica o suporte a GPT, e também queria saber se ele controla o hardware de vídeo diretamente ou se a saída é em formato de terminal
    • O boot a partir da EFI System Partition ainda não foi testado, por enquanto há suporte oficial apenas ao sistema de arquivos FAT12 (há funcionalidade de memory disk, mas atualmente não funciona), GPT ainda não é suportado, e o suporte a FAT32 está sendo considerado como prioridade (normalmente discos flash usam FAT32); quanto à última pergunta, o OS escreve diretamente no buffer de memória VGA, com resolução 80x25 fornecida pelo GRUB
  • Achei o projeto muito legal; pena que perderam a frase clássica: “é só um hobby, não vai ficar grande e profissional como o Linux”
  • Fiquei curioso se há planos para suporte a diacríticos do tcheco
    • Nesta versão o plano é suportar apenas inglês; a primeira versão foi inicialmente feita em tcheco
  • Pergunta sobre usar um driver VGA totalmente novo feito em Rust
  • Pergunta se ele tem estilo DOS, mas não é compatível com DOS
    • Essa análise está correta; a primeira versão era de 16 bits e foi projetada para ser quase compatível com MS-DOS, e também dá para considerar que, em sentido amplo, se consegue lidar apenas com I/O de disco simples, ainda pode entrar na categoria de sistema DOS
    • Ou seja, no nível de compatibilidade com MS-DOS que permitiria rodar Alley Cat, Dune 2 e Doom
  • Opinião de que seria necessária uma fila de eventos para dar suporte a runtime assíncrono
    • Opinião sobre como seria uma implementação de event loop mais completa
  • Pergunta bem-humorada sobre a possibilidade de rodar Crysis