Again ! un topic pour ouvrir une DLL

Salut !

Voici mon bout de code, qui doit servir à ouvrir une DLL "madll.dll", qui, vous vous en doutez, ne marche pas (compil sous MSV2005)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#include <windows.h> #include <string.h> #include <stdio.h> #include <stdlib.h> int main(void) { HMODULE ret; static char chaine[255]="madll.dll"; FILE *fp = fopen(chaine,"r"); if (fp !=NULL) { printf("File %s Exists !\n",chaine); fclose(fp); } else printf("File %s Do Not Exist !\n",chaine); ret = LoadLibrary((LPCWSTR)chaine); printf("LL ret = %d\n",(int)ret); if(!ret) printf("Error code = %d\n",GetLastError()); return(0); }

---

Bien sur avec mon fopen j'arrive à voir le fichier, mais LoadLibrary me retourne toujours 0 avec un code d'erreur 126, cad que le fichier n'existe pas...

J'ai aussi essayé d'ouvrir pour essayer user32.dll, sans succès...


Pourquoi? :bug:

Regarde si l'utilisation de LoadLibrary ne necessite pas un enregistrement de ta dll en base de registre avant de l'utiliser

Bonjour,

Code:

---

1 2 3 4 5 6

static char chaine[255]="madll.dll";   ...   ret = LoadLibrary((LPCWSTR)chaine);

---

Ouch ! Tu convertis explicitement un char* en const wchar_t*...

Le problème vient du fait que tu compiles avec _UNICODE défini.

Deux solutions :

Code:

---

1 2 3 4 5 6

static char chaine[]="madll.dll";   ...   ret = LoadLibraryA(chaine); // note le 'A' à la fin du nom de la fonction.

---

Code:

---

1 2 3 4 5 6

static WCHAR chaine[]= L"madll.dll";   ...   ret = LoadLibrary(chaine) // sous entendu LoadLibraryW puisque _UNICODE est défini.

---

Ouf merci, ça fait du bien quand ça marche...
Sous cygwin je n'avais aucun soucis...alors c'est dans MSV2005 qu'il défini UNICODE de base? Pourquoi?8O

Parce que sans-unicode, c'est le passé.

Et la meilleure façon de marcher aussi bien avec UNICODE que sans, c'est d'utiliser des TCHAR :

Code:

---

1 2 3 4 5

static TCHAR chaine[]= TEXT("madll.dll");   ...   ret = LoadLibrary(chaine)

---

PS: Au sujet du cast aveugle en (LPCWSTR), lire ma signature.

Citation:

---

Envoyé par Fortran90

Sous cygwin je n'avais aucun soucis...alors c'est dans MSV2005 qu'il défini UNICODE de base?

---

Oui, par défaut les projets sont en "wide char" (UNICODE). On peut régler cela projet par projet en allant dans :

Project > properties > Configuration properties > general > Character Set.

Là on peut choisir UNICODE ou ANSI (multi-byte character set).

Citation:

---

Pourquoi?8O

---

Après windows 98, Windows est passé quasiment en tout unicode.

Les fonctions finissant en 'A' sont dans la grande majorité des cas des wrappers sur les fonctions 'W' (c-a-d qu'elles convertissent les chaînes en unicode et appellent la même fonctions mais en 'W)'.

On peut toutefois écrire du code "portable" ANSI <-> UNICODE quelque soit le symbole défini en utilisant les macros et définition en '_T'. Exemple :

_tprintf qui utilise char* si unicode n'est pas défini et wchar_t* dans le cas contraire :

Code:

---

1 2 3 4 5 6

#ifdef _UNICODE #define _tprintf wprintf #else #define _tprintf printf #endif

---

P.S : pas besoin de le faire soi-même c'est déjà défini dans les fichiers d'en-tête du SDK de Windows.

Je veux bien que ce soit le passé, mais justement quand on utilise les nouveaux outils sur des codes anciens, on ne peut pas passer son temps à ré-adapter le code. On en finit jamais, surtout quand c'est pas le but final de la manoeuvre...

Alors je "undefined" UNICODE dans mes variables préprocesseurs...
(mais c'est mieux en changeant character set, je l'avais loupé lui...)
C'est si mal que ça?

Pour la signature...qu'une chose à dire...je suis cast(s)é...

C'est juste que LoadLibraryA va allouer de la mémoire, faire un appel à MultiByteToWideChar puis appeler LoadLibraryW...
Et ce, depuis NT4