GetModuleHandleA, fonction (libloaderapi.h)
Récupère un handle de module pour le module spécifié. Le module doit avoir été chargé par le processus appelant.
Pour éviter les conditions de concurrence décrites dans la section Notes, utilisez la fonction GetModuleHandleEx.
Syntaxe
HMODULE GetModuleHandleA(
[in, optional] LPCSTR lpModuleName
);
Paramètres
[in, optional] lpModuleName
Nom du module chargé (un fichier .dll ou .exe). Si l’extension de nom de fichier est omise, l’extension de bibliothèque par défaut .dll est ajoutée. La chaîne de nom de fichier peut inclure un caractère de point de fin (.) pour indiquer que le nom du module n’a pas d’extension. La chaîne n’a pas besoin de spécifier un chemin d’accès. Lors de la spécification d’un chemin d’accès, veillez à utiliser des barres obliques inverses (\), et non pas des barres obliques (/). Le nom est comparé (cas indépendamment) aux noms des modules actuellement mappés dans l’espace d’adressage du processus appelant.
Si ce paramètre est NULL, GetModuleHandle retourne un handle au fichier utilisé pour créer le processus appelant (fichier.exe).
La fonction GetModuleHandle ne récupère pas de handles pour les modules chargés à l’aide de l’indicateur LOAD_LIBRARY_AS_DATAFILE. Pour plus d’informations, consultez LoadLibraryEx.
Valeur de retour
Si la fonction réussit, la valeur de retour est un handle du module spécifié.
Si la fonction échoue, la valeur de retour est NULL. Pour obtenir des informations d’erreur étendues, appelez GetLastError.
Remarques
Le handle retourné n’est pas global ou hérite. Il ne peut pas être dupliqué ou utilisé par un autre processus.
Si lpModuleName n’inclut pas de chemin d’accès et qu’il existe plusieurs modules chargés avec le même nom de base et la même extension, vous ne pouvez pas prédire le handle de module qui sera retourné. Pour contourner ce problème, vous pouvez spécifier un chemin d’accès, utiliser assemblys côte à côte, ou utiliser GetModuleHandleEx pour spécifier un emplacement de mémoire plutôt qu’un nom DLL.
La fonction GetModuleHandle retourne un handle à un module mappé sans incrémenter son nombre de références. Toutefois, si ce handle est passé à la fonction FreeLibrary
Cette fonction doit être utilisée soigneusement dans une application multithread. Il n’existe aucune garantie que le handle de module reste valide entre le moment où cette fonction retourne le handle et l’heure à laquelle elle est utilisée. Par exemple, supposons qu’un thread récupère un handle de module, mais avant d’utiliser le handle, un deuxième thread libère le module. Si le système charge un autre module, il peut réutiliser le handle de module récemment libéré. Par conséquent, le premier thread aurait un handle pour un module différent de celui prévu.
Exemples
Pour obtenir un exemple, consultez Utilisation de pinceaux.
Note
L’en-tête libloaderapi.h définit GetModuleHandle comme alias qui sélectionne automatiquement la version ANSI ou Unicode de cette fonction en fonction de la définition de la constante de préprocesseur UNICODE. Le mélange de l’utilisation de l’alias neutre en encodage avec du code qui n’est pas neutre en encodage peut entraîner des incompatibilités qui entraînent des erreurs de compilation ou d’exécution. Pour plus d’informations, consultez Conventions pour les prototypes de fonction.
Exigences
| Exigence | Valeur |
|---|---|
| client minimum pris en charge | Windows XP [applications de bureau uniquement] |
| serveur minimum pris en charge | Windows Server 2003 [applications de bureau uniquement] |
| plateforme cible | Windows |
| d’en-tête | libloaderapi.h (include Windows.h) |
| bibliothèque | Kernel32.lib |
| DLL | Kernel32.dll |
Voir aussi
fonctions de bibliothèque Dynamic-Link