MenuetOS est passé en version 1.0 le 15 mai 2015.
Menuet ?
MenuetOS est un OS dont le cœur et les applications de bureau sont écrits entièrement en assembleur x86.
Il est compatible 32 et 64 bits.
Ah, tout en assembleur, ça doit donc être un truc tout pourri en mode texte avec une console 80×24 et un multi-tâches coopératif qui freeze à chaque boucle vide ?
Pas du tout! MenuetOS bénéficie d'un multi-tâches préemptif, est multithreadé, et toute la partie utilisateur (y compris l'interface graphique VESA) tourne en ring3 (non privilégié, donc).
Devinez quoi, il supporte même le SMP (limite à 8 processeurs).
Distribution
MenuetOS est disponible sous deux licenses, selon l'architecture visée:
- 32 bits : GPL pour tout le monde.
- 64 bits : license spéciale. Free comme gratuit pour l'utilisation scolaire ou personelle, payante pour une utilisation commerciale. La redistribution et le désassemblage sont interdits sans autorisation.
Il tient sur une disquette (le plus difficile sera d'en trouver une). Sinon, avec une clé USB, cela fonctionne également.
Que faire de Menuet
Son interface graphique
Jusqu'à 1280×1024 en 24 bits (16 millions de couleurs).
Logiciels disponibles
Un media-player complet : n'espérez pas non plus décoder du h264 en ac3 avec.
Un éditeur pour programmer sur place.
Quelques jeux: échecs, tetris … Quake et Doom!
Protocoles
MenuetOS possède une pile TCP/IP , et implémente les protocoles courants (smtp, nntp, http, ftp…)
Support matériel
Une interface graphique rapide est possible via le MTTR des processeurs qui le supportent (tous, jusqu'à preuve du contraire). Il y a même des effets de transparence, calculés au CPU bien entendu.
Pour le son et le réseau (hors loopback), il vous faudra plus de chance. Il semble que les possesseurs de chipsets Intel aient de bonnes chances d'avoir un support sonore et réseau.
L'USB et l'USB-2 sont supportés, ce qui permet par ricochet de faire fonctionner votre souris à roulette, votre webcam (avec beaucoup de chance) ou votre carte d'acquisition Hauppauge (si il y a des amateurs).
Voici une liste du matériel testé et approuvé
Attention, cette liste est un peu vieille, et beaucoup de matériel compatible n'est pas mentionné.
Développement
MenuetOS est développé avec un assembleur maison: le flat assembleur, plus connu (ahem) sous son petit nom: FASM.
Cet assembleur est utilisable sous Dos, Linux ou MS-Windows.
Vous avez lu plus haut qu'on pouvait jouer à Quake et Doom, donc… il y a une libc. Cela va sans dire, mais cela va mieux en le précisant.
La libc est ici.
Bon alors il y a une libc, mais les Vrais Programmeurs respecteront l'esprit de la plateforme:
Petit exemple d'une fenêtre avec glissières de scrolling
Il me le faut!
Quand à FASM, les heureux (si si) utilisateurs d'Arch Linux le trouveront dans AUR:
aur/fasm 1.71.25-1 (44)
A fast and small assembler for x86 and x86-64
# Commentaire supprimé
Posté par Anonyme . Évalué à 5. Dernière modification le 18 mai 2015 à 16:54.
Ce commentaire a été supprimé par l’équipe de modération.
# Intérêt
Posté par ohm . Évalué à 4.
Je me pose quand même une question (honnêtement et naïvement, sans volonté d'être méchant ou de troller) : quel intérêt ? Est-ce une « proof of concept », un jouet pour geek ou bien est-ce un réel besoin pour certaines personnes ?
[^] # Re: Intérêt
Posté par Marotte ⛧ . Évalué à 2.
Pour l’avoir testé un peu, je ne suis pas programmeur et encore moins en assembleur, ça permet d'avoir un système rapide comme l’éclair, mais alors vraiment rapide…
Je m’étais dit à l’époque que la cible de cet OS c’était clairement les gens qui développent en assembleur à longueur de journée.
C'est bien triste que la version 64bit ne soit pas libre.
[^] # Re: Intérêt
Posté par Antoine . Évalué à 1.
Certes, il faudra bel et bien développer en assembleur à longueur de journée pour réaliser quoi que ce soit d'utilisable…
[^] # Re: Intérêt
Posté par Kerro . Évalué à 10.
Je ne pense pas que ce soit rapide du fait du langage, mais du fait que le système est resté très « basique ».
Il n'y a pas des tonnes de choses à gérer, donc ça fonctionne vite. En assembleur, ou en C, ou n'importe quel langage compilé (ou pas ?).
[^] # Re: Intérêt
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9.
C'est bizarre, j'étais persuadé que en 2015, sauf cas pathologiques, un bon compilateur sortait des programmes mieux optimisées qu'un assembleur écrit à la main.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Intérêt
Posté par Maxime (site web personnel) . Évalué à 10.
Pour de petites fonctions, un humain est capable de faire dans certains cas mieux que le compilateur. En revanche, dès que l'algorithme est un minimum complexe (et cela arrive vite), il devient extrêmement difficile de réorganiser tout un code pour améliorer les performances. Sans parler de tout ce qui est maintenabilité…
Je développe dans mon temps libre un OS pour x86 et lorsque j'ai besoin d'un truc très optimisé, je commence par le faire en C et ensuite je check le code assembleur pour voir s'il n'y avait pas moyen de faire mieux. Dans ce cas, je regarde si je peux modifier le code C pour faire en sorte que le compilateur soit capable de faire une optimisation supplémentaire (réorganisation du code, portée des variables, attributs, etc). Et si vraiment on est dans un cas particulier alors je réfléchis à la possibilité de sortir de l'assembleur. Mais c'est vraiment le cas ultime. Comme souvent, on gagne plus de perfs en repensant les algorithmes et structures de données qu'en essayant de faire de la micro-optimisation. Et déjà que c'est la misère pour trouver certains bugs en C, alors en assembleur :/.
[^] # Re: Intérêt
Posté par Neije . Évalué à 9.
Dans la même veine (sorry, je n'ai plus le lien) j'avais lu un très bon article qui comparait, chiffres et diagrammes à l'appui, la différence de performance entre du code assembleur, du c, du c++ et du java je crois (de mémoire).
Bah l'avantage était pas du tout évident. Avoir mieux en assembleur sur une fonction simple, peut être mais sur un soft comme gimp …
Et surtout, ça mettait des petits graphiques en avant du style : temps de développement <=> efficacité gagnée. et alors là, l'assembleur …
Bref, l'assembleur, c'est pour moi un hobby, comme de faire rouler une veille voiture avec un moteur de 20L ;-) ça marche, ça fait du bruit, ça va vite même mais alors ça ne se compare pas avec la techno actuelle … bref, c'est pour la beauté du geste / la nostalgie.
Donc un OS en assembleur, sans les softs qui vont avec, bah c'est comme réparer le moteur de la vieille voiture sans avoir les roues … car on oublie vite, qu'un OS, ça sert à rien. En soi, l'OS c'est là pour faire tourner les vrais outils … (comme le moteur entraîne la voiture … et pas le contraire).
et donc une license restrictive pour un truc qui est censé être pour la beauté du geste, c'est comment dire … je m'interroge … c'est quoi la raison derrière ?
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
[^] # Re: Intérêt
Posté par reno . Évalué à 7.
C'est probablement le cas, mais en assembleur la gestion des ressources est transparente et comme la moindre fonctionnalités te prend 10 fois plus de code qu'en C, j'imagine que le bloat est très, très limité.
Après deux remarques:
1) ça n'a pas l'air très souple comme système MenuetOS: interface graphique jusqu'à 1280×1024 c'est quoi cette limitation bizarre???
2) l'OS qui m'avait bluffé par sa réactivité était BeOS¹ et il était codé en C++ donc c'est possible de faire efficace avec un langage de "haut niveau", mais ça n'est pas la norme malheureusement.
¹: à l'époque BeOS était beaucoup, beaucoup plus réactif et agréable à utiliser que Windows ou Linux.
[^] # Re: Intérêt
Posté par Astaoth . Évalué à 1.
C'est celle d'un écran 19" 4/3
Emacs le fait depuis 30 ans.
[^] # Re: Intérêt
Posté par Le Gab . Évalué à 2.
La recherche de l'efficience, j'aimerais bien voir des choses optimisées pour Raspberry Pi. Étonnement malgré l'énorme versatilité de la plate-forme RasbPi elle est moins intimidante du fait de ses déclinaisons limitées contrairement au monde PC.
Une petite plate-forme universelle, libre qui a sans doute encore pas mal à montrer.
[^] # Re: Intérêt
Posté par reno . Évalué à 2.
Tu as regardé RiscOS?
[^] # Re: Intérêt
Posté par David Demelier (site web personnel) . Évalué à 10.
Bien sûr qu'il y a un intérêt !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Intérêt
Posté par Michaël (site web personnel) . Évalué à 7.
FreeBSD le fait depuis 15 ans! :)
Un exemple de script CGI écrit en assembleur: https://www.freebsd.org/doc/en/books/developers-handbook/x86-environment.html
[^] # Re: Intérêt
Posté par jseb . Évalué à 1.
Ahah, joli :)
Je m'interroge sur le
manifestement destiné à une impression sur la sortie standard.
Que masque cette macro (on est presque dans le haut-niveau là, mais passons) ? Un appel de l'interruption noyau avec la fonction write empilée, ou bien un «syscall/sysenter» pour un switch rapide du contexte ?
(http://wiki.osdev.org/SYSENTER)
Je pencherais pour la seconde forme, plus intéressante et justifiant justement la macro (je n'ai pas été jusqu'à vérifier que c'était le même opcode sous Intel et AMD, bien que la mnémonique diffère).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Intérêt
Posté par Michaël (site web personnel) . Évalué à 4.
Elle cache un code à peu près équivalent à
en réalité l'appel à
int 80hest caché dans une procédure dédiée, peut-être pour éviter des problèmes d'alignement mémoire.Je ne me souviens pas des détails mais la convention d'appel au noyau est différente sous BSD et sous Linux!
# Payant
Posté par MTux . Évalué à 9. Dernière modification le 18 mai 2015 à 17:41.
Je suis quand même très curieux de savoir qui pourrait payer pour un OS en assembleur en 2015 surtout a la vue de ses nombreuses limitations.
Mais bon le concept est marrant et ça me rappelle des bons souvenirs.
[^] # Re: Payant
Posté par karteum59 . Évalué à 6.
Le gars est un marrant (je cite: "Linux est un système d'exploitation de vieil informaticien, fait par des gens pas non plus super-bons en info (le C bas niveau est bien maîtrisé, mais le niveau de maîtrise du C++ et de l'ASM est catastrophique)"). Il voulait peut-être faire de la concurrence à MultiDeskOS ? :)
[^] # Re: Payant
Posté par Anthony Jaguenaud . Évalué à 4. Dernière modification le 19 mai 2015 à 21:42.
J’en ai trouvé une autre :
C’est vraiment super pour bien se marrer…
Édit :
Gratuit est une licence ;-)…
# ambiance sur le projet...
Posté par Benbben . Évalué à 3.
cela à l'air d'être calme et détendu … lol
http://board.flatassembler.net/topic.php?t=16822
[^] # Re: ambiance sur le projet...
Posté par Nitchevo (site web personnel) . Évalué à 4.
A noter cette remarque qui me laisse perplexe:
[^] # Re: ambiance sur le projet...
Posté par Marotte ⛧ . Évalué à 3.
Bah en gros qu’on leur a piqué le code assembleur quand on avait besoin de code assembleur pour d'autres OS 32bit ?
Mais effectivement si la version 32bit était sous GPL ils ne peuvent pas dire : « without our permission » :/
[^] # Re: ambiance sur le projet...
Posté par arnaudus . Évalué à 4.
Ça n'est pas complètement clair, mais ils ont l'air de dire qu'ils ont disparu des auteurs du code source, ce qui est en effet un problème. Mais bon, quand on héberge et développe un projet et que le projet fonctionne, il n'y a aucune raison que les forks deviennent populaires. Un projet forké, c'est le plus souvent un projet qui a de vrais problèmes de gouvernance, c'est plus un symptôme qu'une cause…
[^] # Re: ambiance sur le projet...
Posté par Nitchevo (site web personnel) . Évalué à 2.
Je crois comprendre que leur projet (version 32 bits) a été brutalement forké alors qu'il était sous licence libre par des gens qui ne respectent pas les lois internationales….
Soit mon anglais est pire que je ne le pensais (à ne pas exclure) soit c'est, sur le plan des licences du grand n'importe quoi, motivé le cas échéant par des rancoeurs liés à un fork agressif.
[^] # Re: ambiance sur le projet...
Posté par arnaudus . Évalué à 3.
C'est leur explication. Mais ça n'a pas l'air très convainquant ; d'une part, il y a clairement une forme de xénophobie (le forkeur est Russe, et apparemment, il y a comme un climat de guerre froide). En essayant de reconstruire les morceaux à partir de la discussion (je ne garantis pas avoir tout compris), un contributeur russe trouvait que les versions patchées ne sortaient pas assez souvent et il a donc décidé de proposer des versions "à lui". Ça n'a pas plus au mainteneur principal et la situation s'est envenimée ; la version 64 bits a été rendue non-libre, et du coup l'autre gars a réellement forké. Le différend semble lié au fait que dès le fork, le nom du forkeur a été ajouté à tous les fichiers, sans lien avec d'éventuelles modifs. Ça ne me semble pas non plus catastrophique…
[^] # Re: ambiance sur le projet...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Le site du fork en question: http://kolibrios.org/fr/
Il me semble que la communauté de KolibriOS est un peu plus impliquée dans le libre, avec une participation régulière au Google Summer of Code et au moins quelques uns des développeurs assez présents sur les canaux IRC de Freenode. Je n'y ai jamais vu de développeur de MenuetOS.
Je n'ai pas tous les détails, alors, je vous laisse vous faire un avis.
[^] # Re: ambiance sur le projet...
Posté par MTux . Évalué à 2.
Ça se compile l'assembleur ? Il y a vraiment une notion de source et de binaire ?
[^] # Re: ambiance sur le projet...
Posté par Renault (site web personnel) . Évalué à 10.
Ça s'assemble.
L'avantage est que tu as accès aux symboles et aux commentaires, ce qui est précieux. Le code assembleur peut utiliser des instructions qui n'existent pas dans le préprocesseur pour simplifier la lecture et l'écriture du code…
Bref, entre un assembleur fait main et lire un programme désassemblée, ce n'est pas vraiment la même chose à mon goût.
[^] # Re: ambiance sur le projet...
Posté par chimrod (site web personnel) . Évalué à 5.
Tu confonds assembleur et langage machine !
Tu as des exemples de code sur la page de wikipédia
[^] # Re: ambiance sur le projet...
Posté par téthis . Évalué à 2.
Le code assembleur est généralement la transcription humaine du langage machine et des données nécessaires au programme. La variation vient du fait que les assembleurs permettent de travailler à un niveau un peu plus élevé que le langage machine grâce aux macros et au préprocesseur.
Fasm permet de faire des choses bien sympathiques comme par exemple, à l'aide de macros, écrire un assembleur pour une machine virtuelle et en générer du code machine. Il peut donc y avoir de très grandes différences entre le source et le binaire.
http://bos.asmhackers.net/docs/FASM%20tutorial/preproc.html
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
# Oui, enfin ...
Posté par Plume . Évalué à 1.
A moins que tu ne sois en Europe. Le rétroingeniering y est strictement autorisé. L'interdiction du désassemblage ne touche donc seulement une minorité des personne présentes sur ce site.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.