4 pontos por GN⁺ 2025-04-27 | 1 comentários | Compartilhar no WhatsApp
  • RetrOS-32 é um sistema operacional hobby totalmente customizado de 32 bits, feito com foco na arquitetura i386, e inclui gráficos, multitarefa e rede
  • O kernel, os utilitários e o sistema de build foram escritos em C e Assembly, e os aplicativos em espaço de usuário são escritos em C++, com Make e Docker usados no build
  • O hardware real testado inclui Lenovo x240, série Asus Eee PC, Dell Optiplex 780, Samsung N150 Plus, Samsung NP-NC10 e IBM Thinkpad a21p
  • Os modos de execução suportam QEMU, v86 via copy.sh e boot em hardware real; em dispositivos reais, usa-se uma GRUB ISO para gravar o arquivo .iso em USB ou CD e executar
  • No roadmap, bootloader, escalonamento preemptivo multithread, sistema de arquivos, gerenciador gráfico de janelas, stack de rede, threads em espaço de usuário e terminal virtual remoto via TCP aparecem como itens já implementados

Visão geral do RetrOS-32

  • RetrOS-32 é um projeto de sistema operacional hobby de 32 bits focado na arquitetura i386
  • A descrição do projeto afirma que se trata de um sistema operacional hobby de 32 bits com gráficos, multitarefa e rede
  • A data de início indicada é 12 de maio de 2022
  • A página do projeto aponta para Project OSHub page

Login e usuários

  • Os usuários padrão são system, admin e guest
  • A senha do admin é admin, e o guest não tem senha
  • Atualmente não há diferença entre admin e guest
  • Usuários podem ser criados com o comando admin create <username> <password>

Linguagens de implementação e configuração de build

  • O kernel, os utilitários e o sistema de build foram escritos em C e Assembly
  • Os aplicativos em espaço de usuário são escritos em C++
  • A compilação usa Make
  • A compilação multiplataforma usa Docker

Hardware testado

  • A lista de hardware real testado é a seguinte
    • Lenovo x240
    • Asus Eee PC series
    • Dell Optiplex 780
    • Samsung N150 Plus
    • Samsung NP-NC10
    • IBM Thinkpad a21p

Como compilar e executar

  • Em ambientes multiplataforma, são necessários Docker para compilar os arquivos de imagem e QEMU para emulação
  • As dependências de compilação nativa variam por plataforma
    • MacOS: i386-elf-gcc, i386-elf-ld, i386-elf-g++
    • Linux / WSL Ubuntu: build-essential, gcc-multilib
    • Para usar GRUB como bootloader, também são necessários grub2, xorriso e xxd
  • No Linux, a sequência de build e execução é: clonar o repositório, ./debian.sh, inicializar os submódulos Git, make compile, make img, make qemu
  • No MacOS, como as ferramentas de build dependem de código x86 de 32 bits, a compilação nativa não é possível no momento, e Docker é a forma mais simples
  • No Windows, usa-se Docker ou WSL
  • Há três formas de execução
    • Fazer upload do arquivo .img como imagem de disco rígido no v86 do copy.sh
    • Executar make qemu ou qemu-system-i386 <image name> no QEMU
    • Em hardware real, gravar o arquivo .iso em um USB ou CD e usar GRUB ISO

Estrutura do projeto

  • A estrutura do repositório é dividida em diretórios de kernel, drivers, gráficos, rede, sistema de arquivos, bibliotecas, apps em espaço de usuário, testes e ferramentas
  • boot contém um bootloader customizado e multiboot.ld
  • kernel contém o código-fonte principal do kernel, código específico por arquitetura e código de threads do kernel
  • apps contém os aplicativos em espaço de usuário e libcore.a, libgraphic.a, libnet.a
  • net contém o código de rede, e fs contém o código relacionado ao sistema de arquivos
  • tools inclui ferramentas e scripts de build

Itens implementados e trabalho restante

  • Nos itens relacionados ao boot, já foram concluídos bootloader customizado, compatibilidade com GRUB e bootloader Stage 2
  • Os recursos de kernel e sistema incluem
    • escalonamento preemptivo multithread
    • separação entre kernel e espaço de usuário com base em GDT e TSS
    • tratamento de interrupções
    • IPC
    • chamadas de sistema
    • threads em espaço de usuário
  • Os recursos de drivers e hardware incluem teclado e mouse PS/2, PIT, VESA 640x480x8, RTC, Serial, E1000 e PCI
  • Em sistema de arquivos e armazenamento, já foram concluídos driver ATA IDE, sistema de arquivos similar ao Ext2, FAT16 e leitura/escrita
    • FAT16 suporta arquivos de até 32MB
    • Atapi ainda não foi concluído
  • Os recursos de memória incluem memória virtual de 32 bits, kalloc/kfree do kernel e malloc/free em espaço de usuário
  • Os recursos gráficos incluem gerenciador de janelas, GFXLib, renderização com double framebuffer, eventos de mouse, redimensionamento dinâmico, tela cheia e biblioteca de widgets
    • Custom HTML to Widgets ainda não foi concluído
  • A stack de rede já concluiu Ethernet, IP, ARP, UDP, Socket API, interface Loopback, DHCP, DNS, TCP e comandos no estilo netcat
    • Webserver, FTP, IRC, SSH, Telnet, HTTP e HTML ainda não foram concluídos
  • Entre aplicativos e ferramentas estão terminal, servidor de janelas, informações de processo, Finder, compilador C/interpretador de bytecode, VM customizada para executar bytecode, editor com realce de sintaxe, calculadora, jogo 3D, jogo Snake em modo texto, terminal virtual remoto via TCP e biblioteca de compressão LZ
  • A lista completa de recursos sugeridos e problemas conhecidos está em open issues

Licença e link do projeto

1 comentários

 
GN⁺ 2025-04-27
Comentários do Hacker News
  • Projetos assim são muito mais agradáveis de ver do que IA sem graça. Talvez não seja algo vendável, mas é um tecnólogo exercendo sua habilidade de forma criativa.
    No fim da adolescência, estudei bastante desenvolvimento de OS como hobby, e era muito legal; ainda hoje às vezes crio pequenos kernels. O último que fiz foi um pequeno kernel RISC-V que exibia uma mensagem para meu/minha parceiro(a).

    • É muito libertador não precisar se preocupar em vender nem fazer marketing. Dá para reinventar a roda até aparecer uma ideia nova.
    • É estranho chamar IA, em bloco, de “sem graça”. Até ser empacotada com uma experiência de usuário inteligente, ela era quase uma investigação acadêmica que não dava dinheiro, mais próxima de um trabalho artesanal.
    • Isso soa como dizer que um pequeno dispositivo de hobby é muito mais interessante do que a tecnologia mais absurda da história da humanidade.
  • Eu gostaria que a fonte padrão do sistema tivesse uma variante mais estreita. Acho que isso deixaria o sistema muito mais refinado, e há várias partes em que os caracteres parecem precisar de mais espaço horizontal.
    Seria preciso reduzir a largura de cada caractere e também estreitar o espaçamento entre eles tanto quanto possível. Com o tamanho de fonte e a resolução atuais, 1 pixel de espaçamento parece suficiente.
    Não entendo muito de sistemas de fontes, mas presumi que fosse uma fonte bitmap monoespaçada. Se for difícil demais mudar isso na base de código, não precisa se preocupar.
    Eu também venho criando há algum tempo um site de OS na web do zero e recentemente reescrevi toda a classe de fontes, então isso chamou especialmente minha atenção.

    • Concordo que a fonte atual está longe de ser ideal. Ainda estou usando quase exatamente a fonte inicial que coloquei para funcionar no começo.
      Também dei uma olhada em renderização de fontes de verdade, e está na lista de tarefas, mas venho adiando.
    • Que clima pesado.
      “Fiz um sistema operacional!”
      “Hmm, a fonte não está boa.”
      Isso parece o ápice do HN.
  • Muito legal. Fico curioso sobre o que você faria diferente se começasse de novo hoje.
    Também tenho curiosidade sobre que linguagem você considera adequada para as partes de baixo nível: se continuaria com C, usaria um subconjunto simples de C++ ou consideraria uma linguagem mais nova.
    Há material demais por aí, então também queria saber como você manteve o projeto interessante sem simplesmente copiar o código dos outros.

    • A maior coisa que eu faria diferente seria planejar. No começo, eu só tinha o objetivo de fazer um OS básico de hello world, mas continuei adicionando novos recursos e trabalhando em várias coisas ao mesmo tempo, o que gerou uma dívida técnica que ainda estou pagando.
      Acho que também teria tentado reduzir as dependências de UNIX.
      Quanto à linguagem, gosto de C por causa da sintaxe básica e do estilo direto ao ponto. Para aplicações em espaço de usuário, eu poderia considerar outras linguagens.
      Eu queria escrever tudo sozinho desde o início, e não portar software era uma parte central do projeto. Em geral, segui a regra de “copie ideias, não código”.
  • Do ponto de vista de alguém que usava um Commodore PET 2001 em 1977, isso é realmente incrível. Eu estava mexendo no KolibriOS e no MenuetOSx64, e fiquei com vontade de criar meu próprio OS. É impressionante que você tenha conseguido.

  • O projeto é realmente impressionante, e quero dar os parabéns. Gosto de desenvolvimento de OS desde a adolescência, então é ótimo ver uma conquista assim realmente implementada.
    Também tenho um pouco de curiosidade sobre como o subsistema gráfico é inicializado. Boa sorte.

  • Eu também queria conseguir arranjar tempo para um projeto de paixão assim.
    Esquecer a praticidade, esquecer a estratégia de entrada no mercado, esquecer o encaixe no mercado-alvo; simplesmente construir e aprender.

    • É realmente revigorante não precisar pensar se algo vai “ser usado” de fato nem no mercado. É puramente por diversão e aprendizado.
    • Fico curioso por que você não consegue arranjar tempo. Desde pequeno, acho que eu teria ficado bem perdido sem projetos de hobby.
      Um deles era um OS de brinquedo, mas quando desenvolvimento de OS de baixo nível virou meu trabalho de verdade, esse projeto parou.
  • Estou nessa área há décadas e estou tentando aprender desenvolvimento de OS. Conheço um pouco de FASM, NASM e FASM-G.
    Mas quero estudar a saída dos programas assembler para entender como um OS realmente funciona no nível binário.
    Fico curioso se você aprendeu os códigos de instrução de alguma arquitetura específica, como fez os programas de drivers de dispositivo e se poderia organizar as etapas para desenvolver um OS por conta própria.

    • Acho que os melhores lugares para aprender são o fórum osdev e a wiki osdev. Há muitos recursos realmente úteis para começar.
      Também existem alguns tutoriais, mas eles frequentemente têm bugs e é fácil acabar basicamente recriando o OS deles.
      Não me aprofundei tanto em códigos de instrução; só pesquisei ao criar o compilador C, então conheço apenas as instruções básicas mais comuns.
      https://forum.osdev.org/
      https://wiki.osdev.org/Expanded_Main_Page
  • Realmente incrível. Eu gostaria que voltasse mais o espírito da computação inicial, quando as pessoas mexiam mais no próprio computador do que no nível das aplicações.
    Venho pensando em criar um computador pessoal como projeto de hobby de longo prazo: um computador em que eu mesmo faça toda a pilha de software e saiba a origem de cada bit que entra no sistema.
    O hardware seria difícil de controlar no mesmo nível, a menos que um FPGA desse desempenho suficiente para rodar tudo, mas pelo menos o software parece possível.
    Até agora isso parecia irrealista, mas você mostrou que é possível. Parece que também está implementando um compilador C de hobby: https://github.com/joexbayer/C-Compiler

    • É uma sensação muito boa saber que escrevi tudo, do topo do espaço de usuário até os drivers. Ao mesmo tempo, também é um inferno de depuração.
      O compilador C foi criado para este OS e roda dentro dele. O projeto ficou grande demais, então eu quis separá-lo do repositório do OS, especialmente porque ele também roda no Linux.
  • Seria bom se você explicasse melhor como esse compilador interage com o sistema operacional. Tenho curiosidade especialmente sobre como ele lida com recursos como structs, e sobre as limitações atuais e melhorias planejadas nessa área.

    • Não há nenhuma interação mágica entre o compilador e o OS. Ele simplesmente compila para o mesmo código de máquina (i386) e usa interrupções para chamadas de sistema.
      Structs são tratadas como regiões de memória cujo tamanho é definido pelos membros, e o acesso a membros é feito por offsets dentro dessa região.
      No momento há muitas limitações, como só existir int e char e não haver instrução switch. As maiores diferenças em relação ao C padrão são permitir funções dentro de structs e, no caso de funções de struct, passar implicitamente a struct para a função. Mais detalhes podem ser vistos aqui:
      https://github.com/joexbayer/C-Compiler
  • É um dos projetos de paixão mais impressionantes que vi aqui em bastante tempo. Fico curioso por que você decidiu usar um compilador C próprio.

    • Eu tinha a regra de querer escrever tudo sozinho, e criar um compilador também sempre foi um dos meus “objetivos”. Então acabou se encaixando naturalmente.