J´ai cherché, cherché et pourtant pas moyen de mettre la main sur un site qui donne les fonctions presente dans les dll les plus utiles.

Quelq´un aurais t´il ca dans sa besasse??

Merci

c´est une blague ou koi?
tu sais ce que c une DLL?

dll=> librairie dynamique

Comme une librairie statique a part que quand tu appelle une fonction l´application ne se cree pas un code propre mais utilise une copie commune a toute les applications.
Permet bien sur comme les librairies statique d´acceder a des ressources(ex: les cartes de jeu dans cards.dll)

ca suffi ou je continu??

arf, oui tu sais ce qu´est une dll.

C´est une question interressante. En générale les dll sont fourni avec une documentation sur leurs fonctions implémentées. Bien sur, si le developpeur ne veux pas les fournir ba la c´est galere.

De quelles DLL s´agit t il?

Bah oui c bien le probleme: ca veut dire koi les dll les plus utiles? rien

Euh... c´est pas clair tout ça..
Les dll les plus utiles? Ca veut rien dire.
Je sais pas si ça peut t´aider,mais pour tout programme Windows 32bits tu utilises les librairies kernell32 et user32, et tu peux connaître leurs fonctions à l´aide du SDK Win ( quelque part sur http://www.microsoft.com ) .

Erreur !
"Comme une librairie statique a part que quand tu appelle une fonction l´application ne se cree pas un code propre mais utilise une copie commune a toute les applications"

Nan, nan nan faut pas dire cela.

1 DLL est un fichier contenant un code eexecutable.
Lors du chargement de cette DLL il faut mapper le fichier en memoire. Bon, cela ce passe ou ? Ben dans l´espace memoire du process appelant, sinon elle n´est pas dans ton espace d´adressage et tu ne peux l´utiliser. Lorsqu´un autre programme ( process ) effectue le chargement de la DLL elle est mappé dans l´espace d´adressage du second process !

Donc il n´existe pas en memoire une copie Unique pour tout le systeme, mais une copie par process !

Par contre si un meme process fait appel 2 fois a la meme DLL ( 2 chargements ) alor elle n´est mappé ( pour la partie code) qu´une seule fois en memoire, et un compteur de reference est alors incrementé.

Passage

Je ne suis pas d´accord.
L´interet de la DLL est de partagé des ressources(peu importe la nature de ces ressources).
Donc quel est l´interet de partager des ressources si celles-ci sont mappées autant de fois qu´il y a de process appelant?
Quand une appli appel une DLL , l´API vérifie si il n´existe pas déjà une instance chargée , si ce n´est pas le cas elle charge la DLL puis renvoie le Handle associé , si c´est le cas elle se contente de récupérer le handle et de le transmettre à l´appli.
Enfin la DLL est déchargée quand il n´y a plus de process pour l´utilisée.
Sinon il n´y a aucun interet à créer des DLL , autant intégré le code directement dans l´application.

Sarafan, une petite question :
La DLL est mappé dans ton espace d´adressage ?

Oui la DLL est mappée dans le même espace d´adressage que le process appelant(c´est le role de LoadLibrary).
Mais les ressources de la DLL ne sont chargées qu´une seule fois en mémoire.
Le gestionnaire mémoire de windows s´occupe ensuite de faire les correspondance.

Que nomes tu "resource de la DLL" ?

S´il il s´agit du code executable ( par exemple):

Si la DLL est dans le meme espace d´adressage, ceci implique que sont code est mappé ( et parsé pour resourdre ses references externes - j´parle meme pas des jump qui faudrait aussi resoudre au passge ) .Donc le "code" de la DLL est copié plusieures fois. ( Ben oui la resolution de ses references externe n´a pas une adresse fixe et se fait en fonction de l´espace d´adressage du process en cours ) ....

Pour simplifier grossierement.
Lorsque tu fait jmp. L´adresse n´est pas connue et est dans ton binaire toujours relative a l´adresse en cours ( jump +5 octet) . Lorsque le code est ammené en memoire, on determine l´adresse de logement, et on ajoute cette adresse au saut relatif pour trouver l´adresse de saut finale et on modifie le code en consequence. Par exemple au mapping de ta DLL dans ton espace memoire.

Donc le code est plusieurs fois en memoire ( autant que de process appelant ) logique non ?

Ce que je nomme ressources de la DLL sont le code exécutable si il y en a un,les images,les curseurs,les icones,les menus ou les boites de dialogue.

Alors comment resouds tu les reference externe de la DLL et ses calcul de saut lors de sa monté en memoire si il n´existe qu´une seule image memoire de cette DLL ?

Pour le LoadLibrary je n´ai pas vérifié les valeur des handles , mais j´imagine(attention il ne s´agit que d´une supposition) que si le handle est le même pour le deux process il y a de grande chance pour qu´ils utilises la même image mémoire.

Pour les ressources externes autre que du code , delphi intègre dans c´est objets des méthode permettant de les récupérer directement sous forme de copie.
Mais si je n´avait pas Delphi et que je doive récupérer des images par exemple , j´implémenterai surement une fonction externe dans le style GetImage qui renverrai le Handle de la ressource,qui aurait alors pour effet de nous retrouver dans le cas précédent.

Extrait de l´aide du SDK Win32 :
"Each DLL has a preferred base address, specified at link time. If the
address space from the base address to the base address plus image size is
unavailable, then the DLL is loaded elsewhere and fixups will be applied."
Il semblerai que les DLLs ait une adresse de base.
Par conséquent il n´est pas impossible de connaitre l´adresse de l´image de la DLL en mémoire(cela est possible parce que windows fonctionne de la sorte).

Autre extrait :
"It is possible that the DLL is
loaded at different addresses in different processes. The memory manager
optimizes the loading of DLLs so that if two processes share the same pages
from the same image, they will share the same physical memory."
Cet extrait semble illustrer le fait qu´il n´y a qu´une seule image de la DLL en mémoire et que c´est windows que gère les sauts.

Il est possible que mon interprétation ne soit pas correct.

je pense aussi qu´une dll n´a qu´une seule image, sinon quel interet ?
apres pour résoudre tout les problemes de conflits et de partage, je crois qu´a chaque processus appellant une dll, un contexte d´execution lui est associé(les variable nécessaires a l´utilisation de la dll en quelques sorte) et chaque proceesus a le son contexte.Ce qui est insignifiant en taille par rapport a une quelquonque dll)

Sarafan :

L´adresse de base de la DLL:
Cette adresse est l´adresse ou la DLL voudrait bien etre mappé pour minimiser la resolution des reference. Mais elle ne maitrise pas la liberté de cette adresse. Si le process appelant a deja quelque chose de mappé a cette adresse ben l´adresse qu´aimerait avoir la DLL on s´en cogne et on reloge la DLL.

Pour le deuxieme extrait je suis dubitatif.

Y a quelque chose la dessous, j´y retourne immediatement...
La manipulation en cours est de
1/ Creer une DLL avec un saut relatif.
2/ Verifier dans le code binaire que ce saut relatif existe ! !
3/ Charger cette DLL a une adresse X avec un programme et retrouver ce saut qui maintenant est absolu. ( Noter l´adresse absolue )
4/ Refaire la 3 mais en chargeant la DLL a une adresse Y.

A ton avis est ce que cette manipulation prouvera si les adresses de saut sont differentes que la DLL est mappé une fois pas process et que son code est dupliqué.
Ted33 : Comment explique tu que lorsque tu fait un jump sur une etiquette tu le retrouve dans ton bianire sous la forme JUMP +NOctet , et que lorsque qu´il est reelement en memoire tu le trouve sous la forme JUMP ADDRESSE . ...
Il y a eu au chargement relogement de ta DLL qui effectue une modification effective de ton code bianire. Pas possible de mettre ceci uniquement dans un contexte, pas possible de n´avoir alors qu´une seule image memoire du code . ...
Alors ?

Après y avoir réfléchi voila comment je vois les choses :
Un process A charge la DLL , une adresse lui est alloué et un Handle est retourné au process,de plus un mappage au niveau de l´espace d´adressage du process à lieu.
1) Le handle sert au gestionnaire mémoire à retrouver l´adresse absolue de l´image de la DLL via une table de correspondance.
2) L´espace mémoire mappé est en fait la zone de données,la zone de code pouvant être partagée.

Quand on veut récupérer un référence externe , on donne comme paramètre le Handle de la DLL et le nom de la référence ( ou son index si les références sont indexées) , il va faire la correspondance entre le handle et l´adresse de l´image de la DLL.
Il va rechercher la référence,on supposera que le début de l´image de la DLL est la table des références avec les offset par rapport à l´adresse d´implantation,ensuite il renvoie au Process Adresse de base de la DLL + l´offset de la référence.

Un process B charge la DLL à son tour , comme elle est chargée le Handle retouné est celui qui a été attribué au moment où A a chargé la DLL et l´espace d´adressage est mappé pour la zone de données.
Ensuite l´accès au références externes se fait de la même manière.

Cela signifie que le code exécutable n´est chargé qu´a un seul endroit en mémoire mais que la zone de données(contenant toutes les variables déclarées) elle est différente pour chaque process(ce qui le plus logique du monde).

Donc ce qui veut dire que la résolution des adresses passe par une table de correspondance et que la clé est le Handle.

Ok, j´viens de faire des essai.
Ca colle, la DLL n´est chargé en memoire qu´une seule fois.

Je retire ce que j´ai dit, c´est des betises.

Merci de cette discussion.

Alors pour expliquer les resultats que j´ai :
Les saut relatif, restent des saut relatif !
La resolution des fonctions passent par une table calculé logé dans le process au moment du loadlibrary. Le GetProcAdress ne sert donc qu´a se deplacer dans cette table pour trouver le point d´entree de la fonction ( en fait un jmp). La fonction est deja diponible des le chargement de la DLL. On peut faire le GetProcAdress a la main assez aisement , mais a quoi bon . ...

Merci a tous de vos reponses construtives.

Si vous souhaitez plus de details ben je suis a votre disposition.

PITIER JE NE VEU PLUS RIEN ENTENDRE SUR LES... LES... JARIVE MEME PLUS A LE DIRE D...D...DLL.

lol.

Passage

Tu dis merci , je te dis donc de rien et également merci.
J´ai beaucoup apprécié cette discussion constructive et instructive.