Discussion :

[..::snake::..]

Merci millie ton lien de wikipedia étais ce que je cherchai .

Tout est explqué

[InOCamlWeTrust]

Et les appels systèmes spécifiques ? Ca représentent les 10 derniers pourcents ?

Tu confonds peut-être API et appel système (accessible uniquement depuis l'assembleur ou depuis la fonction C syscall()...).

Lorsque je dis que 90% des problèmes viennent de la non compatibilité des compilateurs entre eux, il faut aussi comprendre que ce sont, en général, les compilateurs qui fournissent également les libC...

[Shugo78]

Tu confonds peut-être API et appel système (accessible uniquement depuis l'assembleur ou depuis la fonction C syscall()...).

fork(), create_Thread() ce sont des APIs ?

[InOCamlWeTrust]

Ce sont des fonctions faisant partie d'une API utilisant des appels systèmes. Il n'existe que très peu d'appels systèmes comparé à la masse de fonctions présente dans une bonne LibC (par exemple la GLibC). La liste des appels système sous Linux est, de mémoire, dans /usr/include/asm/unistd.h et n'est accessible que depuis l'assembleur ou via la fonction syscall de l'API fournie par la LibC : il doit y en avoir 250 ou moins.

C'est un amalgame que trop de gens font, de façon consciente ou inconsciente.

[millie]

Je pensais que les fonctions tel que open, write, étaient des appels systèmes

EDIT : Oui, s'en est, j'ai rien dit.

http://www.die.net/doc/linux/man/man2/syscalls.2.html

[Shugo78]

Ce sont des fonctions faisant partie d'une API utilisant des appels systèmes. Il n'existe que très peu d'appels systèmes comparé à la masse de fonctions présente dans une bonne LibC (par exemple la GLibC). La liste des appels système sous Linux est, de mémoire, dans /usr/include/asm/unistd.h et n'est accessible que depuis l'assembleur ou via la fonction syscall de l'API fournie par la LibC : il doit y en avoir 250 ou moins.

C'est un amalgame que trop de gens font, de façon consciente ou inconsciente.

Désolé de te contredire mais la page que milie a donnée est formelle :
fork() est un appel systèmes(mais pas create_Thread qui est son portage pour windows)
regarde là :
http://www.die.net/doc/linux/man/man2/syscalls.2.html

[jlliagre]

Ce n'est pas contradictoire.

Il existe heureusement des API qui permettent d'encapsuler la plupart des appels systemes, pour éviter que l'on soit obligé de passer par l'assembleur (ou des choses comme syscall). Sous UNIX, ça se trouve dans les pages de manuel 2.

[InOCamlWeTrust]

C'est bien ce que je disais : fork() et compagnie sont des fonctions de la libC qui sont écrites en utilisant les appels systèmes (tels qu'accessibles via syscall()) par exemple.

La grosse différence, c'est que lorsque tu fais appel à fork(), dans ton code assembleur tu te retrouveras avec un CALL fork (fork est bien une fonction encapsulant comme dit plus haut un appel système, le tout codé dans la libC), et si tu fais un appel système violent, tu te retrouveras sous Linux/BSD avec un INT 80h précèdé de ce qu'il faut... ce qui est très différent. On ne peut pas faire une fonction à partir d'un appel système.

On a la même chose sous DOS avec la fameuse INT 31h (de mémoire).

[Shugo78]

Non, DOS est de retour .
Ouf j'ai eu peur....

[InOCamlWeTrust]

DOS existe toujours.

Du moment que Windows continuera à garder une rétro-compatibilité avec ces vieux programmes 16 bits de merde, DOS continuera d'exister, ça c'est une certitude.

J'aime bien les gens qui disent que DOS n'existe plus "parce qu'on ne le voit plus au démarrage" ! Certes, mais tu peux toujours faire tourner des programmes DOS et en faire de nouveaux ! chercher l'erreur dans tout ça...

[Shugo78]

Ah DOS.... Que des bons souvenirs de programmes qui marchaient jamais et qui donnaient jamais le même résultat....
Nostalgie Nostalgie.
Mais bon on n'est pas la pour parler de ça .

[gorgonite]

Ah DOS.... Que des bons souvenirs de programmes qui marchaient jamais et qui donnaient jamais le même résultat....

DOS, ça marchait particulièrement bien et laissait une très (trop) grande liberté à l'utilisateur... comme décharger le système de la mémoire pour lancer Linux

[millie]

DOS, ça marchait particulièrement bien

Tellement bien qu'un petit *((int*)0) = 1, et tu étais parti pour un reboot Ah, que de bon souvenir les OS monotâche

Cela dit, à part avec QBasic, je n'ai jamais programmé pour DOS

[gorgonite]

Cela dit, à part avec QBasic, je n'ai jamais programmé pour DOS

DOS, mon premier système d'exploitation avec des utilitaires comme Turbo Pascal, Turbo Basic (tellement mieux que QBasic ), Turbo C++ et Turbo Assembleur ; et d'autres trucs moins bons... comme win 3.1

[Katyucha]

On peut revenir à la question initiale?

[Celelibi]

__snake__, j'ai l'impression qu'il te manque certaines bases.
Donc je te propose de reprendre depuis le début.

Le langage C
Il existe des normes qui décrivent ce qu'est le langage C. Prenons le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#include <stdio.h>
 
int main (void) {
    printf("Hello World !\n");
    return 0;
}

La norme C ansi impose que la librairie stdio existe et qu'elle contienne entre autre la fonction printf.
La fonction printf possède au moins un argument qui est la chaîne de format. Dans le cas où il n'y a qu'un seul paramètre c'est cette chaîne qui sera envoyée tel quel (après transformation des \n \t etc.) sur la sortie standard (généralement reliée au terminal, mais ceci n'est pas défini).
La norme C ansi dit aussi à peu de chose près que la fonction main est appelée automatiquement au lancement du programme, et que la valeur de retour de cette fonction a une signification dépendante du système (mais là je suis pas sûr).

Autrement dit, tous les compilateurs respectant la norme C ansi devraient fournir un exécutable qui fait exactement la même chose bien que l'exécutable fourni soit totalement différent.


Le compilateur
C'est un programme qui est chargé de transformer le code source (ici écrit en langage C) en un fichier exécutable qui pourra être exécuté par le système.
Si le compilateur respecte la norme C ansi, le fichier exécutable donnera le résultat attendu (ici, l'affichage de "Hello World !\n" dans le terminal).
Mais pour donner ce résultat, le compilateur windows va utiliser les librairies de windows qui elles-même utilise des appels système de windows. Ensuite il va "encapsuler" le code exécutable dans un format (le format PE) de façon à ce que le système windows puisse charger plus facilement le code en mémoire. Le format PE ne sert qu'à rajouter des informations sur le code lui-même (par exemple la taille du code, la taille des données etc.).
Et pour finir, il met le code et son "enveloppe PE" dans un fichier hello.exe (mais ce n'est rien d'autre qu'un nom de fichier).

Le compilateur Linux lui va utiliser les librairies de Linux, qui utilisent des appels système de Linux, puis il va encapsuler le code dans un format ELF qui contient à peu près les mêmes infos que le PE.
Et enfin le code et son "enveloppe ELF" sont écrits dans un fichier hello. Encore une fois ce n'est qu'un nom de fichier, on pourrait mettre n'importe quoi.


Le système d'exploitation
Lui, il fourni des appels système (c'est un peu comme des fonctions, mais intégrés au coeur du système), il fourni des librairies qui lui sont spécifiques et qui tire parti de fonctionnalités qu'on ne retrouve pas forcément sur d'autres systèmes. Ces librairies sont différentes de celles du langage C qui sont en général fournis avec le compilateur.
Le système fourni aussi (ou plutôt impose) un ou plusieurs format(s) d'exécutables que le système pourra lire pour pouvoir ensuite charger en mémoire le programme qu'il contient.


Le processeur
J'en ai pas parlé jusque là pour ne pas tout embrouiller. Le processeur fourni un ensemble d'instructions élémentaires. Le compilateur lorsqu'il compile le code en lui-même, il transforme les instructions du langage C en une suite d'instructions processeur.



La portabilité
On dit qu'un code source (en C par exemple) est portable si on peut le compiler sur différents système sans avoir à toucher au code.
Si le code C utiliser des fonctionnalités qui sont spécifiques à une certaine plate-forme (système d'exploitation + processeur en gros), alors le code n'est plus portable.
C'est là qu'interviennent les normes.
Les normes définissent une syntaxe et une sémantique. Par exemple elle peut définir que la fonction printf doit recevoir au minimum 1 argument, et que cet argument est envoyé sur la sortie standard.
En revanche une norme peut aussi dire que la sémantique de certaines choses ne sont pas défini. Par exemple la sémantique du mot-clé registery n'est pas défini, il ne faut donc pas que le programme repose sur la signification qu'un compilateur à donné à ce mot. Car sur une autre plate-forme, ça sera un autre compilateur et la sémantique de ce mot peut être différente.
(Note : sur une même plate-forme il peut exister plusieurs compilateurs différents comme borland et gcc sous windows. Bien entendu les mêmes problèmes se posent.)



Voilà mon gros pavé, j'espère qu'il t'aidera à y voir plus clair.
Et si j'ai fait des erreurs, au temps pour moi. Que les gourous de ce forum me corrigent.


PS : InOCamlWeTrust, non, DOS n'existe plus, il n'en existe plus qu'une pâle émulation. Ça fait un moment déjà que windows ne repose plus sur DOS (Me à été le dernier).

[..::snake::..]

Je comprend mieux , ce que veux dire portable !
T'as la notion pédagogique Celelibi man

[Shugo78]

La norme C ansi dit aussi à peu de chose près que la fonction main est appelée automatiquement au lancement du programme, et que la valeur de retour de cette fonction a une signification dépendante du système (mais là je suis pas sûr).

Si la valeur peut être différente d'ailleurs pas souçis de portabilitée, il est bien de retourner la constante EXIT_SUCCESS en cas de dérouelement correcte et EXIT_FAILURE si on est amené à quitter à cause d'une erreur.

[souviron34]

mais de toutes façons ça n'a rien à voir avec la question de départ...

Comme on l'a dit 2 ou 3 posts plus haut, QUEL QUE SOIT le langage (y compris assembleur), QUEL QUE SOIT le type de fonction utilisé (système ou non), NOUS programmons en texte (heureusement, sinon ce serait pénible)..

Pour traduire ce texte en instructions machine, les compilateurs ont besoin de connaître les caractéristiques de la machine sur laquelle ils tournent, et les instructions auquelles elle répond.

Ils traduisent donc notre texte en langage machine EXECUTABLE. Bien évidemment cette traduction est dépendante de la machine et du système d'exploitation.

D'où l'impossibilité (sauf maintenant avec les outils cross-compilation) de créer sous unix un exécutable pour Windows, ou sous Windows de créer un exécutable pour Linux. Mais c'est pareil entre différentes machines *n*x : un exécutable créé sous Linux ne marchera pas sous Solaris ou HPUX ...

[dotmessy]

bon je voie que sur ton poste pas eu la bonne reponse, je vais t'expliquer

cela viens du fait des adressages memoire de base de l'acces au disque entre autre.
sous linux le dump de lecture du disque dur se fait pas a la meme adresse que le dump du systeme windows

( j'ai plus les adresse en tete mais je peux te les retrouvé si tu veux )
en plus sous linux, tu utilise un autre systeme de codage de donné physique sur le disque ( ext et NTFS sont totalement different )

en plus les gestions des instruction sont propre au systeme de par sa conception.

exemple linux :
une gestion de memoire est faite par parcelle --> un block --> une page
windows n'a pas la capacité de géré ton tas de memoire de la sorte d'ou les les problèmes lors de malloc ( unix et windows , si tu code en C tu connais ce pb )

certe les Instructions machines assembleur sont theorique les meme hors si tu code en Assembleur sous linux et windows su y vera 2 norme de codage différent .
les compilateur linux utilise la NORME AT tandisque que windows utilise une autre norme ( je sais plus sont nom )

tu va me dire en ASM un :
mov AX,2 est similiaire a un MOV 2,%AX sous linux
oui l'adressages est le meme ton registre du CPU est le meme
mais le codage diffère
d'ou l'interpretation du code par le compilateur different de linux a windows

voila j'espere t'avoir eclaircie un peu le probleme