Créer un fichier ELF sans même GNU/ld [Infos]

[Hibou57]

GCC est un compilateur imposant. Avoir un compilateur légé est chose aisée : on peut penser à nasm. Seulement, la création des fichier ELF passe toujours par LD. Le problème de LD c'est qu'il fait partie de l'environnement de développement standard qui lui-même dépend de libc6/glibc2... et libc6/glibc2 est une librairie trop lourde pour être utilisable sur les petits systèmes.

Mais il existe une solution qui vous permettra de créer des fichiers ELF sans même passer par un lieur. L'avantage de cette solution et qu'elle vous permet de créer des véritable fichiers ELF sous un environnement restreint, et vous permettra même, le fin-du-fin, de faire de la cross-compilation, c'est à dire de créer sous Windows des binaires ELF destinés à fonctionner sous Linux.

Ceci, je l'espère, rendra service à tous/toutes ceux/celles qui travail sur des adaptation de Linux (petit PCs, système embarqué à peu de frais, etc).

Vous pourrez conculter un exposé détaillé de la question ici : Création de fichier ELF pour Linux, sans utiliser de lieur.

La solution passe par l'utilisation de deux pattern au choix. Vous utiliserez le premier pour les applications nécessitant un segement de code ainsi qu'un segment de données en lecture/écriture. Le second pattern sera à utiliser pour les applications ne nécessitant qu'un segement de code (notez que les donnée en lecture seule pourront être placées dans le segment de code).

Sans plus tarder, allons droit au but, voici les deux patterns éditable :

elf-with-data.asm

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
 
; (hint:tabulation size is 3)
; (date-dd-mm-yyyy:03/01/2007)
 
; Creating a fully functional ELF file without even GNU/ld
; ---------------------------------------------------------
; 
; This a pattern file which allow you to create ELF executable without
; even a linker in hands. This is useful for custom installation with
; low resource, such as old PC. Indeed, the usual way is to use GNU/ld,
; but unfortunatly, ld rely on glibc, which is very-very hugh en
; outrageously resource consuming.
;
; You can use it with nasm (the syntax used here is the one of nasm).
; A static version of nasm if very light (between 150 and 200KB). So
; with a static version of e3 (which is no more than 13KB), and
; a few text files documentations about syscalls and some other good
; stuff, you can have a real developpement environement under less
; than the quarter of an 1.44M floppy disk.
;
; Please visit http://www.les-ziboux.rasama.org/elf-without-ld.html
; for updates. In the futur, I will mirror a very small static version
; of nasm (102KB), a static version of e3, and some useful texte
; documentation.
;
; You can use this pattern in any project... it is not mandatory, but this
; would be very nice of you to put this url on top of your product sources :
; http://www.les-ziboux.rasama.org/elf-without-ld.html
; Thank you :)
;
; To use this pattern, just edit the place between the BEGIN and END mark,
; both in code and data segment.
;
; If you code only adress read-only data, then you can use the other
; "elf-simple.asm", beceause is there are only read-only datas, it is
; best to put them in code segment.
;
; Finaly you have to compile your code with "nasm -f bin [-O2] yourcode.asm"
; (the -O parameter is optional, alghtough often requited because of
; short-jumps and some stuff like that).
 
; This file is full of comments... you may remove them after reading ;)
;
; Comments are welcome : les-ziboux@rasama.org (fr/en)
; You wanna learn Arabic ? -> http://www.les-ziboux.rasama.org (fr)
 
cpu 386
bits 32
 
org 0x08048000 ; Linux applications are loaded at this virtual address.
 
; === Header ================================================================
 
elf_header:
.start
   db 0x7F, "ELF"          ; ELF signature                 -- constant
   db 1                    ; Architecture(1)               -- 1 = 32 bits
   db 1                    ; Data enconding                -- 1 = LSB-First
   db 1                    ; File version                  -- 1 = v1
   db 0,0,0,0,0,0,0,0,0    ; 9 bytes padding               -- should be zero
   dw 2                    ; Type                          -- 2 = executable
   dw 3                    ; Architecture(2)               -- 3 = i386
   dd 1                    ; ELF Version                   -- 1 = ELF-v1
   dd _start               ; Entry point adress in memory  -- virtual adress
   dd segments_table - $$  ; Segments table offset in file
   dd 0                    ; Sections table offset in file -- 0 = none)
   dd 0                    ; File's flags
   dw elf_header.size      ; ELF Header's size
   dw 32                   ; Segments table entries's size
   dw 2                    ; Number of segment descriptors
   dw 0                    ; Sections table entries's size -- 0 = none
   dw 0                    ; Number of sections descriptor -- 0 = none
   dw 0                    ; String table index            -- 0 = none
.size equ $ - .start
 
segments_table:
 
code_segment_descriptor:
.start:
   dd 1                    ; Type            -- 1 = loadable into memory
   dd 0                    ; Offset in file  -- include ELF header and table
   dd $$                   ; Virtual address in memory
   dd 0                    ; Physical adress -- 0 = no physical address
   dd code_size            ; Size in file
   dd code_size            ; Size in memory
   dd 5                    ; Permission flags -- 0x4 + 0x1 = read and execute
   dd 0x4                  ; Alignment in memory (and in file)
.size equ $ - .start
 
data_segment_descriptor:
.start:
   dd 1                    ; Type -- 1 = loadable into memory
   dd _data - $$           ; Offset in file
   dd _data                ; Virtual adress in memory
   dd 0                    ; Physical adress -- 0 = no physical address
   dd data_size            ; Size in file
   dd data_size            ; Size in memory
   dd 6                    ; Permission flags -- 0x4 + 0x2 = read and write
   dd 0x4                  ; Alignment in memory (and in file)
.size equ $ - .start
 
; === Code ==================================================================
 
_code :
 
_start: ; You can move the start label where-ever you want in code segment.
 
   ; ----- BEGIN of your code -----
 
   ; Here is a sample code which simply say good bye and terminate.
   ; It give an example of usage of both code segment and data
   ; segment. Although this example does write to data segment,
   ; the data segment is still fully writable. Note that read-only
   ; datas can also reside in code segment (you should use
   ; the pattern "elf-simple.asm" for this purpose).
   ; You can put your own code between the BEGIN and END mark.
   ; Do not modify something else, unless you're sure about what
   ; you are playing with.
 
   mov  eax, 4                ; function id for sys_write
   mov  ebx, 1                ; descriptor of standard output
   mov  ecx, message          ; offset of bytes to write
   mov  edx, message.length   ; number of bytes to write
   int  0x80                  ; syscall
 
   mov  eax, 1                ; function id for sys_exit
   mov  ebx, 0                ; return code from the program (0 mean Ok)
   int  0x80                  ; syscall
 
   ; ----- END of your code -----
 
align 4
code_size equ $ - $$
 
; === Data ==================================================================
 
align 4
_data:
 
   ; ----- BEGIN of your datas -----
 
   ; This is a simple data example. This data segment is writable.
   ; Note that you can put read-only data in the code segment. If you
   ; only have read-only data, and no writable data in you application,
   ; then putting them in code segmet, avoid the creation of a data
   ; segment, reducing a bit the size of the executable. For this
   ; purpose, use the other patten name "elf-simple.asm".
   ; You can put your own datas between the BEGIN and END mark.
   ; Do not modify something else, unless you're sure about what
   ; you are playing with.
 
message:
   db "Bye, Au-revoir, Ma'a as-salama, Bisbald ... :)", 10
.length equ $ - message
 
   ; ----- END of your datas -----
 
align 4
data_size equ $ - _data

La deuxième version du pattern, pour les applications qui ne nécessite rien de plus qu'un simple segment de code.

elf-simple.asm

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 
; (hint:tabulation size is 3)
; (date-dd-mm-yyyy:03/01/2007)
 
; Creating a fully functional ELF file without even GNU/ld
; ---------------------------------------------------------
;
; There are no explanations here : read "elf-with-data.asm" for
; informations on usage and copyright.
;
; Compile: nasm -f bin [-O2] yourcode.asm
; Updates : http://www.les-ziboux.rasama.org/elf-without-ld.html
; Comments are welcome : les-ziboux@rasama.org (fr/en)
; You wanna learn Arabic ? -> http://www.les-ziboux.rasama.org (fr)
 
cpu 386
bits 32
 
org 0x08048000 ; Linux applications are loaded at this virtual address.
 
; === Header ================================================================
 
elf_header:
.start
   db 0x7F, "ELF"          ; ELF signature                 -- constant
   db 1                    ; Architecture(1)               -- 1 = 32 bits
   db 1                    ; Data enconding                -- 1 = LSB-First
   db 1                    ; File version                  -- 1 = v1
   db 0,0,0,0,0,0,0,0,0    ; 9 bytes padding               -- should be zero
   dw 2                    ; Type                          -- 2 = executable
   dw 3                    ; Architecture(2)               -- 3 = i386
   dd 1                    ; ELF Version                   -- 1 = ELF-v1
   dd _start               ; Entry point adress in memory  -- virtual adress
   dd segments_table - $$  ; Segments table offset in file
   dd 0                    ; Sections table offset in file -- 0 = none)
   dd 0                    ; File's flags
   dw elf_header.size      ; ELF Header's size
   dw 32                   ; Segments table entries's size
   dw 1                    ; Number of segment descriptors -- just one (code)
   dw 0                    ; Sections table entries's size -- 0 = none
   dw 0                    ; Number of sections descriptor -- 0 = none
   dw 0                    ; String table index            -- 0 = none
.size equ $ - .start
 
segments_table:
 
code_segment_descriptor:
.start:
   dd 1                    ; Type            -- 1 = loadable into memory
   dd 0                    ; Offset in file  -- include ELF header and table
   dd $$                   ; Virtual address in memory
   dd 0                    ; Physical adress -- 0 = no physical address
   dd code_size            ; Size in file
   dd code_size            ; Size in memory
   dd 5                    ; Permission flags -- 0x4 + 0x1 = read and execute
   dd 0x4                  ; Alignment in memory (and in file)
.size equ $ - .start
 
; === Code ==================================================================
 
_code :
 
_start: ; You can move the start label where-ever you want in code segment.
 
   ; ----- BEGIN of your code -----
 
   ; Here is a sample code which simply cleanly terminate :P
 
   mov  eax, 1                ; function id for sys_exit
   mov  ebx, 0                ; return code from the program (0 mean Ok)
   int  0x80                  ; syscall
 
   ; ----- END of your code -----
 
   ; You may have read-only data here as well ;)
 
align 4
code_size equ $ - $$

[Hibou57]

P.S. A l'occasion de mes expérimentations, j'ai découvert un bug dans la dernière version de nasm : dans certains cas nasm duplique le code binaire. Les détails de ce bug a été soumis sur sourceforge.net.

Ce bug n'empêche pas le fonctionnement du programme, mais duplique inutilement le binaire produit, la partie dupliquée étant concaténé à la partie légitimement présente.

P.P.S J'ai remarqué même un bug du forum en voulant ajouté ce précédent PS au précédent message : j'ai eu un message me disant que mon message était trop court et que je devais ajouter au moins caractère. Et en retirant le PS du message, rendant le message plus court... ça passait

Y at-il quelqu'un a qui je peux envoyer un screen-short démontrant ce bug du forum ?

[Pouic]

Par contre, ton url du premier post ne fonctionne pas (tu as dû te planter dans les balises )

[Celelibi]

En fait la technique c'est juste de recréer les en-têtes et tout ce qui fait parti du format ELF directement dans le fichier asm.
Je trouve ça très astucieux.
Donc en extrapolant un peu, on peut créer des elf avec une structure aussi complexe qu'on veut (on pourra difficilement faire plus simple qu'un segment de code tout seul) pour peu qu'on ait de la doc sur le format elf.

Je vais garder ces exemples dans un coin en attendant de pouvoir les étudier de plus près.


Pour l'url qui marche pas : le lien est bien dans la balise url, mais l'url est absente de la balise.

[Hibou57]

Envoyé par Celelibi

En fait la technique c'est juste de recréer les en-têtes et tout ce qui fait parti du format ELF directement dans le fichier asm.

Sur la page pour laquelle je donne le liens (que je vais corriger, et d'ailleur je vais mettre à jour la page), il y a un lien vers la référence ELF. J'ai choisi la plus à jour, la version 1.2, il faut y faire attention, parce que même sur les sites dédiés à Linux, on trouve presque toujours des lien vers la version 1.1 (comparer les deux fichiers, et vous verrer que la 1.2 est plus exaustive).

Envoyé par Celelibi

Donc en extrapolant un peu, on peut créer des elf avec une structure aussi complexe qu'on veut (on pourra difficilement faire plus simple qu'un segment de code tout seul) pour peu qu'on ait de la doc sur le format elf.

En fait, je pratique toujours de cette manière : vouloir une chose simple, qui répond au besoins minimum, et on a alors quelque chose de simple et de léger. Je faisais ça sous Windows aussi, quand je n'avais pas les outils nécéssaire (je n'avais pas le net)... j'avais créer un assembleur qui produisait des fichier exe de manière simple.

Je trouve que c'est une bonne chose : vouloir une chose simple, l'implémenté simplement, et seulement ensuite ajouter des fonctionalité si nécéssaire quand le besoin s'en fait strictement ressentire. Dans le domaine du logiciel, je ne crois pas en l'universalité (donc pour moi un logiciel ne doit pas avoir comme objectif de répondre à tous les besoin imaginables... et dans ces derniers cas, il doit être personalisé au cas pas cas, par un contrat d'assistance spécifique par exemple), ni en la portabilité (comme je dis toujours, Linux c'est Linux et Windows c'est Windows, et ainsi on profite du système au maximum sans gaspillage et sans dommage), mais seulement en la méthode et en la documentation (la seule chose portable à mes yeux, ce sont les concept, les idées, et les shema algorithmique).

.... mais pourquoi je raconte tout ça encore

Je vais garder ces exemples dans un coin en attendant de pouvoir les étudier de plus près.

Pour l'url qui marche pas : le lien est bien dans la balise url, mais l'url est absente de la balise.

Alors, attent Celelibi... ne te précipite pas trop vite quand même, je ne voudrais pas t'induite en erreur, parce que le format ELF n'est pas tout, et il faut tenir compte aussi des spécificité de Linux. Le format ELF a une part qui défini des choses univellese, qui sont vraies sous tous les systèmes, mais chaque système restent libre d'ajouter des restriction supplémentaire, ou de définir une sémantique particulère pour certaines sections (par exemple sous Linux, la section .note embarque des informations sur la version de GCC employée pour compiler le binaire).

Alors justement là, il y a un point sur lequel je n'arrive pas à trouver de répons claire : est-ce que oui ou non les segment de code et de donnée sous Linux doivent être obligatoirement aligné sur 4096 bytes. Parce dans le pattern en assembleur que je donne, il sont alignés sur 4 bytes (32 bits). Ca fonctionne sous mes kernel de testes... mais j'ai copier mes petits programme de teste sur un serveur débian, et là j'ai segfault. J'ai recompiler en changeant l'alignement pour 4096, et là ça marche.

Dans les code source de Linux, il existe une macro qui défini un flag qui s'appel PF_ALIGNWARN et qui s'applique au i486 seulement... je n'y comprends rien. Parce que apparement, ça ne semble pas être interdit...

Bref, d'autres considérations me passe par l'esprit, mais je n'ai pas le temps d'en parler tout de suite.

Note pour Celelibi : si tu t'interesse toujours au package Ada pour la console, en fait c'est en voulant créer des programme minimiliste utilisant la console, et ne dépendant pas de la glibc, que j'en suis arrivé à m'interesser à l'assembleur sous Linux (je ne le pratiquais qu'avant sous DOS). Et donc ce que je vais apprendre sur la console Linux par ce moyen, me raménera à ce fameux package que je n'abandonne pas contrairement au apparences (mais je suis occupé à d'autres choses que le developpement... alors je ne peux pas y passer tout mon temps)

Envoyé par Pouic

Par contre, ton url du premier post ne fonctionne pas (tu as dû te planter dans les balises )

Pour le lien, je corrige tout de suite... au passage Pouic, j'adore ta signature

[Lunixinclar]

Beau boulot.

Les travaux de Brian Raiter (ELFkickers) devraient t' intéresser: il compresse le header pour réduire la taille du code (hello world en 59 octets). Le prog est moins portable (selon le noyau) mais c'est la démarche qui est intéressante.
Avec ta méthode j'obtiens un "hello world" de 134 octets, par l' appel système 4. Pas mal!
Par contre il faut un chmod+x.

[granquet]

genial, ça risque de me servir.

[Hibou57]

Envoyé par Lunixinclar

Beau boulot.
Les travaux de Brian Raiter (ELFkickers) devraient t' intéresser: il compresse le header pour réduire la taille du code (hello world en 59 octets).

J'ai entendu parlé de ELFKickers... un package comprennant notament un utilitaire appelé sstrip, et qui permet de retirer encore plus d'informations inutiles que strip. Mais on peut apparement y parvenir avec des options --remove-section=xxxx passées à strip (sauf erreur).

Envoyé par Lunixinclar

Le prog est moins portable (selon le noyau) mais c'est la démarche qui est intéressante.

Alors, à ce sujet, je me suis renseigné. Il semble que l'API du noyau soit plutôt stable. Il faut distinguer l'interface binaire interne et l'interface binaire externe. J'ai lu quelque chose (je ne sais plus où), qui disait que le developpement du noyau ne privilégie par la compatibilité ascendante de l'interface binaire interne (mais on s'en moque... ça ne nous concerne pas), mais maintient autant que possible la compatibilité de l'interface binaire externe (i.e. les syscalls).

Quand on dit que ce n'est pas portable, il faut noter que la portabilité des applications basée sur la libc (the very bloated libc) est obtenu en créant une libc par platte forme (même s'il n'y a qu'un seul tronc de developpement). Et il serait tout à fait possible de créer une libsyscalls qui aurait autant d'implémentation qu'il y a de plateforme, et de créer des applications portable basées sur celle-ci.

Mais ce serait déjà un début de bloat, parce qu'il faudrait aller unifier les structure de donnée au travers des plate forme par exemple. Et le bloat commence là ou on commence à mettre des intermédiaires et des wrappers là ou la logic de l'application ne le nécéssite pas strictement (c'est une manière pour le/la dévelopeur(se), de se décharger sur l'utilisateur final, phénomène extrément accentué par le free-ware, car il invite à une restriction drastique des coup de developpement, tant en temps qu'en argent).

Mais il reste encore la solution de coder une librairie syscalls pour chaque plateforme, sans que cette librairie ne soit portable. Cela ne rendrait pas les applications basées sur cette librairie portable (bien sure), mais cela en faciliterait déjà le codage (it seem obvious :p ).

En règle général il faut en finir avec le mythe de la portabilité, car de nos jours, on fait du « portable » sans même plus savoir pourquoi, mais seulement parce que c'est mis en avant comme un label ou parce que c'est à la mode.

Mais qu'est-ce que la portabilité ? C'est un moyen de réduire les coups de développement pour un logiciel. Mais cette économie du coup de developpement se fait au détriment de la légéreté de l'application, et également de sa stabilité et de son efficacité.

Quand on y regarde bien, cette stratégie est IRRESPONSABLE, car elle fait payer très chèr une petite économie. Car en effet, l'économie en un seul point de développé aboutit à un gaspillage sur des milliers, voir des millions de points d'utilisation. En clair, et avec un exemple imagé, un(e) developeur(se), peut vouloir économiser 3 ou 4 jours de developpement à plein temps, au prix d'une consomation de mémoire de 5 ou 10M de ram supplémentaire sur des milliers de post d'utilisation.

Est-ce que vous comprennez la logique ?

Donc exit la portabilité, et oui à l'exploitation au maximum de toute les caractéristique spécifique d'une plateforme d'exploitation.

Et encore, j'oubli de dire qu'en plus du gaspillage, la portabilité empêche d'utiliser les petits plus locaux que l'on peut trouver sur telle ou telle plateforme. Donc il y a même un gachis dans les fonctionnalité. Et quand on veut tout les plus qui existe partout, on se retrouve avec des mamouth à la glibc.

Franchement entre nous, la portabilité n'est-elle pas illogique ? Parce que soit on veut que tous soit partout pareil, et alors dans ce cas la solution la plus intelligente serait quand même plutôt alors le même matériel et le même OS partout. Et si on répond qu'on ne peut pas avoir le même matériel et le même OS partout, parce que le notion de « cette solution est meilleur que celle-ci » est dépendante d'un grand nombre de facteur, alors on démontre que les système ne peuvent pas tous se ressembler, et, et .... et on démontre par la même que la portabilité n'a aucun sens.


Comme je dis toujours, c'est la portabilité de l'information qu'il faut privilégié, la portabilité des concepts, et la portabilité des algorithme, ce qui peut se faire naturellement, parce que ce sont des choses abstraite... reste à l'implémenté/adapté chaque à la sauce local, pour plus d'économie, plus d'éfficacité, une meilleure d'intégration à l'environnement, et plus de cohérence vis-à-vis du système et de l'environnement (ce qui mettrait fin à beaucoup de frustration).

Bon, merci à tous, merci pour vos commentaires, parce que vous m'avez donner l'inspiration et je viens d'écrire un brouillon d'article pour mon site.

Avec ta méthode j'obtiens un "hello world" de 134 octets, par l' appel système 4. Pas mal!

Alors en parlant de taille justement, fait attention à un bug de nasm que j'ai découvert à l'occasion de mes test (je vous donnerai le lien sur la déclaration du bug, je ne l'ai pas sous la main).

Et au fait Lunixinclar, est-ce que ce hello-world s'execute normalement sous ton Linux ? Parce que j'ai remarqué que l'alignement sur 4 octets ne fontionne pas partout... mais l'alignement sur 4096 bytes me semble être problématique, parce que d'après le doc ELF, l'alignement en mémoire doit aussi être l'alignement dans le fichier, et avec un alignement à 4096 bytes, il y a des padding énormes, et c'est un vrai gachis

Par contre il faut un chmod+x.

beh voui :p

Envoyé par Dark_Ebola

genial, ça risque de me servir.

Je suis curieux de savoir pourquoi ... dis s'ti pli... ti veux bin m'dir pourquoi ? T'es sur un super projet ?

[granquet]

ça vas peut être (si un jour je démarre le projet) me permettre de faire des mise a jour de mon logiciel assez simplement.
je ne peux pas me permettre d'envoyer des .c (ou .cpp, ou autre) sur les serveurs (pour des raisons diverses ) et je n'ai pas forcement accès a un environnement de compilation non plus ...
donc la solution c'est d'envoyer des binaires ... sauf que je bosse sur des machines avec des archs différentes (du sparc au x86_64 en passant par le PIC18 ...) alors cross compil obligatoire avec un PC sur lequel j'ai 50 versions de la libc (une par arch et sous-arch).
c'est un peu lourd ...
alors je me dis que je peux ptetre faire une mini libc (avec juste ce dont j'ai besoin) et un ld "ultra simplifié" par arch/sous-arch.

m'enfin, tout ça reste de l'ordre du projet a faire dans longtemps, le jour ou j'aurais le temps.

--
je precise : tout cela dans un environnement "non professionnel", je vois mal ce genre de bidouilles abomiffreuses dans l'industrie.

[Celelibi]

[...]alors on démontre que les système ne peuvent pas tous se ressembler, et, et .... et on démontre par la même que la portabilité n'a aucun sens.

Moi je dis que, oui, les systèmes se ressemblent, avec des points communs, mais aussi des différences.

Comme je dis toujours, c'est la portabilité de l'information qu'il faut privilégié, la portabilité des concepts, et la portabilité des algorithme, ce qui peut se faire naturellement, parce que ce sont des choses abstraite... reste à l'implémenté/adapté chaque à la sauce local, [...]

Si on suis ton idée, on pourrait avoir un "fichier algorithme" qui décrit un algorithme dans un langage standardisé et sur chaque machine, un programme capable d'implémenter l'algo en langage machine en tirant parti au maximum des spécificité de la machine locale.


N'est-ce pas en quelques sortes ce que l'on fait avec un code source portable et un compilateur ?
Un code source portable est un code qui suit une norme/un standard qui à été défini indépendamment de toute architecture logiciel/matériel. Par exemple, un code source en Ada.
Ensuite il suffit d'avoir un compilateur pour chaque architecture materiel et qui optimise pour l'architecture logiciel.

Bien entendu tu pourrais me dire que ton package qui fait du contrôle de terminal est en Ada, mais ne produit pas le même effet sous win et nux. Ce à quoi je répondrais que ton code est dépendant de l'architecture logiciel (en l'occurrence du terminal utilisé).


Mais je suis d'accord que même si il existe des langages normalisés, les compilateur n'optimisent pas toujours comme il le faudrait. Mais que diable, nous ne sommes plus aux temps des cartes perforées.



Quant-aux lib monstres comme la glibc.
Le couple fichier exécutable/glibc est similaire au couple code source/compilateur.
Ici le fichier exécutable est censé être écrit dans un langage portable, et tout ce qui peut être optimisé par l'architecture locale est délaissé à la lib.
Mais bien entendu comme c'est le fichier exécutable qui devra être exécuté (lapalissade ) c'est au moment de sa création qu'il faudra choisir quel traitement on délaisse à la libc. On ne pourra donc pas avoir autant d'optimisations qu'avec le couple code source/compilateur. Mais pour la plus part des utilisateurs/machines c'est bien suffisant.

Bon, merci à tous, merci pour vos commentaires, parce que vous m'avez donner l'inspiration et je viens d'écrire un brouillon d'article pour mon site.

Dans ton papier, n'oublies pas de mettre dans l'introduction que tu ne parle que de la portabilité binaire.