Besoin de précision sur les DLL

Mastersam Messages postés 116 Date d'inscription dimanche 26 septembre 2004 Statut Membre Dernière intervention 13 février 2008 - 11 déc. 2004 à 22:56
cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 - 12 déc. 2004 à 20:15
Bonjour j'ai actuellement créé un pilote pour une interface se connectant à un port usb. En fait il s'agit d'un pilote de pilote car cette interface a déjà des pilotes bruts, avec les fonctions d'ouverture de paramétrages et autres de l'interface. Mais pour qu'elle soit plus pratique j'ai refait un pilote par dessus qui utilise la première dll (dont j'ai tout les éléments .h .a .lib mais pas la source).

Le mien marche parfaitement quand le pilote primaire de l'interface est installé mais le problème c'est que quand il ne l'est pas et bien mon pilote produit une erreur "impossible de localiser machin.dll" alors je voudrais savoir comment inclure complètement machin.dll pour qu'il n'aille pas le rechercher je ne sais ou.

Je suis en C sous devcpp 4.9.1

Merci d'avance.

http://www.rc-bot.com

7 réponses

boumarsel Messages postés 298 Date d'inscription jeudi 12 juin 2003 Statut Membre Dernière intervention 9 juillet 2008 1
12 déc. 2004 à 02:06
il faut le copier dans le repertoire ou se trouve l'exe de l'application.
0
cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
12 déc. 2004 à 04:17
Tiré de MSDN, la liste des dossiers dans lesquels Windows cherche les DLL de ton prog :
1. The directory from which the application loaded.
2. The current directory.
3. Windows 95: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.

Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

4. Windows NT: The 16-bit Windows system directory. There is no Win32 function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

Si tu veux éviter cette erreur lorsque la dll est introuvable, passe par une liaison dynamique (LodaLibrary + GetProcAdress) au lieu de statique, tu pourras ainsi retomber sur tes pieds et afficher un message plus explicite que celui de Windows (ou extraire la dll à partir des ressources de ton exe, si tu l'as incluse).
0
Mastersam Messages postés 116 Date d'inscription dimanche 26 septembre 2004 Statut Membre Dernière intervention 13 février 2008
12 déc. 2004 à 12:52
Oui ça j'ai bien compris que je pouvais la mettre dans mon dossier d'exe ou System et c'est ce qui est fait lorsque j'installe le pilote primaire et là je n'ai pas de problème. Mais mon soucis c'est justement lors de l'execution de mon programme sur des machines où ce pilote n'est pas installé, et bien à chaque démarrage ma dll que j'ai construit plante car elle ne trouve pas l'autre alors que je l'ai lié en espérant qu'elle soit désormais complètement incluse dans ma dll à moi.

Ce que je voudrais donc c'est savoir comment l'inclure proprement de façon à ce que ma dll se suffise à elle même. En y réfléchissant je ne suis pas sur que cela fonctionne car le pilote primaire est installé quand on connecte cette interface la première fois, mais moi je dois bien utiliser ce pilote et je ne suis pas sur que ce soit directement celui que je charge dans ma dll.

Donc j'aime bien la solution de Nebula avec une liason dynamique seulement je mets comment ma GetProcAdresse car je ne la connais pas. Et je charge comment toutes les fonctions, car il y en a un sacré paquet quand même (plus de 20 que j'utilise directement sans vraiment savoir si elle n'en appellent pas d'autres).
Car pour utiliser une dll ce que je fait d'habitude c'est :

HINSTANCE hModDll;
  hModDll = LoadLibrary("Interfaces/odmxusb.dll");
  if(hModDll == 0){
      MessageBox(GetActiveWindow(),"Erreur lors du chargement du pilote de l'interface DMX.","Erreur",0);
      driverloaded=FALSE;
  }else{      
      
           
  DMXopendevice = (lpFunc1) GetProcAddress((HINSTANCE)hModDll,"opendevice");
  DMXverifdll = (lpFunc1) GetProcAddress((HINSTANCE)hModDll,"verifdll");
  DMXclosedevice = (lpFunc1) GetProcAddress((HINSTANCE)hModDll,"closedevice");         
  DMXsendtrame = (lpFunc2) GetProcAddress((HINSTANCE)hModDll,"sendtrame");       
  driverloaded=TRUE;


Car c'est ma dll et je connais ses fonctions, mais dans dans le .lib de la dll que je dois appeler il y a vraiment bcp de fonctions et c'est écrit tout bizarre, et je viens de m'apercevoir que je n'ai pas de .a .

Voilà j'espère que j'ai recentré mon problème.
Merci

http://www.rc-bot.com
0
cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
12 déc. 2004 à 17:50
Tu ne charges avec GetProcAdress que les fonctions que tu utilises, si elles en appellent d'autres dans la dll elles sauront les trouver toutes seules (par les RVA, qui sont résolues pour toutes les procédures lors du chargement de la dll).

Après je suis pas sûr d'avoir compris ton problème, c'est normal d'avoir une erreur si une dll est manquante non ?
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
boumarsel Messages postés 298 Date d'inscription jeudi 12 juin 2003 Statut Membre Dernière intervention 9 juillet 2008 1
12 déc. 2004 à 18:31
son probleme c'est que sa DLL qu'il maitrise bien toutes ses fonctions (donc elle ne lui pose aucun probleme) appelle une autre DLL depondante du poste du client.le probleme est posé quand sa DLL appelle les fonctions de l'autre DLL.
mastersam> 'je viens de m'apercevoir que je n'ai pas de .a .' tu veux dire .h?
0
Mastersam Messages postés 116 Date d'inscription dimanche 26 septembre 2004 Statut Membre Dernière intervention 13 février 2008
12 déc. 2004 à 19:48
Non je parle bien du .a j'ai le .h mais en fait ça n'est pas du .a que j'aurais le plus besoin c'est du .def qui recence "en français lisible" les fonctions de la DLL.

Sinon c'est vrai que mon problème ressemble pas mal à ce que tu a dit.

En fait je voudrais : soit complètement manger la dll primaire dans la mienne pour qu'elle soit autonome, soit faire en sorte de n'appeler la primaire que si elle est là, pour eviter d'avoir une erreur à chaque démarrage. Surtout que pour l'instant il n'y a qu'une interface mais par la suite il y en aura plusieurs qui ne seront pas toutes installées sur le pc client et donc si j'utilise toujours la même méthode et bien j'aurais autant d'erreur que d'interfaces absentes.

Je pense qu'en faisant comme Nebula a dit ça peut marcher le seul problème c'est que c'est assez long à programmer et que ça oblige à avoir toujours les bon pilotes. J'explique: Si les constructeurs de mon interface sortent de nouveaux pilotes et que je les installe, la dll primaire va changer mais comme je n'aurais pas encore changé la mienne et bien ça risque de planter car je vais appeler des fonctions qui ne seront plus les même. Et inversement si mon logiciel est executé sur un pc où le dll primaire de l'interface est plus ancien que celui avec lequel j'ai créé ma dll et bien il y a des chances pour que cela bug.

C'est pour ça que je préfèrerais directement l'inclure et que j'obtienne un seul pilote et un seul fichier à charger par mon logiciel. Quitte à inclure l'autre dll en binaire dans ma dll, mais là je ne sais pas du tout comment faire.

http://www.rc-bot.com
0
cs_Nebula Messages postés 787 Date d'inscription samedi 8 juin 2002 Statut Membre Dernière intervention 7 juin 2007 2
12 déc. 2004 à 20:15
Hm si tu as les sources des dlls, tu peux tenter une compilation en tant que .a, en vue de tenter une liaison statique. Sinon, je ne vois pas d'autre solution que la liaison dynamique déjà exposée plus haut :-/

Pour le .def, MinGW fournit un programme appelé "pexports" dans son paquage "mingw-utils", qui permet de créer un .def à partir d'une dll, tu devrais regarder de ce côté là (normalement tu devrais déjà l'avoir, puisque DevC++ dépend de MinGW).
0
Rejoignez-nous