Sur HN : mon OS hobby codé maison tourne enfin sur un IBM ThinkPad vintage
(github.com/joexbayer)- RetrOS-32 est un système d’exploitation hobby 32 bits entièrement personnalisé, conçu autour de l’architecture i386, avec graphisme, multitâche et réseau
- Le kernel, les utilitaires et le système de build sont écrits en C et Assembly, tandis que les applications en espace utilisateur sont écrites en C++ ; Make et Docker sont utilisés pour le build
- Le matériel réel testé inclut notamment les Lenovo x240, Asus Eee PC series, Dell Optiplex 780, Samsung N150 Plus, Samsung NP-NC10 et l’IBM Thinkpad a21p
- Les modes d’exécution pris en charge sont QEMU, le v86 de copy.sh et le démarrage sur matériel réel ; sur un appareil physique, le fichier
.isoest gravé sur USB ou CD avec GRUB ISO - La feuille de route indique comme éléments déjà implémentés le bootloader, l’ordonnancement préemptif multithread, le système de fichiers, le gestionnaire de fenêtres graphique, la pile réseau, les threads en espace utilisateur et un terminal virtuel distant TCP
Vue d’ensemble de RetrOS-32
- RetrOS-32 est un projet de système d’exploitation hobby 32 bits centré sur l’architecture i386
- La description du projet le présente comme un système d’exploitation hobby 32 bits avec graphisme, multitâche et réseau
- La date de démarrage indiquée est le 12 mai 2022
- La page du projet renvoie vers Project OSHub page
Connexion et utilisateurs
- Les trois utilisateurs par défaut sont system, admin et guest
- Le mot de passe admin est
admin, et guest n’a pas de mot de passe - Il n’y a actuellement aucune différence entre admin et guest
- Les utilisateurs peuvent être créés avec la commande
admin create <username> <password>
Langages d’implémentation et configuration du build
- Le kernel, les utilitaires et le système de build sont écrits en C et Assembly
- Les applications en espace utilisateur sont écrites en C++
- La compilation utilise Make
- Docker est utilisé pour la compilation cross-platform
Matériel testé
- La liste du matériel réel testé est la suivante
- Lenovo x240
- Asus Eee PC series
- Dell Optiplex 780
- Samsung N150 Plus
- Samsung NP-NC10
- IBM Thinkpad a21p
Build et exécution
- En environnement cross-platform, il faut Docker pour compiler les fichiers image et QEMU pour l’émulation
- Les dépendances de compilation native varient selon la plateforme
- MacOS :
i386-elf-gcc,i386-elf-ld,i386-elf-g++ - Linux / WSL Ubuntu :
build-essential,gcc-multilib - Pour utiliser GRUB comme bootloader,
grub2,xorrisoetxxdsont aussi nécessaires
- MacOS :
- Sous Linux, le build et l’exécution se font en clonant le dépôt, puis avec
./debian.sh, l’initialisation des sous-modules Git,make compile,make img, puismake qemu - Sur MacOS, la compilation native n’est actuellement pas possible car les outils de build dépendent de code x86 32 bits ; Docker est la méthode la plus simple
- Sous Windows, il faut utiliser Docker ou WSL
- Trois modes d’exécution sont pris en charge
- téléverser le fichier
.imgcomme image disque dur dans le v86 de copy.sh - lancer
make qemuouqemu-system-i386 <image name>dans QEMU - sur matériel réel, graver le fichier
.isosur une clé USB ou un CD et utiliser GRUB ISO
- téléverser le fichier
Structure du projet
- L’arborescence du dépôt est divisée en répertoires pour le kernel, les pilotes, les graphismes, le réseau, le système de fichiers, les bibliothèques, les applications en espace utilisateur, les tests et les outils
bootcontient un bootloader personnalisé etmultiboot.ldkernelcontient les principales sources du kernel, le code spécifique à l’architecture et le code des threads du kernelappscontient les applications en espace utilisateur ainsi quelibcore.a,libgraphic.aetlibnet.anetcontient le code réseau, etfsle code lié au système de fichierstoolscontient les outils et scripts de build
Éléments implémentés et travail restant
- Côté démarrage, le bootloader personnalisé, la compatibilité GRUB et le bootloader Stage 2 sont terminés
- Les fonctions kernel et système incluent notamment
- ordonnancement préemptif multithread
- séparation kernel / espace utilisateur basée sur GDT et TSS
- gestion des interruptions
- IPC
- appels système
- threads en espace utilisateur
- Les pilotes et fonctions matérielles incluent clavier et souris PS/2, PIT, VESA
640x480x8, RTC, Serial, E1000 et PCI - Pour le système de fichiers et le stockage, le pilote ATA IDE, un système de fichiers de type Ext2, FAT16, ainsi que la lecture et l’écriture sont terminés
- FAT16 prend en charge des fichiers jusqu’à 32MB
- Atapi n’est pas encore terminé
- Les fonctions mémoire incluent mémoire virtuelle 32 bits,
kalloc/kfreecôté kernel etmalloc/freeen espace utilisateur - Les fonctions graphiques incluent un gestionnaire de fenêtres, GFXLib, le rendu en double framebuffer, les événements souris, le redimensionnement dynamique, le plein écran et une bibliothèque de widgets
- Custom HTML to Widgets n’est pas terminé
- La pile réseau comprend Ethernet, IP, ARP, UDP, Socket API, interface Loopback, DHCP, DNS, TCP et des commandes de style netcat
- Webserver, FTP, IRC, SSH, Telnet, HTTP et HTML ne sont pas terminés
- Les applications et outils comprennent un terminal, un serveur de fenêtres, les informations de processus, Finder, un compilateur C / interpréteur de bytecode, une VM personnalisée pour exécuter le bytecode, un éditeur avec coloration syntaxique, une calculatrice, un jeu 3D, un Snake en mode texte, un terminal virtuel distant TCP et une bibliothèque de compression LZ
- La liste complète des fonctionnalités proposées et des problèmes connus se trouve dans open issues
Licence et liens du projet
- RetrOS-32 est distribué sous MIT License
- Lien du projet : https://github.com/joexbayer/RetrOS-32
1 commentaires
Avis sur Hacker News
Ce genre de projet est bien plus agréable à voir que de l’IA sans intérêt. Ce ne sera sans doute pas un produit vendable, mais c’est un technicien qui déploie sa créativité et son savoir-faire.
À la fin de mon adolescence, j’ai beaucoup étudié le développement d’OS comme hobby, et c’était vraiment génial ; aujourd’hui encore, je fais parfois de petits noyaux. Le dernier que j’ai créé était un petit noyau RISC-V qui affichait un message pour ma partenaire.
J’aimerais que la police système par défaut ait une variante plus étroite. Le système aurait l’air beaucoup plus soigné, et on voit pas mal d’endroits où les caractères auraient besoin de moins d’espace horizontal.
Il faudrait réduire la largeur de chaque caractère et resserrer autant que possible l’espacement entre les lettres. Avec la taille de police et la résolution actuelles, un espacement de 1 pixel semble suffisant.
Je ne connais pas bien le système de polices, mais j’ai supposé qu’il s’agissait d’une police bitmap à chasse fixe. Si c’est trop difficile à changer dans la base de code, ce n’est pas grave.
Moi aussi, je construis depuis quelque temps un site de type OS web à partir de zéro, et j’ai récemment réécrit toute la classe de polices, donc ce point m’a particulièrement sauté aux yeux.
J’ai aussi regardé du côté d’un vrai rendu de polices et c’est sur ma todo list, mais je n’ai cessé de le repousser.
« J’ai créé un système d’exploitation ! »
« Hmm, la police n’est pas terrible. »
C’est vraiment le sommet de HN.
Super. Je me demande ce que tu ferais différemment si tu recommençais aujourd’hui.
Je suis aussi curieux de savoir quel langage tu juges adapté aux parties bas niveau : resterais-tu sur C, utiliserais-tu un sous-ensemble simple de C++, ou envisagerais-tu un langage plus récent ?
Il y a énormément de ressources, et je me demande aussi comment tu as gardé le projet intéressant au lieu de copier le code des autres.
J’aurais aussi probablement essayé de réduire la dépendance à UNIX.
Pour le langage, j’aime C pour sa syntaxe de base et son côté direct, qui va droit au cœur du sujet. Pour les applications en espace utilisateur, je pourrais envisager d’autres langages.
Je voulais tout écrire moi-même depuis le début, et ne pas porter de logiciels était au cœur du projet. Dans l’ensemble, j’ai respecté la règle « copie les idées, pas le code ».
Même du point de vue de quelqu’un qui utilisait un Commodore PET 2001 en 1977, c’est vraiment génial. Je bricolais avec KolibriOS et MenuetOSx64, et ça me donne envie de créer mon propre OS. Bravo d’y être arrivé.
Le projet est vraiment impressionnant, et je veux te féliciter. J’aimais le développement d’OS depuis l’adolescence, et ça fait plaisir de voir une telle réalisation concrète.
Je suis aussi un peu curieux de savoir comment le sous-système graphique est initialisé. Bonne continuation.
https://github.com/joexbayer/RetrOS-32/blob/development/grap...
https://github.com/joexbayer/RetrOS-32/blob/development/grap...
J’aimerais moi aussi pouvoir consacrer du temps à ce genre de projet passion.
Oublier l’utilité pratique, oublier la stratégie de mise sur le marché, oublier l’adéquation au marché cible, et simplement construire et apprendre.
L’un d’eux était un OS jouet, mais quand le développement d’OS bas niveau est devenu mon vrai métier, ce projet s’est arrêté.
Je suis dans ce domaine depuis des décennies et j’essaie d’apprendre le développement d’OS. Je connais dans une certaine mesure FASM, NASM et FASM-G.
Mais j’aimerais étudier la sortie des programmes assembleur pour comprendre comment un OS fonctionne réellement au niveau binaire.
Je me demande si tu as appris les codes d’instruction d’une architecture particulière, comment tu as géré les programmes de pilotes de périphériques, et si tu pourrais résumer les étapes pour développer son propre OS.
Il existe aussi quelques tutoriels, mais ils contiennent souvent des bugs et finissent facilement par te faire recréer leur OS.
Je ne suis pas allé aussi loin dans les codes d’instruction ; je les ai surtout consultés quand je faisais un compilateur C, donc je ne connais que les instructions de base les plus courantes.
https://forum.osdev.org/
https://wiki.osdev.org/Expanded_Main_Page
Vraiment génial. J’aimerais voir revenir davantage l’esprit des débuts de l’informatique, où l’on bricolait plus avec l’ordinateur lui-même qu’au niveau des applications.
J’envisage depuis quelque temps de construire un ordinateur personnel comme projet de long terme. Un ordinateur dont j’aurais créé toute la pile logicielle, et pour lequel je connaîtrais l’origine de chaque bit présent dans le système.
Le matériel serait plus difficile à contrôler au même niveau, sauf à obtenir suffisamment de performances avec un FPGA pour tout faire tourner, mais au moins, côté logiciel, ça semble possible.
Jusqu’ici, ça me paraissait irréaliste, mais tu montres que c’est possible. Il semble aussi mettre en œuvre un compilateur C de hobbyiste : https://github.com/joexbayer/C-Compiler
Le compilateur C a été conçu pour cet OS et fonctionne dedans. Le projet devenait trop gros, donc je voulais le séparer du dépôt de l’OS, surtout parce qu’il fonctionne aussi sous Linux.
J’aimerais que tu expliques davantage comment ce compilateur interagit avec le système d’exploitation. Je suis particulièrement curieux de savoir comment il gère des fonctionnalités comme les structures, ainsi que les limites actuelles et les améliorations prévues dans ce domaine.
Les structures sont traitées comme des zones mémoire dont la taille dépend des membres, et l’accès aux membres se fait via des offsets dans cette zone.
Pour l’instant, il y a beaucoup de limites : seulement int et char, pas de switch, etc. La plus grande différence avec le C standard est l’autorisation de fonctions à l’intérieur des structures, et le passage implicite de la structure à la fonction lorsqu’il s’agit d’une fonction de structure. Plus de détails ici :
https://github.com/joexbayer/C-Compiler
C’est l’un des projets passion les plus impressionnants que j’aie vus ici depuis un bon moment. Je me demande pourquoi tu as décidé d’utiliser un compilateur C maison.