Bonjour,
est il possible de programmer un OS uniquement en c et uniquement avec ses bibliothèques standards ? Autre petite questions, existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Version imprimable
Bonjour,
est il possible de programmer un OS uniquement en c et uniquement avec ses bibliothèques standards ? Autre petite questions, existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Non, il te faudra un minimum d'assembleur, ne serais ce qu'en inline.
Dans le cas de Linux, pas de fonction dans le noyau, tu as des fonctions dans les couches graphiques telles que X11. (pour ne citer que lui).Citation:
existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Sur Windows, tu pourras avec la couche DirectX.
Je me permets de modérer ce propos car il est possible d'utiliser le framebuffer directement indépendamment d'un serveur X. La meilleure source de documentation pour ce faire étant je pense les sources d'un programme qui exploite cela (mplayer peut-être ?).Citation:
Envoyé par chrtophe
Certe, je n'ai pas parlé du Framebuffer, mais celui-ci permet d'accéder si je ne me trompe à la RAM video depuis l'espace d'adressage. (et aussi de bénéficier d'accélération matérielle).
Il y a une bibliothèque directFB qui contient peut-être des fonctions de modification de pixels, mais c'est une bibliothèque, ce n'est donc pas intégré "bibliothèque standard".
La question étant :
La libc également appelée bibliothèque standard C ne contient pas de fonctions dédiées à la manipulation de pixels. Il faut compter sur des bibliothèques additionnellesCitation:
existe t il dans ses bibliothèques standards une "commande" pour contrôler un pixel précisément ?
Merci pour vos réponses rapides, avez-vous un livre à me conseiller pour apprendre le langage assembleur d'un maximum de processeurs ? Windows par exemple fonctionne sur pas mal de processeur, il contient des codes sources différents pour chaque processeur ou son code source est unique pour tous les processeurs et s'adapte à eux ?
Windows ne fonctionne que sur x86 et ARM pour les versions Windows RT. Mais je pense pas que se soit le même code, les applis win32 ne fonctionnant pas avec Windows RT. Les applis Modern UI utilisant une API différente, présntes dans les deux versions.Citation:
Windows par exemple fonctionne sur pas mal de processeur
Si tu prends le cas de Linux qui lui gère beaucoup plus de processeurs différents, l'essentiel du code est commun, et des parties spécifiques aux CPU sont présentes. Exemple, Linux gère la pagination à trois niveaux que ne gèrent pas les CPU Intel (seulement 2 niveaux) mais que gèrent les CPU Alpha. Le code est conçu pour sauter le troisième niveau pour les CPU Intel.
Ensuite le code d'amorce est différent.
Les appels systèmes sont les même, mais la convention d'appel est adaptée au CPU, et bien que tu trouve les mêmes softs sur le différents noyaux, les versions sont adaptés au CPU, les applis sont compilés vers le CPU de destination.
Ceci n'est qu'un exemple. Je ne suis pas spécialiste du sujet non plus.
Si le sujet t’intéresses, tu peux regarder ceci :Citation:
Merci pour vos réponses rapides, avez-vous un livre à me conseiller pour apprendre le langage assembleur d'un maximum de processeurs ?
http://chrtophe.developpez.com/tutoriels/minisysteme/
http://systeme.developpez.com/tutori...eloppement-OS/
Pour l'assembleur proprement dit :
http://asm.developpez.com/cours/
http://asm.developpez.com/livres/
Commences déjà par un CPU, se sera déjà pas mal.
Bonjour,
Apprendre l'assembleur n'est plus vraiment obligatoire sauf dans des cas précis. Suivant ce que vous voulez faire, vous devriez peut être vous intéresser à d'autres langages.
Pour l'histoire de jouer avec les pixels, ce que je fais c'est faire un rendu, dans une mémoire qui est gérée par moi même à la même. Une sorte de simulation de l'écran. Ainsi, je peux faire ma taille d'écran que je veux, je peux écrire/lire les pixels comme je le souhaite et le tour est joué.
Si je veux voir le résultat, je sauvegarde en BMP ou un autre format simple et je l'ouvre avec un visualiseur approprié.
En fait ce que je veux faire c'est pouvoir contrôler mon pc intégralement, et ne plus dépendre d'un quelconque logiciel, peut être même par cette volonté créer mon propre langage. Lâché dans ce monde sans logiciel, lire une clé USb ou une souris sera t il possible ?
Oui, c'est possible, tout est possible, mais cela vous prendre du temps, beaucoup de temps.
Je pense qu'au lieu de partir dans une telle direction, il faut mieux regarder les logiciels libres, tel le noyau Linux et les logiciels gravitant autour.
Bonjour,
Nous proposons ici le forum assembleur et son sous-forum programmation d'OS pour les questions relatives à ce sujet. Il est toujours très enrichissant de se prêter à ce genre d'exercice mais sache que c'est extrêmement long, beaucoup plus qu'on l'estime au départ.Citation:
Envoyé par Factorisable
Oui, mais il te faudra par définition tout réécrire depuis zéro (sauf à utiliser les fonctions BIOS, EFI, ou ACPI quand elles sont disponibles) et ré-implémenter toute la pile des pilotes des différentes couches avant d'arriver à lire ta souris ou ta clé USB. Cela va essentiellement dépendre de la machine que tu utilises, mais on considère quand même que c'est un PC.Citation:
Lâché dans ce monde sans logiciel, lire une clé USb ou une souris sera t il possible ?
Un bon compromis consiste à se donner un objectif précis, par exemple « lire la clé USB » et implémenter depuis la base tout ce qui est nécessaire pour y parvenir mais rien d'autre : uniquement la lignée nécessaire à cette tâche en particulier (en s'accordant quand même le droit de mettre en place quelques facilités, comme une console digne de ce nom). Ça implique quand même un bootloader, un système de passage en mode protégé, une initialisation des segments, une prise en charge des principales interruptions, une gestion du clavier (via l'historique 8042, pas directement par l'USB), une initialisation éventuelle des modes vidéo jusqu'à VGA ou SVGA (sauf à rester en mode texte), puis de là, une énumération des bus PCI, l'identification et le mappage en mémoire de l'hôte HCI, une prise en charge partielle du complexe protocole USB en lui-même, une énumération des périphériques USB, l'identification d'un périphérique type « mass storage » et la prise en charge du protocole associé pour pouvoir, enfin, lire un secteur sur ta clé.
Il est tout-à-fait possible d'écrire tout cela en C. Enfin, plus précisément, il est possible d'écrire 99,9 % de tout cela en C. Tu ne pourras jamais échapper à un minimum d'assembleur pour initialiser le mode protégé ou pour lire les ports I/O initiaux. Et c'est très bien comme cela : l'assembleur a été passionnant et nombreuses étaient, dans les années 1980 et début des 90's, les applications 100 % assembleur. Ensuite, les micro-processeurs sont devenus trop sophistiqués pour gérer humainement du code assembleur efficace et les compilateurs C, eux, sont devenus parallèlement très performants à cette tâche.
Tu ne pourras pas non plus t'appuyer directement sur la bibliothèque standard, d'abord parce que celle-ci n'est pas directement engendrée par le compilateur C, mais est mise à disposition du programmeur avec le compilateur, parce que la norme l'exige. Ensuite, parce que cette bibliothèque est faite, par définition, pour s'appuyer sur le système d'exploitation. À dire vrai, c'est là la définition même d'un système d'exploitation : mettre en place les infrastructures minimum requises permettant d'écrire et d'exécuter un programme dans des conditions standardisées.
Par contre, le C est fait pour pouvoir générer du code machine même en l'absence de toute infrastructure préalable (puisqu'il est, entre autres, censé être justement une alternative à l'assembleur). Il te faudra donc réécrire également les fonctions les plus importantes de la bibliothèque standard, par exemple un printf minimaliste.
Enfin, pour répondre à ta question, contrairement au Basic ou à d'autres langages, il n'existe pas en C de commande « standard » pour allumer ou éteindre un pixel donné à l'écran, pour la simple raison que cela dépend totalement de la machine : rien ne dit que ta machine soit dotée d'un écran, rien n'indique que celui-ci soit capable de fonctionner en mode graphique, ni même que tu aies le droit d'y écrire. C'est vrai spécialement dans l'embarqué où tes programmes sont destinés à fonctionner sur micro-contrôleur, dans une machine a priori totalement dépourvue d'interface homme-machine, hormis une connexion série ou réseau.
Par ailleurs, si tu refais ton OS, ce serait à toi de réécrire cette fonction si elle existait. Ce qui nous amène à la partie la plus intéressante : l'architecture des ordinateurs (en général). Pour allumer ou éteindre un pixel, il faut écrire dans la mémoire vidéo. Il s'agit en fait de RAM plus ou moins ordinaire mais qui a la particularité d'être lue automatiquement par la carte vidéo qui, elle, module la tension de sa sortie en fonction de ce qu'elle y trouve. Déposer un octet en mémoire à cet endroit provoque donc automatiquement la modification de l'aspect du ou des pixels correspondants.
Merci beaucoup pour cette riche réponse, où trouver les commandes utilisées notamment pour programmer le printf du langage c ?
Tout d'abordCar avant de refaire printf, il faut savoir comment ça marche, et rien que printf avec les options c'est dense.Code:man printf
Tu peux aussi consulter le code source (mais pas sûr que tu y comprennes grand-chose)
Simplifions : on va dire que tu veux afficher une séries de caractères depuis une chaine.
C'est pas si simple que ça, printf va en fait écrire dans un fichier stdin, donc on rajoute une couche gestion de fichiers. Le noyau va afficher le contenu de stdin à l'écran. Tout cela est un long cheminement qui peut faire un livre (voir plusieurs), car en mode graphique par exemple, tu dois dessiner caractère par caractère (ce que fait l'OS) , selon la police de caractères utilisée.
Pour en revenir à la question originelle, pour modifier un pixel à l'écran, on utilise une fonction d'une bibliothèque. Sans système, cela consiste à modifier 3 à 4 octets en mémoire. Encore faut-il savoir y accéder, car il faut initialiser le mode vidéo dans la résolution souhaitée, puis calculer la position des octets correspondant au pixel à modifier (3 octets pour les valeurs RVB et éventuellement un octet pour le canal alpha par exemple).
Attention, une partie significative d'un OS est son noyau (les deux sont d'ailleurs souvent et incorrectement confondus).Citation:
Envoyé par Factorisable
Le code d'un noyau ne peut en général pas utiliser de bibliothèques standard puisque ces dernières s'appuient elles-mêmes sur noyau...
Puis-je vous demander une dernière chose, comment appelle t on le rassemblement de processeur ayant le même langage assembleur ?
Je pense que l'on parlera d'architecture (x86,x64, ARM)...
Attention, toutes les fonctions de la bibliothèque standard ne n'appuient pas sur le noyau: celui-ci est évidemment nécessaire pour l'accès aux fichiers et l'allocation mémoire, mais les fonctions de manipulation de chaînes, de mathématiques ou de tri sont indépendantes (à supposer qu'elles n'aient pas besoin d'allocation mémoire).
Je trouve le projet un peu trop ambitieux pour quelqu'un qui ne sait pas grand chose ^^'
Pour connaître l'assembleur en général si tu en connais un , il est facile d'en connaître un autre , mais c'est pareil pour les autres langages de programmation.
La question suppose que tout les printf sont codé de la même manière , mais en faite cela dépend énormément de la machine (quand la dite machine possède un écran evidamment).Citation:
Merci beaucoup pour cette riche réponse, où trouver les commandes utilisées notamment pour programmer le printf du langage c ?
Par exemple sur les vielles consoles ,ils ne possèdent pas de mode console(ou mode texte comme tu veux) , il est obligatoire d'envoyer en VRAM un bitmap font pour afficher du texte.
Pour une image je comprend pour le RVBA , mais pour un framebuffer un RVBA c'est pas un peu étrange ?Citation:
(3 octets pour les valeurs RVB et éventuellement un octet pour le canal alpha par exemple)
Je dis ça mais je n'en sais rien si de nos jours on va sur du Framebuffer en RVBA rien ne m’étonne maintenant :P
C'est surtout utile à l'alignement 32 bits.Citation:
Pour une image je comprend pour le RVBA , mais pour un framebuffer un RVBA c'est pas un peu étrange ?
exemple mode VESA 32 bits 1024x768 : 0x138
Bonjour,Citation:
Envoyé par Obsidian
Désolé de ressortir un sujet de 1 mois, bien que je n'ai pas la prétention d'écrire un OS, je me demande bien pourquoi on ne peut pas échapper à de l'assembleur pour certaine chose ?
Moi qui travaille sur microcontroleur, le C permet de faire vraiment tout. Il suffit simplement de connaître l'adresse des registres et avec un pointeur c'est réglé.
Pourquoi c'est différent sur un PC ? Je pense au mode protégé par exemple car si j'ai compris, c'est un bit à passer à 1 dans un registre et si l'adresse du registre est connu alors on peut le faire en C ? Non ?
D'avance merci.