Question sur DLL

Version imprimable

04/08/2006, 10h42
inertia

Question sur DLL

Je me pose une question sur les DLL dans windows XP.

J'ai tenté récement de recompiler une version maison de openAL. Initialement la librairie openAL se nomme : OpenAL32.dll. Ma version s'appelle MyOAL.dll.

J'ai ensuite tenté de la tester avec un p'tit jeu qui utilise openAL pour son rendu sonore : Chromium BSU. Initialement la dll OpenAL32.dll se trouve au même niveau que l'exécutable du jeu.

Si j'enlève la dll OpenAL32.dll et que je mets ma librairie. Le jeu utilise ma librairie. Curieux elles n'ont pas le même nom pourtant.

Pire, le jeu utilise ma dll si celle-çi ainsi que OpenAL32.dll se trouve au même niveau que l'exécutable. Comment expliquer cela ?

Windows scrute d'abord le repertoire courant tente de charger chaque dll (dans l'ordre alphabétique) et y cherche les ref aux fonctions utilisé par le prog ? A la première dll qui correspond il s'arrête ?

Si un expert pouvait m'éclairer sur ce point.
Merci d'avance
05/08/2006, 13h28
rigobert

Ce ne sont que des hypothèses, mais il se pourrait bien que :

- l'application examine au démarrage tous les fichiers DLL du dossier courant (le sien, donc).
- dans chacune des DLLs trouvées, recherche si les fonctions dont elle a besoin existent.
- si toutes les fonction requises sont disponibles, alors la DLL est retenue.
- et si plusieurs DLLs implémentent les fonctions requises, alors c'est la DLL la plus récente qui est sélectionnée.

C'est un fonctionnement plausible, même si je pense personnellement que ce n'est pas génial en termes de conception, fiabilité et sécurité.
06/08/2006, 00h40
Ti-R

Citation:

Si j'enlève la dll OpenAL32.dll et que je mets ma librairie. Le jeu utilise ma librairie. Curieux elles n'ont pas le même nom pourtant.

Me semble vraiment bizarre, comment tu es sur que c'est ta lib ?

En principe (j'en suis quasi certain), Windows regarde la dll dans le répertoire courant !
Si le nom de la dll ne s'y trouve pas, il va regarder dans les autres répertoires situé dans la variable d'environnement "path"

En ligne de commande

Code:

echo &path

S’il ne trouve pas le nom la dll, il jète un message "…. xxx.dll est introuvable …"

Donc je pense que tu as l'impression qu'il utilise ta dll, mais il doit sûrement en trouver une autre dans « Windows/system32/ » par exemple.
06/08/2006, 02h23
sloshy

Bonjour,

Citation:

Envoyé par Ti-R

Me semble vraiment bizarre, comment tu es sur que c'est ta lib ?

En principe (j'en suis quasi certain), Windows regarde la dll dans le répertoire courant !
Si le nom de la dll ne s'y trouve pas, il va regarder dans les autres répertoires situé dans la variable d'environnement "path"

En ligne de commande

Code:

echo &path

S’il ne trouve pas le nom la dll, il jète un message "…. xxx.dll est introuvable …"

Donc je pense que tu as l'impression qu'il utilise ta dll, mais il doit sûrement en trouver une autre dans « Windows/system32/ » par exemple.

Je supose qu'il sait que c'est sa dll car le rendu doit être différent non? (sinon il n'aurait pas modifier la dll ...)

Sinon, si ce qui est dit au dessus est vrai, ça fait peur en terme de sécurité 8O
06/08/2006, 02h48
David.Schris

Citation:

Envoyé par Ti-R

En principe (j'en suis quasi certain), Windows regarde la dll dans le répertoire courant !
Si le nom de la dll ne s'y trouve pas, il va regarder dans les autres répertoires situé dans la variable d'environnement "path"

Ben non. Voir "Dynamic-Link Library Search Order" : là tu pourras être certain que le répertoire courant (à ne pas confondre avec le répertoire de l'application) n'est jamais le premier et que la recherche dans les répertoires dont le nom est présent dans la variable "PATH" s'effectue toujours en dernier.

Citation:

Envoyé par sloshy

Sinon, si ce qui est dit au dessus est vrai, ça fait peur en terme de sécurité 8O

Pas plus que pour n'importe quelle autre application avec n'importe quelle autre DLL (sauf quand des mesures ont spécifiquement été prises contre une utilisation de cet ordre de chargement à des fins malicieuses...ce qui est rare).
06/08/2006, 12h52
Ti-R

Citation:

là tu pourras être certain que le répertoire courant (à ne pas confondre avec le répertoire de l'application)

Abus de langage de ma part, je voulais bien dire le répertoire d'ou l'application est lancé, pas le répertoire sauvegardé comme courant dans Windows.... dsl :aie:

Citation:

la variable "PATH" s'effectue toujours en dernier.

Mais c'est un résumé grossier de ce qui est fait dans la recherche

The system directory
sauf ->The 16-bit system directory
The Windows directory

sauf ->The current directory

Car si on a pas modifié le path

Les 2 premiers chemins sont -> =C:\WINDOWS\system32;C:\WINDOWS;
J'ai toujours pas compris pourquoi ils gardent « C:\WINDOWS\system ».... mais bon il aime garder les reliques du passé ;)

Et la lib OpenAL
A toute les chances de se trouver dans "C:\WINDOWS\system32"
06/08/2006, 15h01
rigobert

Quoiqu'il en soit, si la DLL modifiée est linkée avec succès par l'application alors qu'elle a un nom différent de celle d'origine, Windows n'y est pour rien (et ce n'est pas non plus une question de path);
il n'y a que l'application elle-même qui puisse être responsable d'un truc pareil (entendez par là un comportement totalement atypique), en linkant dynamiquement/manuellement et explicitement telle ou telle DLL sur des critères qui nous échappent certainement un peu ici.
08/08/2006, 11h07
inertia

Donc pour ce qui est de ma DLL j'en suis sur car un traitement spécial (avec alerte visuelle) codé dans le DLLmain se déclenche et en debug mes fonctions sont appelées.

J'ai testé sur un autre exemple tout bête dont j'ai le source, toujours avec OpenAL et le même phénomène se reproduit.

Je vais tenter de me coder une dll de test à 2 fonctions exporté et tenté de l'utiliser dans un petit prog de test, on verra se qui se passe. Si rien, en effet OpenAL ou sa composant ALUT sont responsables.