Discussion :

[- Robby -]

Bonjour à tous,
Cette question peut se poser quelque soit le language ... C/C++, Pascal, même MASM. Voici :
Quand je fais appel à une fonction api, kernel ou win32, peu importe... que ce soit par un " FonctionApi (paramètres) " ou par un " push paramètres, Call FonctionApi " ... Comment notre compilateur, C, Pascal, ou Asm, connait-il l'adresse réelle de "FonctionApi" ?
Il doit bien exister quelque part, une structure, un tableau, une liste ... ou d'un côté je vais pouvoir trouver la chaine de caractères " F o n c t i o n A p i " , et de l'autre une adresse physique, non ? Sinon, comment notre compilateur, C ou asm, encore une fois, peu importe ... pourrait-il générer un code exécutable en final.
Comment se passe exactement cette translation symbolique -> physique ?

[reptils]

quand tu fais appel à une focntion de win32 par exemple, ben les dll (user32...) sont référencé dans les variables d'environement et le compilateur y fait appel via le Makefile de la compilation. dans le Makefile tu spécifi des lib dont tu as besoin, ensuite si le chemin est stocké dans les variables d'environement ben il va les trouver sinon dans le Makefile tu devras mettre le chemin de la lib.

[- Robby -]

Oui reptils, je sais que l'on fait référence aux " dll ". Bon ... prenons l'exemple de la fonction "IoCreateDevice", ok ? C'est une fonction de l'api native. Cette fonction se trouve à l'origine dans kernel32.dll (je pense).
Bon ... kernel32.dll, c'est du code, un assemblage de fonctions. Cette "dll" est chargée lors du boot, et devient partie intrinsèque du noyeau. Quand on écrit ... peu importe les subtilités du langages ... "include Kernell32.dll" ... que signifie exactement cette ligne ?
Include ... include ... le code de kernel32.dll, il est déjà depuis bien longtemps en memoire, il "tourne", et fait partie du noyeau ... alors ? On "include" quoi en fait ? ... du code ? une table de références ? ... quoi ? ... y'a pas 36 trucs qui se nomment "kernel32.dll" dans mon pc ... c'est soit du code, soit des références.
Alors ? que veut dire exactement "include kernel32.dll", qu'est-ce que cela implique, et comment cela fonctionne-t-il ? Je reviens à ma première angoisse (hi) ... ou se trouve la table, avec d'un côté ma chaine de caractères "I o C r e a t e D e v i ce ", et de l'autre une adresse ? Car c'est bien de cela dont il s'agit ...
Merci de m'avoir répondu Reptils.

[Jean-Marc.Bourguet]

Quand tu generes un fichier objet, celui-ci contient une table des symboles donnant pour les symboles qui sont definis pas le fichier la position du symbole, et pour les symboles utilises mais non definit ce qu'il faut en faire (mettre leur adresse a telle position, ou bien mettre la difference entre deux adresses a telle position, ...)

Un editeur de liens va prendre plusieurs fichiers objets et resoudre les symboles non definis, cad modifier le contenu des fichiers objets en fonction des choses a faire indiquees dans le fichier.

Dans le cas des bibliotheque partagees (du moins celles qui ne sont pas chargees explicitement), le travail de l'editeur de liens se fait au demarrage pour les symboles qui se trouvent dans les bibliotheques partagees. Parfois meme, il peut se faire la premiere fois qu'il faut trouver l'adresse du symbole.

La reponse a ta question est donc: dans les fichiers objets, dans les bibliotheques et dans des tables en memoire.

[- Robby -]

Peut être suis-je en train de poser une question de tordu, ou je n'arrive pas à expliquer mon questionnement. Quoi qu'il en soit, merci de m'avoir répondu Jean Marc. Le fichier objet, il est créé ... donc, au départ de la compilation, il n'existe pas. Donc, cela ne peut pas être lui qui "donne" l'adresse ... il ne peut que la recevoir. Les bibliothèques ... les ".lib" donc ! Es-ce dans un ".lib" que je pourrais retrouver ma chaine de caractères "IoCreateDevice" ... elle doit bien se trouve quelque part cette chaine, avec à côté, une adresse, un numéro, un déplacement, une référence au code se trouvant déjà en mémoire. je me répète peut être, désolé. Et ce "include" ... include kernell32.dll par exemple ... le compilateur va-t-il réellement chercher le fichier kernel32.dll ... dans windows\system32 ? que fait-il de cette "copie" ? le code de kernel32.dll est déjà en mémoire depuis le boot, non ? Comment notre compilateur possède-t-il une référence précise (peu importe le type de référence) de notre fonction api ... se trouvant dans le noyeau ... alors que notre bon compilo a été lancé "après" le kernel ? Le kernel change suivant le systeme d'exploitation ... Windows 2000, xp, pack 1 ou 2, server 2003 ... le code du kernel n'est pas le même et pas au même endroit. Pourtant mon visual c/c++ tourne et compile sur chaque kernel .. il "sait" ou se trouve IoCreateDevice ... étonnant ! A mon avis, le "secret" se trouve dans les ".lib" ... car dans les ".h" et les ".obj" ... je ne vois pas. Les premiers ne contiennent que des déclarations et les seconds sont créés ... donc, ne peuvent pas fournir la solution, puisque n'existant pas avant la compilation. Désolé si je saoule tout l'monde avec ma recherche du Graal, hi !

reprise du post ...

PS: Je retrouve la chaine de caractère "I o C r e a t e D e v i c e" dans NtOsKrnl.LIB ... cette fonction est déclarée dans Ntddk.H aussi, comme une "NTKERNELAPI". Cette déclaration dans Ntddk.H donne au compilo la "forme" de la "chose" ... le compilo doit "connaître" le terme "NTKERNELAPI", et peut se référer alors à la "base de donnée" pour les api natives, soit NtOskrnl.LIB. Dans NtOsKrnl.LIB, je retrouve les chaines de caractères de toutes les fct de l'api native. Si mon raisonnement est bon (si) ... la suite m'échappe ! Qui a-t-il dans NtOsKrnl.Lib à côté de chaque chaines de caractères, une référence, un déplacement, ou un simple N° ... un simple numéro suffirait via l'instruction "SysEnter" et la table des services. Y a-t-il qq qui connait le fin du fin de cette histoire ?

maintenant, j'arrête, promis !

[Jean-Marc.Bourguet]

Désolé d'avoir tardé... ce système ne permet pas -- à ma
connaissance, je serais enchanté qu'on me montre que je me
trompe -- de marquer des messages sur lesquels on désire
repasser plus tard.

Reprenons. J'ai un peu simplifié mais c'est déjà long...

Quand on génére un fichier objet, celui-ci contient le code
et une description des symboles. Ceux-ci sont de deux
types: les symboles utilisés mais non définis dans le
fichier objet et les symboles définit dans le fichier objet
pour lesquels le fichier contient la position de l'objet
désigné par le symbole par rapport au début du fichier; dans
tous les cas, il y a aussi les positions où on utilise
l'objet en question pour qu'on puisse modifier le code une
fois que sera connue sa position à l'exécution.

Une bibliothèque statique (.a pour Unix, .lib si je ne me
trompe pas sous Windows), c'est simplement un regroupement
de fichiers objet.

Une bibliothèque dynamique (.so, .dl pour Unix, .dll) est un
fichier particulier contenant du code (généralement compilé
de sorte qu'il puisse être facilement chargé à des endroits
différents en mémoire, donc avec peu de besoin de
modifications de code, une technique est d'utiliser le plus
possible les modes d'adressage relatif au PC et des tables
d'indirection, il suffit alors de mettre à jour les tables),
la position par rapport au début de la bibliothèque objets
désignes par les symboles exportés.

Un exécutable contient le code mais aussi une description
des symboles qui sont utilisés et qui proviennent de
bibliothèques dynamiques.

Que fait l'éditeur de liens? Quand il construit un
programme n'utilisant pas de bibliothèques dynamiques, il
décide pour chaque fichier objet faisant partie du programme
de sa position. Il connait alors la position à l'éxécution
de chaque objet désigné par un symbole. Il peut donc
modifier le code en utilisant les informations contenues
dans le fichier objet.

Si le programme utilise des bibliothèques dynamtiques, il
considère qu'il ne connait pas la position finale des
symboles exportés par ces bibliothèques. Donc il ajoute à
l'exécutable une table indiquant les bibliothèques
dynamiques utilisées, les symboles qu'il faut y chercher et
les endroits où ils sont utilisés.

A l'exécution, le programme commencera par aller charger en
mémoire les bibliothèques dynamiques, recupèrera les
adresses des objets utilisés et mettra à jour les endroits
où on utilise leur adresse dans les bibliothèques et le
programme.

Note: je connais beaucoup mieux le fonctionnement sous Unix
que Windows. Je l'ai donc décrit. D'après ce que j'ai cru
comprendre, la différence sous Windows est qu'on utilise une
.lib associée à la .dll lors de l'édition de liens tandis
que Unix utilise la .so aussi.

[- Robby -]

Merci pour ces explications Monsieur Jean-Marc, cela m'aide. question de phrases et de mots parfois. Ceci dit, la fonction prise en exemple (IoCreateDevice) est une fct exportée par NtOskrnl.EXE et non une dll ... mais je ne pense pas que cela remet le principe de ton raisonnement en cause.

juste un morceau de phrase qui m'a un peu fait sursauté ... une dll contient du code "généralement" compilé ... bein, du code, c'est du code, une suite d'instructions machines. Y'a pas de code compilé ou pas compilé ... du langage est compilé ou pas. Une dll, c'est un fichier au format PE qui contient du code et des informations ... de relocation, de point d'entrée, d'indexation des fonctions y reprises ...
Mais ... j'ai peut être mal compris ton expression ... possible aussi !

[Jean-Marc.Bourguet]

Merci pour ces explications Monsieur Jean-Marc,

Jean-Marc ça suffira. Monsieur + Prénom ça fait un peut trop patron de bordel ou parain du milieu à mon goût :-)

cela m'aide. question de phrases et de mots parfois. Ceci dit, la fonction prise en exemple (IoCreateDevice) est une fct exportée par NtOskrnl.EXE et non une dll ... mais je ne pense pas que cela remet le principe de ton raisonnement en cause.

Je ne connais pas assez Windows pour répondre là dessus. Je doute que ça remette en cause le principe.

juste un morceau de phrase qui m'a un peu fait sursauté ... une dll contient du code "généralement" compilé

Il faut lire jusqu'au bout, j'avais écrit:

généralement compilé de sorte qu'il puisse être facilement chargé à des endroits différents en mémoire

et j'avais continué en essayant d'expliquer que dans ce mode (appelé PIC, Position Independant Code) on utilisait au maximum les possibilités d'adressage relatif, quite à être plus lent, pour éviter d'avoir des modifications d'adresses à faire (et aussi permettre le partage des pages en mémoire, d'où l'autre nom de bibliothèque partagée qui a donné .so, pour shared object).

[- Robby -]

Ok, tout ok Jean Marc. Merci pour le temps passé à me répondre