HN no ar: sistema operacional hobby feito à mão finalmente roda em um IBM ThinkPad vintage
(github.com/joexbayer)- 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
.isoem 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,xorrisoexxd
- MacOS:
- 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
.imgcomo imagem de disco rígido no v86 do copy.sh - Executar
make qemuouqemu-system-i386 <image name>no QEMU - Em hardware real, gravar o arquivo
.isoem um USB ou CD e usar GRUB ISO
- Fazer upload do arquivo
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
bootcontém um bootloader customizado emultiboot.ldkernelcontém o código-fonte principal do kernel, código específico por arquitetura e código de threads do kernelappscontém os aplicativos em espaço de usuário elibcore.a,libgraphic.a,libnet.anetcontém o código de rede, efscontém o código relacionado ao sistema de arquivostoolsinclui 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/kfreedo kernel emalloc/freeem 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
- O RetrOS-32 é distribuído sob a MIT License
- O link do projeto é https://github.com/joexbayer/RetrOS-32
1 comentários
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).
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.
Também dei uma olhada em renderização de fontes de verdade, e está na lista de tarefas, mas venho adiando.
“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.
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.
https://github.com/joexbayer/RetrOS-32/blob/development/grap...
https://github.com/joexbayer/RetrOS-32/blob/development/grap...
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.
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.
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
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.
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.