LoadLibrary et AfxLoadLibrary
Les processus appellent LoadLibrary (ou AfxLoadLibrary) pour une liaison explicite avec une DLL. Si l'appel réussit, la fonction mappe la DLL spécifiée à l'espace d'adressage du processus appelant et retourne un handle vers la DLL qui peut être utilisé avec d'autres fonctions pour une liaison explicite, par exemple GetProcAddress et FreeLibrary.
LoadLibrary tente de localiser la DLL à l'aide de la séquence de recherche utilisée pour la liaison implicite. Si le système ne trouve pas la DLL ou si la fonction de point d'entrée retourne FALSE, LoadLibrary retourne NULL. Si l'appel à LoadLibrary spécifie un module DLL déjà mappé à l'espace d'adressage du processus appelant, la fonction retourne un handle vers la DLL et incrémente le décompte de références du module.
Si la DLL a une fonction de point d'entrée, le système d'exploitation appelle la fonction dans le contexte du thread ayant appelé LoadLibrary. Il n'appelle pas la fonction de point d'entrée si la DLL est déjà liée au processus, suite à un appel antérieur à LoadLibrary sans appel correspondant à la fonction FreeLibrary.
Pour les applications MFC qui chargent des DLL d'extension, nous recommandons d'utiliser AfxLoadLibrary à la place de LoadLibrary. AfxLoadLibrary gère la synchronisation des threads avant l'appel de LoadLibrary. L'interface (prototype de fonction) de AfxLoadLibrary est identique à celle de LoadLibrary.
Si Windows ne peut pas charger la DLL, le processus peut tenter de récupérer à partir de l'erreur. Par exemple, il peut notifier l'erreur à l'utilisateur et lui demander de spécifier un autre chemin d'accès à la DLL.
.gif "Note de sécurité") Note de sécurité |
|---|
Si le code doit être exécuté sous Windows NT 4, Windows 2000 ou Windows XP, veillez à spécifier le chemin d'accès complet de toute DLL. Sur ces systèmes d'exploitation, la recherche porte d'abord sur le répertoire actif lors du chargement des fichiers. Si vous ne spécifiez pas le chemin d'accès au fichier, un fichier inapproprié risque d'être chargé. |