Programme C qui fonctionne au boot (sans OS)

Bonjour, je cherche à comprendre ce qu'est exactement un programme compilé en C.

Prenons l'exemple d'un programme en C compilé sur XP et qui n'utilise que la bibliothèque stdio. Il est écrit en langage machine mais utilise les dlls comme msvrct par exemple. Le programme est donc dépendant de ces dlls et ne peut fonctionner sans. Est-ce que c'est bien à cause de ça (et uniquement) qu'il ne fonctionnera pas sous Linux par exemple? C'est une vraie question que je me pose.
Je veux dire que si le programme ne nécessitait aucune dll, serait-il pour autant portable, tel quel, sur un autre OS avec le même processeur?

Je me demande aussi: si on "collait" l'ensemble du code machine que représente le programme (exécutable + multiples dlls chargées) est qu'il serait compréhensible par le processeur seul?

En bref un programme compilé dialogue directement avec le processeur sans passer par l'OS?

Tout ça pour demander: comment créer un programme qui marche sans os (lancé par un programme de boot par ex) à partir d'un compilateur C?

Je suis presque sur que les librairies (.lib) qui sont liés au programme à la fin de la compilation ne sont pas les même selon des OS. Un appel à malloc sur Windows de sera pas pareil qu'un appel à cette même fonction sur linux, car la mémoire est gérée par l'OS. Il en est de même de toutes les fonctions comme printf. Même sans utiliser de librairies, je crois qu'il y a des différences en un executable windows et un executable linux (mais je ne sais pas lesquelles). De toute façon tout programme est lié à un minimum de librairies à la compilation (les fichiers startup).

Si tu veux faire un programme executable au démarrage de l'ordinateur, je crois qu'il faut le faire en assembleur (bonjour la galère).

Salut,

Chaque OS définit son propre format de binaire exécutable (PE sous Windows, ELF sous Linux, ...).

Chaque plateforme doit implémenter les fonctions de la lib C et génère des appels systèmes (pour tout ce qui I/O) qui sont propre à l'OS. Par exemple, un fopen(), sous Windows, appelle CreateFile(), ...

Un programme de boot est lancé avant l'OS et est écris en assembleur (amorçage) et éventuellement une partie en C.

Tu peux télécharger le source de LILO pour te faire un idée.

Les OS sont donc beaucoup plus impliqués que ce que je pensais alors.

Quand tu dis qu'une partie du programme boot peut être écrite en C, dans ce cas on compile la partie C avec quoi?

Citation:

---

Envoyé par Nykoo

Les OS sont donc beaucoup plus impliqués que ce que je pensais alors.

Quand tu dis qu'une partie du programme boot peut être écrite en C, dans ce cas on compile la partie C avec quoi?

---

avec un compilo C !

Pour plus d'infos (en anglais) sur la notion de boot : booting

Merci à vous deux je vais voir ça.

Citation:

---

Envoyé par vicenzo

avec un compilo C !

---

J'en doute pas :D Mais avec quel type de compilo C? Puisque qu'un compilateur compile pour un OS spécifique. On compile pas un OS avec GCC quand même?

En fait tu compiles avec un compilateur C qui donne donc du langage machine, mais tu ne fais appel à aucune bibliothèque spécifique à une os, tu as donc un programme indépendant de la plateforme

Citation:

---

Envoyé par Prayeriz

En fait tu compiles avec un compilateur C qui donne donc du langage machine, mais tu ne fais appel à aucune bibliothèque spécifique à une os, tu as donc un programme indépendant de la plateforme

---

Ce programme par exemple qui n'a aucune inclusion serait donc "OS indépendant":

Code:

---

1 2 3 4 5 6

int main(void) { int a = 1; int b = a + 1; return 0; }

---

Citation:

---

Envoyé par Nykoo

Ce programme par exemple qui n'a aucune inclusion serait donc "OS indépendant":

Code:

---

1 2 3 4 5 6

int main(void) { int a = 1; int b = a + 1; return 0; }

---

---

Le programme, non, mais le code oui.

Le code binaire de la fonction est OS indépendant.
Le programme généré est dépendant de l'OS car son format (load, table d'import des symbols, offset codes, ...) est dépendant de l'OS

Ne confond code binaire ASM exécutable et programme !

D'accord j'ai les idées plus claires maintenant je sais vers où chercher. Merci à vous tous!

Citation:

---

Envoyé par Nykoo

Puisque qu'un compilateur compile pour un OS spécifique. On compile pas un OS avec GCC quand même?

---

Bah si, c'est même fait pour ça !

gcc a été conçu au départ pour compiler GNU/Linux (d'où le mode 'kernel').

Ah oui c'est vrai, mais avec des options différentes alors?

Citation:

---

Envoyé par Nykoo

Ah oui c'est vrai, mais avec des options différentes alors?

---

Oui, bien sûr. La doc de gcc est ton amie...

Citation:

---

Envoyé par Nykoo

Bonjour, je cherche à comprendre ce qu'est exactement un programme compilé en C.

Prenons l'exemple d'un programme en C compilé sur XP et qui n'utilise que la bibliothèque stdio. Il est écrit en langage machine mais utilise les dlls comme msvrct par exemple. Le programme est donc dépendant de ces dlls et ne peut fonctionner sans. Est-ce que c'est bien à cause de ça (et uniquement) qu'il ne fonctionnera pas sous Linux par exemple? C'est une vraie question que je me pose.
Je veux dire que si le programme ne nécessitait aucune dll, serait-il pour autant portable, tel quel, sur un autre OS avec le même processeur?

Je me demande aussi: si on "collait" l'ensemble du code machine que représente le programme (exécutable + multiples dlls chargées) est qu'il serait compréhensible par le processeur seul?

En bref un programme compilé dialogue directement avec le processeur sans passer par l'OS?

Tout ça pour demander: comment créer un programme qui marche sans os (lancé par un programme de boot par ex) à partir d'un compilateur C?

---

Chaque compilateur est à priori conçu pour générer du code spécifique à une machine donnée, pour un système d'exploitation donné. Mais des nos jours la plupart des compilateurs supportent plus d'une cible. Par exemple le compilateur Visual C++ (2005) sait générer du code pour x86, x64, ARM, MIPS, etc. C'est au moment de la compilation qu'on spécifie la cible qu'on désire (switch /machine:). En fait, la compilation proprement dite transforme seulement le code source en "module objet", c'est ensuite le linkeur qui se charge de générer l'exécutable. Le linkeur de Visual C++ ne sait produire que du code pour Windows. Mais souvent, après la compilation, le compilateur appelle automatiquement le linkeur pour lier les différents modules objets. GCC (plus précisément ld, son linkeur) sait générer des exécutables pour Windows, Linux, et ... du code binaire plat (switch: --oformat:binary), c'est-à-dire un fichier constitué de code en langage machine uniquement, et qu'on peut donc exécuter directement au boot. Quand à la manière d'écrire ce morceau de code sur le premier secteur, c'est une autre histoire (mais moins longue :lol:). Seulement, le programme d'amorçage est trop spécifique de chaque architecture c'est pourquoi on l'écrit généralement en langage machine plutôt qu'en C (mais on peut le faire en C). C'est généralement le noyau du système qui est écrit en C. Les autres éléments peuvent être ensuite écrits dans n'importe quel langage mais généralement on continue en C. D'après ce que nous rapporte Microsoft (dans le DDK de Windows XP et 2003), le noyau de Windows est écrit en C tandis qu'une petite partie de l'interface graphique est écrite en C++. UNIX et Linux sont entièrement écrits en C.

Citation:

---

Envoyé par Melem

UNIX et Linux sont entièrement écrits en C.

---

Enfin, en ce qui concerne GNU/Linux, dans un langage issu du C qui s'appelle GNUC... Idem pour Windows, qui est écrit en MSC (MicroSoft C).

Citation:

---

Envoyé par Melem

Chaque compilateur...

---

Encore merci, et surtout pour l'option qui permet de générer un binaire plat par GCC!