Fonction LoadLibraryExA (libloaderapi.h)
Charge le module spécifié dans l’espace d’adressage du processus appelant. Le module spécifié peut entraîner le chargement d’autres modules.
Syntaxe
HMODULE LoadLibraryExA(
[in] LPCSTR lpLibFileName,
HANDLE hFile,
[in] DWORD dwFlags
);
Paramètres
[in] lpLibFileName
Chaîne qui spécifie le nom de fichier du module à charger. Ce nom n’est pas lié au nom stocké dans un module de bibliothèque lui-même, tel que spécifié par le mot clé LIBRARY dans le fichier de définition de module (.def).
Le module peut être un module de bibliothèque (un fichier .dll) ou un module exécutable (fichier .exe). Si le module spécifié est un module exécutable, les importations statiques ne sont pas chargées ; Au lieu de cela, le module est chargé comme si DONT_RESOLVE_DLL_REFERENCES a été spécifié. Pour plus d’informations, consultez le paramètre dwFlags.
Si la chaîne spécifie un nom de module sans chemin d’accès et que l’extension de nom de fichier est omise, la fonction ajoute l’extension de bibliothèque par défaut « .DLL » au nom du module. Pour empêcher la fonction d’ajouter « .DLL » au nom du module, incluez un caractère de point de fin (.) dans la chaîne de nom du module.
Si la chaîne spécifie un chemin complet, la fonction recherche uniquement ce chemin d’accès pour le module. Lors de la spécification d’un chemin d’accès, veillez à utiliser des barres obliques inverses (\), et non pas des barres obliques (/). Pour plus d’informations sur les chemins d’accès, consultez noms de fichiers, de chemins d’accès et d’espaces de noms.
Si la chaîne spécifie un nom de module sans chemin d’accès et que plusieurs modules chargés ont le même nom de base et l’extension, la fonction retourne un handle au module chargé en premier.
Si la chaîne spécifie un nom de module sans chemin d’accès et qu’un module du même nom n’est pas déjà chargé, ou si la chaîne spécifie un nom de module avec un chemin relatif, la fonction recherche le module spécifié. La fonction recherche également des modules si le chargement du module spécifié entraîne le chargement du système d’autres modules associés (autrement dit, si le module a des dépendances). Les répertoires qui sont recherchés et l’ordre dans lequel ils sont recherchés dépendent du chemin spécifié et du paramètre dwFlags. Pour plus d’informations, consultez Remarques.
Si la fonction ne trouve pas le module ou l’une de ses dépendances, la fonction échoue.
hFile
Ce paramètre est réservé à une utilisation ultérieure. Elle doit être NULL.
[in] dwFlags
Action à entreprendre lors du chargement du module. Si aucun indicateur n’est spécifié, le comportement de cette fonction est identique à celui de la fonction LoadLibrary. Ce paramètre peut être l’une des valeurs suivantes.
| Valeur | Signification |
|---|---|
|
Si cette valeur est utilisée et que le module exécutable est une DLL, le système n’appelle pas DllMain pour l’initialisation et l’arrêt des processus et des threads. En outre, le système ne charge pas de modules exécutables supplémentaires référencés par le module spécifié.
Remarque N’utilisez pas cette valeur ; elle est fournie uniquement pour la compatibilité descendante. Si vous envisagez d’accéder uniquement aux données ou aux ressources dans la DLL, utilisez LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_IMAGE_RESOURCE ou les deux. Sinon, chargez la bibliothèque en tant que module DLL ou exécutable à l’aide de la fonction LoadLibrary.
|
|
Si cette valeur est utilisée, le système ne vérifie pas règles de AppLocker ou applique stratégies de restriction logicielle pour la DLL. Cette action s’applique uniquement à la DLL chargée et non à ses dépendances. Cette valeur est recommandée pour une utilisation dans les programmes d’installation qui doivent exécuter des DLL extraites pendant l’installation.
Windows Server 2008 R2 et Windows 7 : sur les systèmes avec KB2532445 installés, l’appelant doit s’exécuter en tant que « LocalSystem » ou « TrustedInstaller » ; sinon, le système ignore cet indicateur. Pour plus d’informations, consultez « Vous pouvez contourner les règles AppLocker à l’aide d’une macro Office sur un ordinateur exécutant Windows 7 ou Windows Server 2008 R2 » dans la Base de connaissances d’aide et de support à https://support.microsoft.com/kb/2532445. Windows Server 2008, Windows Vista, Windows Server 2003 et Windows XP : AppLocker a été introduit dans Windows 7 et Windows Server 2008 R2. |
|
Si cette valeur est utilisée, le système mappe le fichier dans l’espace d’adressage virtuel du processus appelant comme s’il s’agissait d’un fichier de données. Rien n’est fait pour exécuter ou préparer l’exécution du fichier mappé. Par conséquent, vous ne pouvez pas appeler des fonctions comme GetModuleFileName, GetModuleHandle ou GetProcAddress avec cette DLL. L’utilisation de cette valeur entraîne l’écriture en mémoire en lecture seule pour déclencher une violation d’accès. Utilisez cet indicateur lorsque vous souhaitez charger une DLL uniquement pour extraire des messages ou des ressources à partir de celui-ci.
Cette valeur peut être utilisée avec LOAD_LIBRARY_AS_IMAGE_RESOURCE. Pour plus d’informations, consultez Remarques. |
|
Similaire à LOAD_LIBRARY_AS_DATAFILE, sauf que le fichier DLL est ouvert avec un accès en écriture exclusif pour le processus appelant. D’autres processus ne peuvent pas ouvrir le fichier DLL pour l’accès en écriture pendant son utilisation. Toutefois, la DLL peut toujours être ouverte par d’autres processus.
Cette valeur peut être utilisée avec LOAD_LIBRARY_AS_IMAGE_RESOURCE. Pour plus d’informations, consultez Remarques. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge tant que Windows Vista n’est pas pris en charge. |
|
Si cette valeur est utilisée, le système mappe le fichier dans l’espace d’adressage virtuel du processus en tant que fichier image.
Toutefois, le chargeur ne charge pas les importations statiques ou effectue les autres étapes d’initialisation habituelles. Utilisez cet indicateur lorsque vous souhaitez charger une DLL uniquement pour extraire des messages ou des ressources à partir de celui-ci.
Sauf si l’application dépend du fichier ayant la disposition en mémoire d’une image, cette valeur doit être utilisée avec LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_DATAFILE. Pour plus d’informations, consultez la section Remarques. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge tant que Windows Vista n’est pas pris en charge. |
|
Si cette valeur est utilisée, le répertoire d’installation de l’application est recherché pour la DLL et ses dépendances. Les répertoires dans le chemin de recherche standard ne sont pas recherchés. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.
Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge. |
|
Cette valeur est une combinaison de LOAD_LIBRARY_SEARCH_APPLICATION_DIR, de LOAD_LIBRARY_SEARCH_SYSTEM32et de LOAD_LIBRARY_SEARCH_USER_DIRS. Les répertoires dans le chemin de recherche standard ne sont pas recherchés. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.
Cette valeur représente le nombre maximal recommandé de répertoires qu’une application doit inclure dans son chemin de recherche DLL. Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge. |
|
Si cette valeur est utilisée, le répertoire qui contient la DLL est temporairement ajouté au début de la liste des répertoires qui sont recherchés pour les dépendances de la DLL. Les répertoires dans le chemin de recherche standard ne sont pas recherchés.
Le paramètre lpFileName doit spécifier un chemin complet. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH. Par exemple, si Lib2.dll est une dépendance de C:\Dir1\Lib1.dll, loading Lib1.dll with this value causes the system to search for Lib2.dll uniquement dans C :\Dir1. Pour rechercher Lib2.dll dans C :\Dir1 et tous les répertoires du chemin de recherche DLL, combinez cette valeur avec LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge. |
|
Si cette valeur est utilisée, %windows%\system32 est recherché pour la DLL et ses dépendances.
Les répertoires dans le chemin de recherche standard ne sont pas recherchés. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.
Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge. |
|
Si cette valeur est utilisée, les répertoires ajoutés à l’aide du AddDllDirectory ou de la fonction SetDllDirectory sont recherchés pour la DLL et ses dépendances. Si plusieurs répertoires ont été ajoutés, l’ordre dans lequel les répertoires sont recherchés n’est pas spécifié. Les répertoires dans le chemin de recherche standard ne sont pas recherchés. Cette valeur ne peut pas être combinée avec LOAD_WITH_ALTERED_SEARCH_PATH.
Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : Cette valeur nécessite l’installation de KB2533623. Windows Server 2003 et Windows XP : Cette valeur n’est pas prise en charge. |
|
Si cette valeur est utilisée et lpFileName spécifie un chemin absolu, le système utilise la stratégie de recherche de fichiers alternative décrite dans la section Remarques pour rechercher les modules exécutables associés que le module spécifié provoque le chargement. Si cette valeur est utilisée et lpFileName spécifie un chemin relatif, le comportement n’est pas défini.
Si cette valeur n’est pas utilisée ou si lpFileName ne spécifie pas de chemin d’accès, le système utilise la stratégie de recherche standard décrite dans la section Notes pour rechercher les modules exécutables associés que le module spécifié provoque le chargement. Cette valeur ne peut pas être combinée avec n’importe quel indicateur de LOAD_LIBRARY_SEARCH. |
|
Spécifie que la signature numérique de l’image binaire doit être vérifiée au moment du chargement.
Cette valeur nécessite Windows 8.1, Windows 10 ou version ultérieure. |
|
Si cette valeur est utilisée, le chargement d’une DLL pour l’exécution à partir du répertoire actif n’est autorisé que s’il se trouve sous un répertoire dans la liste de chargement sécurisé. |
Valeur de retour
Si la fonction réussit, la valeur de retour est un handle pour le module chargé.
Si la fonction échoue, la valeur de retour est NULL . Pour obtenir des informations d’erreur étendues, appelez GetLastError.
Remarques
La fonction LoadLibraryEx est très similaire à la fonction LoadLibrary. Les différences se composent d’un ensemble de comportements facultatifs qui LoadLibraryEx fournit :
- LoadLibraryEx peut charger un module DLL sans appeler la fonction DllMain de la DLL.
- LoadLibraryEx peut charger un module d’une manière optimisée pour le cas où le module ne sera jamais exécuté, en chargeant le module comme s’il s’agissait d’un fichier de données.
- LoadLibraryEx pouvez rechercher des modules et leurs modules associés à l’aide de l’une des deux stratégies de recherche ou effectuer une recherche dans un ensemble spécifique au processus de répertoires.
Le processus appelant peut utiliser le handle retourné par
Pour activer ou désactiver les messages d’erreur affichés par le chargeur pendant les chargements dll, utilisez la fonction SetErrorMode.
Il n’est pas sûr d’appeler LoadLibraryEx à partir de DllMain. Pour plus d’informations, consultez la section Remarques dans DllMain.
Visual C++ : Le compilateur Visual C++ prend en charge une syntaxe qui vous permet de déclarer des variables locales de thread : _declspec(thread). Si vous utilisez cette syntaxe dans une DLL, vous ne pourrez pas charger la DLL explicitement à l’aide de LoadLibraryEx sur les versions de Windows antérieures à Windows Vista. Si votre DLL est chargée explicitement, vous devez utiliser les fonctions de stockage local de thread au lieu de _declspec(thread). Pour obtenir un exemple, consultez Utilisation du stockage local thread dans une bibliothèque de liens dynamiques.
Chargement d’une DLL en tant que ressource de fichier de données ou d’image
Les valeurs LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVEet LOAD_LIBRARY_AS_IMAGE_RESOURCE affectent le nombre de références par processus et le chargement du module spécifié. Si l’une de ces valeurs est spécifiée pour le paramètre dwFlags, le chargeur vérifie si le module a déjà été chargé par le processus en tant que DLL exécutable. Dans ce cas, cela signifie que le module est déjà mappé dans l’espace d’adressage virtuel du processus appelant. Dans ce cas, LoadLibraryEx retourne un handle à la DLL et incrémente le nombre de références DLL. Si le module DLL n’a pas déjà été chargé en tant que DLL, le système mappe le module en tant que fichier de données ou image et non en tant que DLL exécutable. Dans ce cas, LoadLibraryEx retourne un handle au fichier de données ou d’images chargé, mais n’incrémente pas le nombre de références pour le module et ne rend pas le module visible par les fonctions telles que CreateToolhelp32Snapshot ou EnumProcessModules.Si LoadLibraryEx est appelé deux fois pour le même fichier avec LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVEou LOAD_LIBRARY_AS_IMAGE_RESOURCE, deux mappages distincts sont créés pour le fichier.
Lorsque la valeur LOAD_LIBRARY_AS_IMAGE_RESOURCE est utilisée, le module est chargé en tant qu’image à l’aide de l’extension d’alignement de section exécutable portable (PE). Les adresses virtuelles relatives (RVA) n’ont pas besoin d’être mappées aux adresses de disque. Les ressources peuvent donc être récupérées plus rapidement à partir du module. La spécification de LOAD_LIBRARY_AS_IMAGE_RESOURCE empêche d’autres processus de modifier le module pendant son chargement.
Sauf si une application dépend des caractéristiques de mappage d’images spécifiques, la valeur LOAD_LIBRARY_AS_IMAGE_RESOURCE doit être utilisée avec LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE ou LOAD_LIBRARY_AS_DATAFILE. Cela permet au chargeur de choisir s’il faut charger le module en tant que ressource d’image ou fichier de données, en sélectionnant l’option qui permet au système de partager des pages plus efficacement. Les fonctions de ressources telles que FindResource peuvent utiliser l’un ou l’autre mappage.
Pour déterminer comment un module a été chargé, utilisez l’une des macros suivantes pour tester le handle retourné par LoadLibraryEx.
#define LDR_IS_DATAFILE(handle) (((ULONG_PTR)(handle)) & (ULONG_PTR)1)
#define LDR_IS_IMAGEMAPPING(handle) (((ULONG_PTR)(handle)) & (ULONG_PTR)2)
#define LDR_IS_RESOURCE(handle) (LDR_IS_IMAGEMAPPING(handle) || LDR_IS_DATAFILE(handle))
Le tableau suivant décrit ces macros.
| Macro | Description |
|---|---|
| LDR_IS_DATAFILE(handle) | Si cette macro retourne TRUE, le module a été chargé en tant que fichier de données (LOAD_LIBRARY_AS_DATAFILE ou LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE). |
| LDR_IS_IMAGEMAPPING(handle) | Si cette macro retourne TRUE, le module a été chargé en tant que fichier image (LOAD_LIBRARY_AS_IMAGE_RESOURCE). |
| LDR_IS_RESOURCE( handlehandle) | Si cette macro retourne TRUE, le module a été chargé en tant que fichier de données ou fichier image. |
Utilisez la fonction FreeLibrary pour libérer un module chargé, qu’il soit ou non chargé, ce qui a entraîné l’incrémentation de son nombre de références. Si le module a été chargé en tant que fichier de données ou image, le mappage est détruit, mais le nombre de références n’est pas décrémenté. Sinon, le nombre de références DLL est décrémenté. Par conséquent, il est sûr d’appeler FreeLibrary avec n’importe quel handle retourné par LoadLibraryEx.
recherche de DLL et de dépendances
Le chemin de recherche est l’ensemble de répertoires qui sont recherchés pour une DLL. La fonctionLa fonction LoadLibraryEx utilise le chemin de recherche standard dans les cas suivants :
- Le nom de fichier est spécifié sans chemin d’accès et le nom du fichier de base ne correspond pas au nom de fichier de base d’un module chargé, et aucun des indicateurs de LOAD_LIBRARY_SEARCH n’est utilisé.
- Un chemin d’accès est spécifié, mais LOAD_WITH_ALTERED_SEARCH_PATH n’est pas utilisé.
- L’application n’a pas spécifié de chemin de recherche DLL par défaut pour le processus à l’aide de SetDefaultDllDirectories.
Si lpFileName spécifie un chemin relatif, le chemin d’accès relatif entier est ajouté à chaque jeton du chemin de recherche DLL. Pour charger un module à partir d’un chemin relatif sans rechercher d’autre chemin, utilisez GetFullPathName pour obtenir un chemin d’accès non rérelatif et appeler LoadLibraryEx avec le chemin d’accès nonrelatif. Si le module est chargé en tant que fichier de données et que le chemin d’accès relatif commence par « ». ou « ». », le chemin relatif est traité comme un chemin absolu.
Si lpFileName spécifie un chemin absolu et dwFlags est défini sur LOAD_WITH_ALTERED_SEARCH_PATH, LoadLibraryEx utilise le chemin de recherche modifié. Le comportement n’est pas défini lorsque LOAD_WITH_ALTERED_SEARCH_PATH indicateur est défini et lpFileName spécifie un chemin relatif.
La fonction SetDllDirectory peut être utilisée pour modifier le chemin de recherche. Cette solution est préférable à l’utilisation de SetCurrentDirectory ou de coder en dur le chemin complet de la DLL. Toutefois, n’oubliez pas que l’utilisation de SetDllDirectory désactive efficacement le mode de recherche DLL sans échec alors que le répertoire spécifié se trouve dans le chemin de recherche et qu’il n’est pas thread sécurisé. Si possible, il est préférable d’utiliser AddDllDirectory pour modifier un chemin de recherche de processus par défaut. Pour plus d’informations, consultez Dynamic-Link ordre de recherche de bibliothèque.
Une application peut spécifier les répertoires à rechercher un seul appel LoadLibraryEx à l’aide des indicateurs LOAD_LIBRARY_SEARCH_*. Si plusieurs LOAD_LIBRARY_SEARCH indicateur sont spécifiés, les répertoires sont recherchés dans l’ordre suivant :
- Répertoire qui contient la DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). Ce répertoire est recherché uniquement pour les dépendances de la DLL à charger.
- Répertoire de l’application (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
- Chemins d’accès explicitement ajoutés au chemin de recherche d’application avec la fonction AddDllDirectory (LOAD_LIBRARY_SEARCH_USER_DIRS) ou la fonction SetDllDirectory. Si plusieurs chemins d’accès ont été ajoutés, l’ordre dans lequel les chemins d’accès sont recherchés n’est pas spécifié.
- Répertoire System32 (LOAD_LIBRARY_SEARCH_SYSTEM32).
Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : les indicateurs de LOAD_LIBRARY_SEARCH_ sont disponibles sur les systèmes qui ont KB2533623 installés. Pour déterminer si les indicateurs sont disponibles, utilisez GetProcAddress pour obtenir l’adresse du AddDllDirectory, RemoveDllDirectoryou Fonction SetDefaultDllDirectories. Si GetProcAddress réussit, les indicateurs de LOAD_LIBRARY_SEARCH_ peuvent être utilisés avec LoadLibraryEx.
Si l’application a utilisé la fonction SetDefaultDllDirectories pour établir un chemin de recherche DLL pour le processus et aucun des indicateurs LOAD_LIBRARY_SEARCH_* n’est utilisé, la fonction LoadLibraryEx utilise le chemin de recherche DLL de processus au lieu du chemin de recherche standard.
Si un chemin d’accès est spécifié et qu’il existe un fichier de redirection associé à l’application, la fonction LoadLibraryEx recherche le module dans le répertoire de l’application. Si le module existe dans le répertoire de l’application, LoadLibraryEx ignore la spécification du chemin d’accès et charge le module à partir du répertoire de l’application. Si le module n’existe pas dans le répertoire de l’application, la fonction charge le module à partir du répertoire spécifié. Pour plus d’informations, consultez redirection de bibliothèque de liens dynamiques.
Si vous appelez LoadLibraryEx avec le nom d’un assembly sans spécification de chemin d’accès et que l’assembly est répertorié dans le manifeste compatible système, l’appel est automatiquement redirigé vers l’assembly côte à côte.
Remarques sur la sécurité
LOAD_LIBRARY_AS_DATAFILE n’empêche pas d’autres processus de modifier le module pendant son chargement. Comme cela peut rendre votre application moins sécurisée, vous devez utiliser LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE au lieu de LOAD_LIBRARY_AS_DATAFILE lors du chargement d’un module en tant que fichier de données, sauf si vous devez utiliser spécifiquement LOAD_LIBRARY_AS_DATAFILE. Spécifier LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE empêche d’autres processus de modifier le module pendant son chargement. Ne spécifiez pas LOAD_LIBRARY_AS_DATAFILE et LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE dans le même appel.N’utilisez pas la fonction SearchPath pour récupérer un chemin d’accès à une DLL pour un appel LoadLibraryEx ultérieur. La fonction SearchPath utilise un ordre de recherche différent de LoadLibraryEx et n’utilise pas le mode de recherche de processus sans échec, sauf si cela est explicitement activé en appelant SetSearchPathMode avec BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Par conséquent, SearchPath est susceptible d’effectuer une recherche dans le répertoire de travail actuel de l’utilisateur pour la DLL spécifiée. Si un attaquant a copié une version malveillante d’une DLL dans le répertoire de travail actuel, le chemin récupéré par SearchPath pointe vers la DLL malveillante, qui LoadLibraryEx chargera ensuite.
N’effectuez pas d’hypothèses sur la version du système d’exploitation en fonction d’une LoadLibraryEx appel qui recherche une DLL. Si l’application s’exécute dans un environnement où la DLL n’est légitimement pas présente, mais qu’une version malveillante de la DLL se trouve dans le chemin de recherche, la version malveillante de la DLL peut être chargée. Utilisez plutôt les techniques recommandées décrites dans Obtention de la version système.
Pour obtenir une discussion générale sur les problèmes de sécurité DLL, consultez Dynamic-Linkde sécurité de bibliothèque .
Exemples
L’exemple de code suivant illustre un appel à LoadLibraryExA.
//Load the FMAPI DLL
hLib = ::LoadLibraryEx(L"fmapi.dll", NULL, NULL);
if ( !hLib )
{
wprintf(L"Could not load fmapi.dll, Error #%d.\n", GetLastError());
return;
}
Pour obtenir un exemple supplémentaire, consultez Recherche de texte pour obtenir des numéros de code d’erreur.
Note
L’en-tête libloaderapi.h définit LoadLibraryEx 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
Dynamic-Link ordre de recherche de bibliothèque
Dynamic-Link de sécurité de bibliothèque
Run-Time de liaison dynamique
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour