rou2exOS - un OS de hobby tipo DOS escrito en Rust y ensamblador x86

• Sistema operativo estilo DOS de 64 bits desarrollado en Rust, con algo de ensamblador x86 usado también para cargar el kernel
• Implementa modo texto VGA (80x25), sistema de archivos FAT12 y pila de red IPv4 sobre SLIP (ICMP/UDP/TCP/HTTP)
• Se ejecuta y desarrolla en una máquina virtual basada en QEMU, y también soporta algunos medios físicos de disquete
• Incluye utilidades básicas como un editor de texto, autocompletado de archivos/directorios con TAB, el juego Snake y más

Arquitectura y bootloader

• La CPU objetivo es x86_64, con soporte futuro planeado para la arquitectura ARM (aarch)
• Las versiones iniciales cargaban y ejecutaban el kernel en memoria con un bootloader escrito a mano
• En el kernel de 64 bits se usa el bootloader GRUB2 para manejar la entrada a Long Mode y la transición a Protected Mode
• El bootloader stage2 realiza tareas como configurar GDT, IDT y paginación, además de asignar el puntero Multiboot2
• El kernel está compuesto por un intérprete de comandos de shell y varios componentes personalizados

Emulación e imágenes en QEMU

• El desarrollo y las pruebas se realizan en un entorno de máquina virtual mediante QEMU
• Creación de imagen ISO: usa grub2-mkrescue y xorriso
• Soporta creación y montaje de imágenes de disquete FAT12, utilizables en hardware real o con la opción de QEMU -fda fat.img

Proceso de inicialización

• Al entrar al kernel, verifica Long Mode, etiquetas Multiboot2, el sistema de archivos FAT12, el estado de VGA y más
• Tras mostrar un logo en ASCII art, transfiere el control al bucle del shell

Sistema de archivos

• Soporte para sistema de archivos FAT12: lectura/escritura/búsqueda/eliminación de archivos, creación/eliminación de directorios y más
• Permite crear y sobrescribir archivos de texto, con soporte para subdirectorios
• Incluye una herramienta fsck para comprobar la consistencia del sistema de archivos
• También hay planes de añadir soporte para FAT32

Pila de red

• Envío y recepción de paquetes IPv4 basados en el protocolo SLIP
• Soporte para procesamiento de tramas Ethernet (pruebas aún no completadas)
• Soporta ICMP Echo (Request/Reply), UDP y TCP (máquina de estados SYN/SYNACK)
• Servidor HTTP simple: sirve páginas HTML estáticas

Juego Snake

• Incluye el juego Snake, y más adelante también planea una versión multijugador (P2P TCP)
• Los datos del juego (niveles, puntajes) pueden guardarse y cargarse como archivos de texto
• Se sale del juego con ESC, y guarda el High Score según la puntuación

Valor del proyecto y puntos de uso

• Como ejemplo de un sistema operativo escrito en Rust, permite apreciar cómo mejora la seguridad y la productividad en el desarrollo de software de bajo nivel
• Con pruebas de SLIP/ICMP, despliegue sencillo y soporte para hardware real, resulta adecuado para experimentar con sistemas operativos y aprender implementaciones personalizadas
• Permite experimentar directamente una estructura de sistema similar a DOS que combina Rust y ensamblador x86

[GN⁺]

Comentarios en Hacker News

• Uso de un lenguaje que garantiza seguridad de memoria, basado en x86_64 con planes de soporte para Arm, stack de red propio, arranque por CD y multiboot; mi proyecto de hobby ofrece una experiencia que supera a DOS
  • Si quiere competir con DOS, es indispensable soportar Doom y BASIC; eso oficialmente funciona como la línea base del estilo DOS
  • Combinación de Rust y ensamblador x86, así que si se busca seguridad de memoria, queda la duda de qué valor práctico tiene realmente; hoy en día Rust da la sensación de estar sobrepromocionado como en su momento la impresión 3D; en su popularización los beneficios reales parecen limitados, y aunque estaría bien que el proyecto tuviera compatibilidad con software antiguo, si no la tiene se acerca más a un proyecto educativo o de nicho para entusiastas; da la impresión de que todavía está lejos del uso real
• Me encanta que en el stack de red use SLIP y slattach(1); cuando hice mi propio stack TCP/IP simple también conecté SLIP por pty en Linux para integrarlo con el kernel; en macOS antes existía slattach(1), pero parece que ya lo quitaron; me pregunto si alguien ha usado SLIP en macOS para hacer una API de red multiplataforma; como alternativa están tun/tap en Linux y utun en macOS, pero SLIP es mucho más simple
• Me da curiosidad por qué eligió x86: si fue porque hay muchos recursos, por su formato de instrucciones particular, por la complejidad de la secuencia de arranque, o si la estrategia era seguir DOS tal cual; también dijo que pronto dará soporte a la arquitectura ARM, y como DOS en sí une muy de cerca hardware y software, me intriga cómo piensa soportar varias arquitecturas
  • No he revisado este proyecto directamente, pero mi suposición es que la plataforma x86, por su compatibilidad histórica con sistemas heredados, trae integradas muchísimas interfaces, así que es fácil implementar un “OS tipo DOS” muy delgado y simple; se puede empezar sin tener que parsear device trees, configurar la MMU ni lidiar con buses complejos como PCI(e); en ARM el bootstrap en sí ya es difícil, así que para mantener la simplicidad hay que aceptar más restricciones, lo que se puede hacer sin MMU es limitado, y además no hay interfaces tipo BIOS, así que no es tan simple como en x86 leer sectores o esperar entrada de teclado
  • La razón de elegir x86 es que este sistema deriva de una primera versión hecha en Turbo C basada en interrupciones BIOS y ensamblador en línea; no busca imitar solo a MS-DOS, aunque sí recibió bastante inspiración de ahí; el soporte para varias arquitecturas es posible gracias a que el compilador de Rust permite especificar la arquitectura objetivo; basta con definir el target antes de compilar y eso se aplica directamente en el proceso de build
• En el entorno actual de UEFI, en vez del shell quizá habría sido mejor una solución tipo DOS de 64 bits basada en FLOSS; se vería genial como boot manager retro o herramienta de diagnóstico del sistema; me pregunto si esto podrá ejecutarse desde la partición del sistema EFI; ya confirmé soporte para fat12, pero no sé qué tal va con gpt, y también tengo curiosidad de si controla el hardware de video directamente o si la salida es tipo terminal
  • Todavía no se ha probado el arranque desde la partición del sistema EFI; por ahora solo hay soporte oficial para el sistema de archivos FAT12 (hay una función de memory disk, pero en este momento no funciona), GPT todavía no está soportado, y se está considerando priorizar soporte para FAT32 (normalmente los discos flash usan FAT32); sobre la última pregunta, el OS escribe directamente al buffer de memoria VGA, y GRUB proporciona resolución 80x25
• Me parece genial este proyecto; lástima que faltó la frase legendaria: “solo es un hobby, no va a llegar a ser algo grande y profesional como Linux”
• Me pregunto si hay planes de soporte para diacríticos del checo
  • En esta versión solo se planea soporte para inglés; la primera versión originalmente se hizo en checo
• Me pregunto si usa un driver VGA completamente nuevo hecho en Rust
  • Este módulo es el código fuente relacionado con VGA
  • En parte sí, pero en la práctica se parece más a un módulo wrapper para acceder al buffer de video
• Pregunta de si, aunque tenga estilo DOS, no es compatible con DOS
  • Sí, ese análisis es correcto; la primera versión era de 16 bits y estaba diseñada para ser casi compatible con MS-DOS, y además creo que si puede manejar I/O de disco simple ya podría incluirse, en un sentido amplio, dentro de los sistemas tipo DOS
  • O sea, un nivel de compatibilidad con MS-DOS suficiente para correr Alley Cat, Dune 2 o Doom
• Opinión de que se necesita una cola de eventos para soportar un runtime asíncrono
  • Qué tal sería implementar un event loop bien completo
• Pregunta en tono juguetón sobre si puede correr Crysis