La question intiale est "Quel langage peut-on utiliser pour développer un système d'exploitation ?", ce qui sous entends qu'il n'y a pas encore de système d'exploitation avec lequel interragir.Envoyé par capucine1983
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
La question intiale est "Quel langage peut-on utiliser pour développer un système d'exploitation ?", ce qui sous entends qu'il n'y a pas encore de système d'exploitation avec lequel interragir.
Système et sur-système
Bonjour à tous,
je ne sais pas si la question a été abordée, mais avant de me demander "comment" je me demanderais "quoi", et plus précisément:
- Qu'est ce qu'un système, à minima?
- Quelles sont les fonctionnalités supplémentaires qu'on peut attendre?
- Est-ce qu'un sur-système telle que Windows 3.1 ou X11+KDE sont des systèmes?
Pour ma question sur le sur-système, je cherche en fait à introduire l'idée que n'importe quel langage permettant de faire une couche d'abstraction au-dessus d'un système permettrait ainsi de réaliser un sur-système Graphique ou un Shell.
Ceci afin de ne pas avoir à redévelopper toutes les fonctions d'un sytème complet, tache qui me parait fastidieuse...
J'avais notamment eu l'idée de faire un sur-système Java, masquant complètement le système réel, et fonctionnant uniquement avec des programmes Java pur, et centralisant toutes les actions système.
Si vous connaissez "BeanShell", cet librairie permet de faire une partie de cela en réalisant un bureau Java permettant d'ouvrir des fenêtre de Shell, de lancer des Classes.
Pour l'anectdote, cette idée farfelue m'est venue en pensant que le système prend part entière avec le matériel (car le matériel sans logiciel n'est rien), alors que la machine virtuelle Java est en quelques sorte un matériel virtuel, el n'est associé à aucun système virtuel.. donc difficile de la comparer à une machine réelle, celle-ci serait-elle Windows, Linux?
j'en revient à mes question sur un système "à minima" et à ses fonctionnalités supplémentaires, dans quelles catégorie dont-on classer les suivantes:
- Scheduling des processus
- Gestion de la mémoire virtuelle/réelle
- Gestion des fichiers
- Shell
- Affichage graphique
- autres ...? (votre avis, dites moi ce que j'oublie)
Pour changer complètement d'orientation, prenons l'exemple du petit prog en C qui boote sur une disquette: est-ce qu'on peut considérer qu'un simple boot qui charge le restant de la disquette, mais sans prendre en charge les disque ni d'écran graphique est un système?
t as des codes sources pour ecrire un os ? je programme qu en java. java est aussi rapide que c++ maintenant
en aucun cas un langage managé n'est adapté au développement d'un OS.
tu veux des sources d'un OS ? regarde les sources de linux... ca te donnera deja un bon apercut de ce que cela peut nécessiter.
Ensuite pour développer un OS, tout langage (sauf managé) est utililsable.
Tout est question de rentabilité...
On peut développer en PROLOG tout ce qui est faisable en C++, et oui n'en déplaise à beaucoup.
En réalité, tous les langages (vrais langages de developpement, pas les trucs de scripting) sont "équivalents".
Il faut bien comprendre que chaque langage quelqu'il soit repose sur un modele mathématique, et qu'a ce jour, tous les modeles de calculs se valent... AUCUN NE PERMET DE CALCULER PLUS DE CHOSE QU'UN AUTRE.
En revanche pour développer un OS, connaitre l'assembleur est quasi primordial. En effet, que vous soyez sous linux, unix, ou meme windows, la libc/libc++ contient pas mal de code écrit totalement en assembleur, c'est malheureusement nécessaire pour être sure de ce qui sera réellement compilé, et des alignement, des offsets .... Pour le reste, ce n'est pas primordial, et n'importe quel langage qui compile en natif directement fait l'affaire.
Toutefois il demeure quelques langages non managés encore moins adaptés que des langages managés, la raison est simple, il y a quand meme des runtimes à trimbaler pour les faires fonctionner... c'est le cas de VB (VB.NET lui c'est parce qu'il est managé)
Pour ce qui est scheduling et de la gestion mémoire...
C'est une question d'architecture.
En effet, jusqu'à la version 2.6 des noyaus linux, par exemple, le noyau n'était pas préemptible, en d'autre terme, il était impossible d'intérrompre un process (thread ou ce que vous voulez) qui était en mode kernel et exécutait une fonction "système"... Depuis l'avenement des noyaux 2.6 cela est possible si le noyau est compilé avec le mode préemptible.
Il y a n architectures et modeles différents, aucun n'est bon ni mauvais. Tout est question de choix et de préférences et de besoins.
Si tu prend pour exemple le modele mémoire Windows (NT ou n'importe lequel) et le modele mémoire Linux, BSD... tu verras une différence... c'est pas dans la facon de gérer la mémoire qu'il ya une vraie différence, c'est dans l'architecture choisie, ce qui forcément rend la gestion différente.
- Dans un systeme linux, unix, chaque process dispose de TOUT l'espace mémoire théorique moins 1Go réservé au kernel. Aucun d'entre eux ne partage son espace mémoire avec un autre, chacun est totalement isolé. On appel cela l'environnement virtuel. Donc lorsque tu code sous linux, tes pointeurs contiennent des adresses virtuelles qui n'ont rien avoir avec l'adresse physique.
- Dans un système windows, c'est très différent, la notion de mémoire virtuelle n'a rien avoir avec la notion de virtuelle de linux.
Tous les process et threads partagent TOUT l'espace mémoire virtuelle, cet espace mémoire virtuel est composé de la mémoire physique et de l'espace disque dans le fichier d'échange. Ainsi, un process dispose de zones mémoires à lui, mais les autres programmes aussi. Quand tu manipule un pointeur sous windows, ce pointeur n'est pas virtuel, ainsi il mene OBLIGATOIREMENT vers une zone mémoire physique existante, qui peut d'ailleur ne pas t'appartenir... C'est d'ailleurs là dessus que compte les trainers pour modifier le fonctionnement d'un jeu, ce qui est impossible sous linux de par son modele mémoire radicalement différent.
Ce n'est qu'un exemple bien entendu, mais c'également à l'origine d'un problème fréquent sous windows.
- sous unix quand une appli quitte, peu importe comment, TOUTES les ressources quelles qu'elles soient possèdées par l'appli sont libérées, surtout la mémoire, dans ce contexte, la mémoire occupée par une appli ne peut pas subsister et doncsi avant t'avais 1.5Go de libre, après tu retrouve 1.5Go de libre (si ta pas fait autre chose)
- sous windows, la mémoire peut être partagée entre application, juste en ce filant le handle de réservation, ou le pointeur, par conséquent, windows ne libère pas la mémoire supplémentaire occupée par une appli, c'est donc le cas de tout ce qui est alloué sur le tas. (hormis la pile, le segment de code, et le segment de données) et il est là le probleme, tout le monde accuse windows, mais en fait non... le problème c'est les appli, meme celles de microsoft pour certaines "oublies" de libérer toutes les ressources qu'elles ont demandées. c'est aussi due pour beaucoup à la méconaissance des différences d'architectures des developpeurs. Ainsi certains on appris à développé sous linux et que sous linux ya libération, ils pensent donc (meme s'ils pensent mal) que c'est pareil sous window...
Rien ne permet de dire que le modèle de windows est moins bon que celuii de linux/unix, il est juste différent, il a des avantages, et des inconvénients, mais c'est le cas du modele unix également.
Bon je suis d'accord la gesion mémoire de windows laisse à désiré mais pas par son architecture mais juste parce qu'elle est bugguée, mais j"ai trouvé des bugs dans celle de linux aussi, et meme sous certains unix qui eux coutent largement plus cher que window...
Ce n'est qu'un exemple, mais sans savoir ou tu va dans ces choix principaux, il est difficile de bien faire un choix d'implantation, ni meme de faire un choix de modele. et donc encore moins de langage.
Non. Les LibC sont écrites en C traditionnellement, sans assembleur. Pour ce qui est de la GLibC, il n'y a pas un goutte d'assembleur.
Les fonctions système telles read(), write() et compagnie sont implantées en faisant directement appel à la fonction syscall() qui implante les appels système du système d'exploitation. Seule syscall(), je crois, doit être écrite en assembleur : tout le reste, c'est du C pur et dûr.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
Des sources complètes, non, Ils me manque les réponses aux questions posées plus haut pour spécifications. Je pourrais éventuellement mettre mon code sur SourceForge, mais ça nécessite un suivi et un première version fonctionnelle.
Voci un petit extrait néanmoins:
Niveau technique, les ClassLoader permette un petite séparation de l'environnement mémoire, le ThreadGroup une séparation de l'environnement d'exécution. J'aurais pu ajouter un SécurityManager. L'ensemble de ces 3 truc me fourni un "Process" du Système. Il manque un réelle gestion d'ordonnancement pour les Thread, et une limitation de la mémoire utilisée.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18public class Lancher{ /*...*/ public Process launch(Class clazz, URL[] classpath) { //what about arguments, params?? BProcess proc = new BProcess();//(Process) loader.load(Process.class,""); proc.id=getIdSequence(); proc.cl = new URLClassLoader(classpath,Thread.currentThread().getContextClassLoader().getParent()); proc.tg = new ThreadGroup(proc.id+"_"+clazz.getClass().getName()); proc.executable = clazz; //Stack Size ! int sz = 1000; Thread pthread = new Thread(proc.tg,new ProcessWorker(proc), proc.id+"_"+clazz.getClass().getName(), sz); pthread.setContextClassLoader(proc.cl); pthread.start(); return proc; }
Par langage managé tu entend dépendant d'une JVM?
Je suis d'accord que pour faire un OS valable aujourd'hui, c'est le couple ASM/C qui semble le plus adapté, (quelle que soient les proportions de l'un ou de l'autre) pour être proche de la machine.
mais le sujet est plus d'apprendre à faire un OS, sans qu'il soit vraiment fonctionnel, ce qui m'avait amené à la question "qu'est ce qui fait qu'un OS peut-être appelé comme tel?"
Un fois les concepts d'un système maitrisé, on peut rapidement voir les limites d'un langage choisi et revenir à autre chose.
pour commencer il faut ecrire le kernel ?
Étape n°1 : le chargeur de démarrage
Il y a JNode qui est un OS écrit en java. Il y a également un peu d'ASM je crois.
Salut,
Pour répondre à la question initiale : C + Asm pour les routines de base, C++ pour les routines de plus haut niveau. Je m'explique : Un OS étant fortement lié à l'architecture matérielle, il convient, pour les couches basses, d'utiliser un langage lui aussi proche de l'architecture matérielle -> C + Asm.
Ensuite, lorsqu'il devient possible de le faire, utiliser le C++ serait appréciable, car selon moi, le découpage objet permet une meilleure maintenabilité.
J'ai un conseil à te donner : regarde du coté de Minix. C'est un projet destiné à expliquer le fonctionnement d'un OS selon la mode Unix. Il est accompagné d'un livre pédagogique expliquant les principes d'un OS.
Après, pour faire ton propre OS, il faudrait faire des choix d'architecture et de design.. Mais à mon avis, tout seul, tu auras du mal à faire quelque chose qui dépasserait le stade "amateur", à moins que tu ne sois un génie capable d'investir plusieurs années de ta vie pour ton projet.. Sans vouloir te décourager ! C'est un bon moyen d'apprendre les langages en questions, et comme il a été dit plus haut, tu peux aussi en choisir d'autres, bien que selon moi ils soient moins adaptés, pour les couches basses tout du moins...
A+
K
Qu'est-ce que le C permet que le C++ ne permet pas?
Je comprends l'avis de ceux qui veulent utiliser C+ASM, comme celui de ceux qui veulent C++ + ASM, mais C++ + C + ASM me semble bizarre.
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Le C++ est selon moi trop lourd pour les couches basses qui se doivent être minimalistes pour que l'OS au final soit performant. A la rigueur, faire une couche basse en Asm pure, pourrait être la meilleure option, cependant, l'avantage du C est de pouvoir partager son travail en communauté plus simplement.
Il suffit de regarder les tests de benchmarks pour voir que pour des opérations algorithmiquement basiques, le C est supérieur au C++ en terme notamment de mémoire ( et accessoirement en performance également ).
Et puis pourquoi utiliser du C++ pour des routines de bases, qui n'ont pas la nécessité d'être codées en objet ( car de toutes façons une fois écrites, elles sont abstraites par les couches supérieures ). Le C++ intervient alors dans mon hypothèse, dans les couches qui seront accessibles par l'API de l'OS..
K
Ma question etait "Qu'est-ce que le C permet que le C++ ne permet pas". Oui il y a des choses qui vont etre codee dans un style proche du C. Mais meme alors, il y a des choses qui peuvent etre utilisee sans perte de performance, parce qu'elles vont generer exactement le meme code mais qui vont apporter un confort plus ou moins grand.
Pourquoi utiliser deux langages semblable mais parfois subtilement different?Et puis pourquoi utiliser du C++ pour des routines de bases, qui n'ont pas la nécessité d'être codées en objet ( car de toutes façons une fois écrites, elles sont abstraites par les couches supérieures ). Le C++ intervient alors dans mon hypothèse, dans les couches qui seront accessibles par l'API de l'OS..
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
je peux avoir les codes sources de "JNode" ?
oui, il est open source. suffit d'aller sur leur site
C'est une idée peut être stupide, mais à priori le C est peut être plus adapté pour les routines de bas niveau même si le C++ fait plus, les librairies linkées sont plus petites cependant non ?
K
1/ On est dans le cadre d'un OS, donc les libs utilisees sont a priori tres fortement controllees (en gros, on part du juste necessaire pour ce qui est demande par le langage et c'est tout; on peut meme s'interdire d'utiliser certaines choses parce qu'il faut un support run-time trop couteux).
2/ J'ai pose la question dans un cadre ou le C++ etait de toute maniere utilise en precisant bien que je voyais des raisons de faire tout en C comme tout en C++. C'est le melange que je questionne. Et je ne le questionne pas uniquement dans le cadre d'un OS mais dans presque tout cadre: je le comprends comme resultat d'une evolution, je le comprends comme resultat d'un partage de code mais pas comme choix delibere sous pretexte que certaines parties sont de bas niveau. Un avantage du C++ est qu'il traite aussi bien le bas niveau que le haut niveau, pourquoi s'en priver?
Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.
Il y a aussi un argument, qui concerne plutôt ma façon d'organiser les choses : quand un code est écrit en C, on s'attend à du code système ( bas niveau ), alors qu'en C++ on s'attend à du plus haut niveau.. Mais tu as raison, autant tout faire en C++ au final si on compte s'en servir par la suite
K
La modélisation objet que permet le C++ est certe utile dans le cadre d'API évoluées, mais est-elle nécessaire pour ce qui concerne la programmation d'un OS ?
Le C++ intègre dans sa bibliothèque standard des routines haut niveau. S'il fallait coder un OS entièrement en C++, comment envisager de coder ces routines ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager