Pourquoi la compilation entre unix et windows est différente ?

[..::snake::..]

Bonjour .

une question un peut newbie , mais quand meme je vous demande .

Lorsqu'on code une source C par example et en la compile sous Unix .

Elle marche normale , mais si en la déplace vers Windows elle marche pas .

Malgré que les synthaxe de codage pour le language sont les memes .

[vincent magnin]

Il ne faut pas oublier que les librairies que tu utilises ne sont pas toutes ... "portables"

Donc, dans la stricte utilisation des librairies portables tu ne rencontrera aucun problème (stdio, stdlib... pour ne citer que ces basiques).

Saches qu'il y a également des fonctions dans ces librairies qui ne sont pas portables

Porter un logiciel ce n'est, en gros, pas copier coller la source et la compiler

[..::snake::..]

@vincent magnin

Merci de l'interet que vous portez vers mon poste ,
Mais est ce que vous pouvez mieu m'eclairez ?

[Shugo78]

La portabilitée est importante.
Les appels systèmes et les normes sont différentes.

[..::snake::..]

La portabilitée , c'est quoi ?

[Shugo78]

En informatique, la portabilité d'un programme est caractérisée par sa capacité à fonctionner plus ou moins facilement dans différents environnements d'exécution tels que Windows, Unix ou encore Mac

[..::snake::..]

Je comprend bien maintenat !

Et pour ma question ,
Pourquoi ce n'est pas le meme programme si en le compile sous windows ou sous linux ?


Est ce que c'est les bibliotheque et library qui sont différente depuis l'un a l'autre ?.

[Shugo78]

Peut être utilise t-il des librairies qui ne sont pas portables ?
Ou des appels systèmes, ou de la programmation systèmes spécifiques à Unix(threads, sockets, etc...) ?
Ou encore des normes de fichiers différentes(POSIX, API windows) ?

[..::snake::..]

Encore est ce que les biblio de Linux et windows leur contenu synthax est le meme ?

Merci , parce que je ne comprend pas trop bien avec tes explication Shugo78.

je sais que tu fait des effort pour m'expliquer , mais bon ....

[millie]

Le compilateur ne génère pas du tout le même code tout simplement.

Les fichiers exécutables ont des formats différents (format ELF sous Linux / format PE sous windows, bibliothèque partagée .so sous Linux, bibliothèque dynamique .dll sous Windows). Il y a des formats différents pour les autres systèmes (solaris...)

De plus, la plupart du temps, ces programmes font des appels systèmes qui peuvent être différents suivant le système.

Les architectures sont différentes, ça peut pas marcher :
Exemple code assembleur d'un hello world sur un SPARC :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
        .file   "test.c"
        .section        ".rodata"
        .align 8
.LLC0:
        .asciz  "Chaine"
        .section        ".text"
        .align 4
        .global main
        .type   main, #function
        .proc   04
main:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
        !#PROLOGUE# 1
        sethi   %hi(__iob+32), %g1
        or      %g1, %lo(__iob+32), %o0
        sethi   %hi(.LLC0), %g1
        or      %g1, %lo(.LLC0), %o1
        call    fprintf, 0
         nop
        mov     0, %g1
        mov     %g1, %i0
        ret
        restore
        .size   main, .-main
        .ident  "GCC: (GNU) 3.3.5"

Sous Linux :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
        .file   "test.c"
        .section        .rodata
.LC0:
        .string "Chaine"
        .text
.globl main
        .type   main, @function
main:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        andl    $-16, %esp
        movl    $0, %eax
        subl    %eax, %esp
        subl    $8, %esp
        pushl   $.LC0
        pushl   stderr
        call    fprintf
        addl    $16, %esp
        movl    $0, %eax
        leave
        ret
        .size   main, .-main
        .section        .note.GNU-stack,"",@progbits
        .ident  "GCC: (GNU) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)"

Ensuite, même sur un même processeur, l'édition des liens va être complétement différente

Sous Windows XP :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
	.file	"test.c"
	.def	___main;	.scl	2;	.type	32;	.endef
	.section .rdata,"dr"
LC0:
	.ascii "Chaine\0"
	.text
.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$24, %esp
	andl	$-16, %esp
	movl	$0, %eax
	addl	$15, %eax
	addl	$15, %eax
	shrl	$4, %eax
	sall	$4, %eax
	movl	%eax, -4(%ebp)
	movl	-4(%ebp), %eax
	call	__alloca
	call	___main
	movl	$LC0, 4(%esp)
	movl	__imp___iob, %eax
	addl	$64, %eax
	movl	%eax, (%esp)
	call	_fprintf
	movl	$0, %eax
	leave
	ret
	.def	_fprintf;	.scl	3;	.type	32;	.endef

[Shugo78]

La synthaxe des biblio(standards ou portables) est la même
Mais come l'a dit milie, les formats des fichier éxécutables ne sont pas les mêmes.

Et les programmes peuvent faire des appels systèmes propres à un système(comme fork() sous Unix et Create_Thread sous windows).

[jlliagre]

Envoyé par Shugo78

La synthaxe des biblio(standards ou portables) est la même

Non, on ne peux pas parler de syntaxe pour les bibliothèques puisqu'il s'agit d'un format binaire (ELF pour les bibliothèques et exécutables de tous les Unix actuels). Tu dois confondre avec la syntaxe des fichiers ".h" généralement associés à ces bibliothèques, qui bien sur doivent respecter la syntaxe du langage utilisé (C, C++ ou autre).

Mais come l'a dit milie, les formats des fichier éxécutables ne sont pas les mêmes.

Seuls les sources doivent respecter un format commun. Les exécutables, objets et bibliothèques sont spécifiques à une architecture (CPU) et doivent se conformer à une format supporté par les outils et l'O/S.

Et les programmes peuvent faire des appels systèmes propres à un système(comme fork() sous Unix et Create_Thread sous windows).

C'est vrai. La portabilité ne se limite pas à ça.

[Shugo78]

Envoyé par jiliagre

Non, on ne peux pas parler de syntaxe pour les bibliothèques puisqu'il s'agit d'un format binaire (ELF pour les bibliothèques et exécutables de tous les Unix actuels). Tu dois confondre avec la syntaxe des fichiers ".h" généralement associés à ces bibliothèques, qui bien sur doivent respecter la syntaxe du langage utilisé (C, C++ ou autre).

Non je me suis trompé, je parlais de .h à inclure dans le code(stdlib.h).

Envoyé par jiliagre

Seuls les sources doivent respecter un format commun. Les exécutables, objets et bibliothèques sont spécifiques à une architecture (CPU) et doivent se conformer à une format supporté par les outils et l'O/S.

On parle de sources qui peuvent s'adapter dans plusieurs OS.

[..::snake::..]

Merci a vous tout , mais j'ai rien chopé

C'est pas de votre faute non plus , mais c'est moi

une question :

le format de l'exécution sur windows c'est .exe et sous unix ?

[jlliagre]

Envoyé par __snake__

le format de l'exécution sur windows c'est .exe et sous unix ?

Ce n'est pas le format, c'est le suffixe.
Sous Unix, il n'y a pas besoin de suffixe.

[jlliagre]

Envoyé par Shugo78

Non je me suis trompé, je parlais de .h à inclure dans le code(stdlib.h).

Pourquoi "Non", j'avais bien compris que tu confondais [g]libc.so et stdlib.h.

On parle de sources qui peuvent s'adapter dans plusieurs OS.

Oui, des sources portables.

[InOCamlWeTrust]

Les langages de programmation ont tous leurs partie portable, c'est-à-dire indépendante du compilateur utilisé (et non seulement de l'OS), et leurs parties non portables.

Pour le C, tout programme écrit en strict C-ANSI (c'est une norme) devrait compiler et s'exécuter de la même façon partout (y compris sur ces petits micro-contrôleurs dépourvus la plupart du temps d'OS que sont les PIC et autres).

Par exemple, la norme C-ANSI fige une partie de la syntaxe et de la sémantique du C, spécifie un minimum de fonctions que l'on doit retrouver dans la librairie C.

Les normes ne se limitent pas à figer ou définir des langages : elles peuvent également spécifier des API (Application Programmer Interface), c'est-à-dire des fonctions de base. C'est le cas de POSIX, que l'on retrouve sur Unix et sur les Windows à partir de NT.

Le problème intervient lorsqu'un compilateur donné ne respecte pas la norme voulue (ici, le C-ANSI, mais il y en a aussi d'autres, et pour à peu près tous les langages) : ça pose des problèmes de portabilité, c'est-à-dire qu'il va falloir ré-écrire une partie du code pour qu'il s'exécute correctement sur la machine/OS/compilateur cible. Les problèmes de portabilité surgissent aussi parce que les OS/compilateurs ne fonctionnent pas de la même façon et ne présentent pas des API entièrement compatibles (comme Linux et BSD...).

En fait, 90% des problèmes de portabilité viennent des compilateurs qui n'offrent pas les mêmes fonctionnalités. Les programmeurs sont souvent tentés d'utiliser des services précis offerts par certains compilateurs et non par d'autres, ce qui, lors de la migration du code source, pose de sérieux problèmes de ré-écriture du code.

Cependant, si on s'en tient strictement aux normes, il n'y a jamais de problèmes, du moment que les compilateurs utilisés respectent ces normes (ce sont des choses bien documentées en général).

[Shugo78]

Envoyé par InoCamlWetrust

En fait, 90% des problèmes de portabilité viennent des compilateurs qui n'offrent pas les mêmes fonctionnalités. Les programmeurs sont souvent tentés d'utiliser des services précis offerts par certains compilateurs et non par d'autres, ce qui, lors de la migration du code source, pose de sérieux problèmes de ré-écriture du code.

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

[..::snake::..]

c'est quoi un suffix ?

une format C'est comme .exe
et le suffix quesque tu veux dire avec ?

[millie]

.exe n'est pas un format, c'est juste une extension (ou suffixe). Essaye de prendre un fichier texte, de le renommer .exe et tu verras

Un format exécutable sous Windows, c'est par exemple le format PE : http://fr.wikipedia.org/wiki/Portabl...le_File_Format