Journal MenuetOS : 1.0

Posté par (page perso) . Licence CC by-sa
Tags : aucun
22
18
mai
2015

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!

MenuetOS

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 . Évalué à 5. Dernière modification le 18/05/15 à 16:54.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Intérêt

    Posté par . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . Évalué à 1.

            interface graphique jusqu'à 1280×1024 c'est quoi cette limitation bizarre???

            C'est celle d'un écran 19" 4/3

            Opera le fait depuis 10 ans.

    • [^] # Re: Intérêt

      Posté par . É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 (page perso) . Évalué à 10.

      Bien sûr qu'il y a un intérêt !

      revient à la mode

      l'azerty est ce que subversion est aux SCMs

      • [^] # Re: Intérêt

        Posté par (page perso) . É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 (page perso) . Évalué à 1.

          Ahah, joli :)

          Je m'interroge sur le

          sys.write
          

          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).

          • [^] # Re: Intérêt

            Posté par (page perso) . Évalué à 4.

            Elle cache un code à peu près équivalent à

            mov eax, SYSTEM_WRITE
            int 80h
            

            en réalité l'appel à int 80h est 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 . Évalué à 9. Dernière modification le 18/05/15 à 17:41.

    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.

    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 . Évalué à 6.

      et ça me rappelle des bons souvenirs

      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 . Évalué à 4. Dernière modification le 19/05/15 à 21:42.

        J’en ai trouvé une autre :

        Le directeur principal du projet est ingénieur en informatique, en réseau, et en électronique, avec un master de maths. Autrement dit, appelez-le Dieu parce qu'il code comme un Dieu. Qui plus est, il a ses entrées chez Microsoft, donc il connaît bien Windows et les (coûteuses) connaissances de ses spécifications (notamment celles requises pour créer des drivers).

        C’est vraiment super pour bien se marrer…

        Édit :

        En ce qui concerne le devenir, le projet sera bien entendu open-source et gratuit. Une double licence permettant aux entreprises de réutiliser le code est à l'étude…

        Gratuit est une licence ;-)…

  • # ambiance sur le projet...

    Posté par . É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 (page perso) . Évalué à 4.

      A noter cette remarque qui me laisse perplexe:

      The reason why Menuet64 is closed source is because Menuet32 was ruthlessly forked and new copyrights slapped to the beginning of almost all 32bit source code, without our permission. Some people don't respect international laws.

      • [^] # Re: ambiance sur le projet...

        Posté par . É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 . É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 (page perso) . É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 . Évalué à 3.

              a été brutalement forké alors qu'il était sous licence libre par des gens qui ne respectent pas les lois internationales

              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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 . Évalué à 1.

    64 bits : license spéciale. […] La redistribution et le désassemblage sont interdits sans autorisation

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.