Discussion :

[jenez]

Bonjour !
alors voila, je voudrais faire une dll capable d'obtenir son chemin d'accès, mais ca marche pas. Voila le problème :
Ma DLL contient la fonction suivante, qui normalement doit afficher son chemin d'accès, soit C:\MesDocs\maDll.dll ( pour schématiser ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#define DLLEXPORT   __declspec (dllexport)

void DLLEXPORT fonction ( void )
{
    char pathname[256];
    
    HMODULE hMe = GetModuleHandle(NULL); 
    DWORD nRet = GetModuleFileName(hMe, pathname, 256);
    MessageBox(0, pathname, "Chemin de la DLL", MB_ICONINFORMATION);
}

Et j'ai une application qui doit activer la fonction de ma dll :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fonction();

Ok, je lance l'application, et la ca m'affiche le chemin d'accès de l'application ( on a qu'a dire C:\MesDocs\monAppli.exe ), et pas de la DLL !!
Comment faire pour que ma DLL trouve son chemin toute seule ?
Merciiii !

[Neitsa]

Bonjour,

Le paramètre NULL pour GetModuleHandle fait toujours référence à l'exécutable.

Pour avoir le chemin de ta dll depuis celle-ci, prend le HANDLE (parfois un HINSTANCE) de ta dll que tu peux récupèrer lors de son initialisation et sauve le en variable globale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
BOOL APIENTRY DllMain( HANDLE hModule, // à sauver
                       DWORD  ul_reason_for_call, 
                       LPVOID lpReserved
					 )

Ensuite, depuis ta fonction "fonction" tu passes ce HANDLE à la fonction GetModuleFileName(), tu aura le chemin complet dans le buffer.

[jenez]

Je n'y arrive pas. En faite je dois pas bien m'y prendre pour la sauvegarde de l'hinstance ( c'est pas un handle d'ailleurs, ca change quelque chose ? )
Enfin voila ce que ca donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
char HINST[256]; // variable globale

BOOL APIENTRY DllMain ( HINSTANCE hinst, DWORD raison, LPVOID reserv )
{
    if ( raison == DLL_PROCESS_ATTACH )
        HInst = hinst;
    sprintf(HINST, hinst); // euh... c'est vraiment la bonne fonction ?
    return TRUE;
}


void DLLEXPORT fonction ( void )
{
    char pathname[256];

    //HMODULE hMe = GetModuleHandle(NULL); // on supprime, puisque c'est pour l'exécutable
    DWORD nRet = GetModuleFileName(HINST, pathname, 256);
    MessageBox(0, pathname, "Chemin de la DLL", MB_ICONINFORMATION);
}

Déjà j'ai un warning pour la conversion invalide du sprintf et le pointeur incompatible de GetModuleFileName, et quand je lance l'appli qui utilise la fonction de la dll :
"I%"
Bouhhh !

PS : Merci encore pour ton aide !

[kidpaddle2]

Là, ce n'est même pas un problème de WinAPI, mais plutôt de C... tu ne peux pas inscrire dans une chaîne une instance ! -je ne vois d'ailleurs pas l'intérêt...-

Tu peux par contre faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
HINSTANCE instance;

//...

instance = hThisInstance;

[David.Schris]

Bonjour,

[...] hinstance ( c'est pas un handle d'ailleurs [...]

Et le "H" de "HINSTANCE", que veut-il dire ?

[jenez]

Ca marche nikel ! Merci beaucoup !

[Médinoc]

Bonjour,

Et le "H" de "HINSTANCE", que veut-il dire ?

Ce n'est pas un "Vrai" handle, et ce n'est certainement pas un HANDLE (le type HANDLE étant pour moi réservé aux objets Kernel).

Bien que HINSTANCE et HMODULE partagent le même typedef, l'aide dit que ce ne sont pas exactement les mêmes types, et que l'un des deux représente l'adresse de base d'un module dans la mémoire virtuelle du processus.

Par contre, ils gardent la caractéristique principale de tout handle: L'unicité dans un processus: deux modules ne peuvent pas avoir le même HINSTANCE/HMODULE dans le même processus (il dans le cas présent, il est possible que cette unicité soit réciproque).

[jenez]

ouais, moi handles, hinstances et modules je fais pas trop la différence...
mais merci quand même pour ta petite explication !

[David.Schris]

Ce n'est pas un "Vrai" handle, et ce n'est certainement pas un HANDLE (le type HANDLE étant pour moi réservé aux objets Kernel).

[...]

Que de détails !
Mon propos n'était pas de dire que c'était un "vrai handle (<- nom commun en minuscules, pas typedef en majuscules) pur jus 100% sans impuretés", juste que c'était un handle d'après la doc. de MS.

BOOL WINAPI DllMain(
HINSTANCE hinstDLL,
DWORD fdwReason,
LPVOID lpvReserved
);

Parameters

hinstDLL
[in] Handle to the DLL module.

<shamelessPlug>Sinon, si tu aimes donner des détails, je suis preneur de détails sur les fonctions de samsrv.dll</shamelessPlug>

[Aurelien.Regat-Barrel]

A l'origine c'était un Handle (Win 3x). Mais en prog 32 bits il n'a plus de sens. Il est là pour compatibilité ascendante.
Note que les handles GDI et User sont eux aussi des vrais handles.

[David.Schris]

Comment reconnaît-on un "vrai" handle d'un faux ?

[Médinoc]

En l'occurence, un "vrai" handle est plus ou moins supposé n'être rien d'autre qu'un descripteur/ID/etc (mais c'est flou, bien sûr).

Les handles des objets Kernel (HANDLE) sont typiquement des descripteurs (pour être précis, c'est le niveau en-dessous). Il me semble qu'il en est de même pour les objets USER (globaux) et GDI (locaux à un processus, bien qu'accessibles sous un ancien Windows).

Le HINSTANCE/HMODULE portant une information supplémentaire (adresse de base du module), on peut les considérer comme autre chose que des "vrais" handles (bien que je reconnaisse que c'était pompeux de ma part de dire cela).

Mais rétrospectivement, je me dis que cette "limite" est trop floue pour qu'on puisse vraiment dire qu'il y en a une: De quels types sont les handles de la CryptoAPI ? Spécialement le plus extérieur (HCRYPTPROV) qui est peut-être en vérité un pointeur opaque...
Sans compter les HGLOBAL/HLOCAL, qui ne sont visiblement pas des handles Kernel puisqu'ils ne sont pas duplicables par DuplicateHandle(), mais qui sont marshallés par le DDE...

[David.Schris]

Ok.
D'une certaine façon, cela dépend comment on le regarde.
Pour faire un parallèle (douteux?), pour toi le numéro national d'identité ne serait pas un "vrai" handle et le numéro d'une plaque d'immatriculation sans numéro de département en serait un, c'est bien ça ?

[Aurelien.Regat-Barrel]

Le principe des handle, c'est un idiome de programmation qu'on retrouve ailleurs qu'en Win32. Un handle, c'est un identifiant opaque, qui identifie quelque chose. HINSTANCE : handle sur une instance ? kesako ?
Et sa valeur n'est pas opaque du tout (adresse du process mappé en mémoire), donc c'est pas un handle.
En Win32, on ne prend traditionnellement en compte que 3 types de handle : noyau, user, GDI, issus de 3 "bibliothèques" différentes. Mais pour le reste (CryptoAPI, Wininet, Heap...), le terme de handle me semble tout à fait correct. Ce sont des handles propres à une lib, alors que les précédents sont gérés par l'OS. Mais ils sont distincts : un handle kernel n'a rien à voir un handle GDI, et il convient d'utiliser les fonctions adaptées (CloseHandle/DeleteObject, ...).
Bref, tout ça pour dire qu'il y a très peu de "faux" handle.

[David.Schris]

Le principe des handle, c'est un idiome de programmation qu'on retrouve ailleurs qu'en Win32. Un handle, c'est un identifiant opaque, qui identifie quelque chose. HINSTANCE : handle sur une instance ? kesako ?
Et sa valeur n'est pas opaque du tout (adresse du process mappé en mémoire), donc c'est pas un handle.
[...]

La valeur d'un HINSTANCE n'est pas opaque quand tu te préoccupes de ce qu'il y a dedans. Si tu ne t'en soucies jamais, et c'est possible, cela sera - de ton point de vue - un handle, mais pas dans l'absolu. D'où ma phrase précédente : "D'une certaine façon, cela dépend comment on le regarde".
Je ne sais pas si je suis plus clair cette fois...???...

Bref, je crois que nous sommes vaguement d'accord mais que nous ne voyons pas forcément les choses sous le même angle...

Quelqu'un veut ajouter quelque-chose ? (à part un lien vers un article de Wikipedia)

[Aurelien.Regat-Barrel]

Je n'ai pas cherché à contester tes propos, je pense comme tu dis qu'on est d'accord. Le principe du handle c'est que tu n'as pas à te soucier de sa valeur (à part NULL/INVALID etc...) car elle n'est pas censé avoir de signification pour toi = le client de la bibliothèque.
Dans le cas de HINSTANCE:
http://msdn.microsoft.com/library/en...se/dllmain.asp

hinstDLL
[in] Handle to the DLL module. The value is the base address of the DLL. The HINSTANCE of a DLL is the same as the HMODULE of the DLL, so hinstDLL can be used in calls to functions that require a module handle.

la valeur du "handle" n'est pas opaque, elle est documentée comme ayant une signification. C'est ce qui en fait, à mon avis, un faux handle, car à la base le handle est là pour dissimuler une structure interne privée. Et là, il n'y a aucune structure cachée rattachée à ce handle. Donc, HINSTANCE/HMODULE, ce sont simplement des pointeurs.

Ils ont laissé en l'état à cause de l'aspect historique de la chose. C'est comme WPARAM, qui n'est plus un WORD depuis longtemps, mais qui s'appelle toujours WPARAM.

[Médinoc]

En effet, le WPARAM est maintenant un UINT_PTR (et le LPARAM un LONG_PTR).
Pourtant, hélas, on trouve encore des gens qui apprennent à programmer avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LONG FAR PASCAL WindowProc(HWND, WORD, WORD, LONG);

Je le sais, mon vieux prof de système m'a appris ça en 2001...
Difficile d'utiliser HIWORD(wParam) avec ça...

[David.Schris]

Je n'ai pas cherché à contester tes propos

<dialogueDeSourds>Je n'ai jamais dit que tu contestais mes propos.</dialogueDeSourds>

[Aurelien.Regat-Barrel]

Je le sais, mon vieux prof de système m'a appris ça en 2001...

Estime toi heureux d'avoir eu une initiation à Win32/Win16 à l'école.

[Médinoc]

Ah, non, pas à l'école!
Dans mon école d'ingé, on n'a eu droit qu'à du mode console sur un très vieil unix (le gcc installé ne reconnait même pas -Wextra), et un peu de java Swing.

Ma formation Windows, je l'ai eu en BTS II (dernière année avant que ça ne devienne IRIS) et en fait, j'ai appris les sockets sous Windows.