voilà tout est dans le titre,
je voudrai savoir si le Langage C est suffisant (à lui tout seul sans la moindre instruction d'un autre langage) pour programmer un système d'exploitation ?

merci

oui

est est ce que c'est le plus adapter pour de la programmation système ?
est ce que le principe de programmation système change d'un langage à l'autre ?
où est ce qu'on peut apprendre ça ?
quel sont les connaissance requise pour ça ?

Je crois que tu ne réalises pas ce que représente la programmation d'un OS.

Oué je sais je veut simplement savoir...
Alors pouvais vous me répondre svp ?

Le C standard ? Non. Il faut connaitre l'assembleur, car certaines parties du code ne peuvent être écrites qu'en assembleur. D'autre part, il faut des extensions permettant de manipuler les adresses fixes. De plus, il faut un éditeur de lien qui permet de réaliser un 'boot sector' pour une disquette ou un CD..., qui sache placer du code ou des données à des offsets bien précis...

Enfin, la partie du langage C nécessaire au boot ne peut, par définition, pas utiliser ls parties de la bibliothèque qui font appel aux fonctions systèmes, ... puisqu'il n'y a pas encore de système ! Il peut cependant y avoir un 'micro-noyau' ne servant qu'au boot, qui disparait ensuite au profit du vrai système... Celui-ci peut implémenter une partie des fonctions systèmes nécessaires au C...

Ecrire un système, c'est un énorme boulot. Pourquoi cette question ?

!!!
l'un dit oui (cf Harkonnen) , l'autre dit non (cf Emmanuel Delahaye), je ne comprend pas là,
pourquoi y a il un autre Langage C non standard ou quoi !    
 

J'ai développé... Oui, il existe GNUC qui est un langage issu du C avec des extensions faites pour écrire un système. Ca a permet d'écrire GNU/Linux, par exemple.

jamais entendu parler, donc GNU/Linux est programmer sous GNUC et pas en C contrérement à ce que la plupart disent...
Où est ce qu'on peut ce documenté sur GNUC ?
 

Merci pour m'avoir un peut eclairer

On lisant ça http://mapage.noos.fr/emdel/dev_proj.htm (pas que ça), ça ma donner des idée futuriste, et ma motivé pour écrire un système, (pas tout de suite lol et pas tout seul)...
je sais que c'est un énorme boulot, mais j'ai mis ça dans ma tête et même si ça me prendrai toute ma vie pour le faire

Bah, faut pas croire ce que disent les non-informaticiens...

http://www.gnu.org/software/gcc/

Tu as de saines lectures, c'est bien !
 

 
Parce que Harko il a le cerveau mou depuis qu'il cottoie des juristes.
(j'pense il a simplement zappé l'assembleur tellement c'est naturel de l'inclure, quel que soit le langage, quand il s'agit de développer un OS)

ouiiiiiiiii
 

voila ! pas d'OS sans assembleur, meme inliné dans le code C

Avec la merveilleuse syntaxe AT&T...

putain, clair... rien que de lire ça, je prends 3 points de tension ! cette syntaxe a été pondue par le malin qui était en train de pousser sur ses chiottes

Si tu veux regarder à quoi ressemble un OS codé en C+Assembleur, faut aller sur www.kernel.org (sur le FTP, y a toutes les versions depuis la 0.01 jusqu'à la 2.6.20.2)
 
Sinon, GNUC c'est pas un langage. C'est juste des trucs en plus par rapport au C standard, y a pas vraiment de quoi fouetter un chat.

C'est un langage et c'est un sur-ensemble du C standard.  

GNUC n'est pas un sur-ensemble de C. Le contre exemple qui me vient à l'esprit: la différence de sémantique à propos d'extern inline, inline, entre C99 et GNUC (je ne parle pas de 4.3 non encore releasé)

Exact. J'aurais du préciser 'du C90'.

( Les topics C, c'est un peu "tout les chemins mènent à Rome", on peut les commencer comme on veut on peut être surs que les derniers messages du topic vont contenir le mot "sur-ensemble" )

Je ne connais pas la syntaxe de l'assembleur AT&T mais il parais que malheureusement, par défaut, gcc sortent de l'assembleur AT&T ... mais on peut aussi utiliser la syntaxe INTEL sous gcc ...
 
Sinon, vous voulais dire quoi exactement par sur-ensemble du C ?
 

Il n'y a pas "d'assembleur AT&T", mais il y a une "syntaxe AT&T" pour écrire en assembleur inline avec gcc. Nuance... L'assembleur, sur PC, c'est de l'Intel x86, pas le choix !

Tu veux dire, par exemple,  la syntaxe MASM ? Pas à ma connaissance, mais si tu sais comment faire, ça m'intéresse, et je ne dois pas être le seul.

Qu'il (GNUC) englobe tout le C90. On étudie plus la glorieuse théorie des ensembles des années 70 dans les écoles ?
J'ai fait ça en 4ème...
 

Primo: http://sourceware.org/binutils/doc [...] 002dSyntax
Secundo: AT&T > Intel, mais c'est vrai que les % à tout va c'est chiant.
Tertio: Si on a disposition un assembleur capable d'émettre un fichier objet, un linker fonctionnel et un moyen quelconque depuis le langage originel - quel qu'il fusse - d'appeler un machin externe, on a le minimum syndical.
 
En 1973, il n'y avait ni GNUC ou C90 et pourtant...

en fin, je ne sais pas, j'ai lu sertain topic c'est tout:  
http://www.cppfrance.com/codes/ASM [...] 38813.aspx
http://www.traduc.org/~isa/index.p [...] t-vs-intel

voire là : http://www.delorie.com/djgpp/v2faq/faq17_2.html
 

Quelle sont selon vous, les pré-requis (tout ce qu'il faut connaître et savoir) pour un groupe de personne qui veulent apprendre à programmer un Système d'exploitation ?
 

Une patience qui ferait perdre pied au moine bouddhiste le plus aguerri, un entêtement qui ferait passer l'âne le plus buté pour une girouette, et le double de la capacité de travail d'un chinois bossant dans une usine de textile.

C'est quoi cette manie de vouloir écrire un SE ? Il en existe de très bons, pourquoi vouloir réinventer la roue ?
Les vrais problèmes se situent au niveau des applications, qui sont le plus souvent mal définies, mal conçues, mal écrites et mal testées...

Là, il y a du boulot...

Sinon, pour faire un SE, il faut de l'expérience en programmation organisée et et bien connaitre les interfaces hard/soft (pour la partie driver).

D'autre part, il faut être un expert en processus, commutation de tâches etc. Une très bonne connaissance de la cible (assembleur) peut aider pour écrire un scheduler performant (on ne programme le programme pas pareil pour un 80386, pour un Duo Core, ou un Athlon 64...

Ensuite, il faut savoir gérer la mémoire (RAM, disque...), les protocoles réseaux courants ...

Mais lol, je ne parle pas question enthousiasme,
Mais question Connaissance technique quoi...
 
 
Merci pour ces quelque précisions Emmanuel Delahaye.

 
Enthousiasme. Ca rime avec miasmes.

MIASM32 ?

Joli !
 

Assembleur 16 bit ?
32 ?

32 bits bon dieu ! 32 BITS §§§

L'Assembleur 16 bit est si useless que ça ?!
C'est dépassé pour les applications 32 bit, mais tout PC boote en 16 bit (mode réel), donc je ne croie pas que c'est si inutile que ça, Harkonnen...

Ah, bah tu vas être franchement limité pour l'addressage mémoire et autre joyeuseté ayant besoin de grands nombre

Ouais, mais generalement il y reste pas longtemps
 
Et pour repondre a ED, la manie de vouloir ecrire des SE c'est surtout l'envie de savoir ce qui se passe "reellement" dans ton PC lorsque tu appelles une API depuis le mode utilisateur. Je pense qu'une fois qu'on a compris comment ca marche, on realise que les SE actuels ne sont pas si mals fichus que ca ... et sont meme a des annees lumieres a ce qu'une bande de potes "motives" pourrait aboutir.

Ca dépend de la cible. Pour du x86, les deux bien sûr (le boot se fait en 16-bit).

 
oh serieux ?

En fait, ma derniere phrase etait plus ou moins a l'attention de CreaRetour.