Funzione LoadLibraryExA (libloaderapi.h)

Il processo chiamante può usare l'handle restituito da LoadLibraryEx per identificare il modulo nelle chiamate al GetProcAddress, FindResourcee funzioni di LoadResource.

Per abilitare o disabilitare i messaggi di errore visualizzati dal caricatore durante il caricamento della DLL, usare la funzione SetErrorMode .

Non è possibile chiamare LoadLibraryEx da DllMain. Per altre informazioni, vedere la sezione Osservazioni in DllMain.

Visual C++: Il compilatore Visual C++ supporta una sintassi che consente di dichiarare variabili locali del thread: _declspec(thread). Se si usa questa sintassi in una DLL, non sarà possibile caricare la DLL in modo esplicito usando LoadLibraryEx nelle versioni di Windows precedenti a Windows Vista. Se la DLL verrà caricata in modo esplicito, è necessario usare le funzioni di archiviazione locale del thread anziché _declspec(thread). Per un esempio, vedere Using Thread Local Storage in a Dynamic Link Library.

Caricamento di una DLL come file di dati o risorsa immagine

Se LoadLibraryEx viene chiamato due volte per lo stesso file con LOAD_LIBRARY_AS_DATAFILE, LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVEo LOAD_LIBRARY_AS_IMAGE_RESOURCE, vengono creati due mapping separati per il file.

Quando si usa il valore LOAD_LIBRARY_AS_IMAGE_RESOURCE, il modulo viene caricato come immagine usando l'espansione dell'allineamento della sezione PE (Portable Executable). Gli indirizzi virtuali relativi non devono essere mappati agli indirizzi del disco, quindi le risorse possono essere recuperate più rapidamente dal modulo. Se si specifica LOAD_LIBRARY_AS_IMAGE_RESOURCE si impedisce ad altri processi di modificare il modulo durante il caricamento.

A meno che un'applicazione non dipenda da caratteristiche specifiche del mapping delle immagini, il valore di LOAD_LIBRARY_AS_IMAGE_RESOURCE deve essere usato con LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE o LOAD_LIBRARY_AS_DATAFILE. In questo modo il caricatore può scegliere se caricare il modulo come risorsa immagine o un file di dati, selezionando quale opzione consente al sistema di condividere le pagine in modo più efficace. Le funzioni delle risorse, ad esempio FindResource possono usare entrambi i mapping.

Per determinare come è stato caricato un modulo, usare una delle macro seguenti per testare l'handle restituito da 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))

Nella tabella seguente vengono descritte queste macro.

Usare la funzione FreeLibrary per liberare un modulo caricato, indipendentemente dal fatto che il caricamento del modulo abbia causato l'incremento del conteggio dei riferimenti. Se il modulo è stato caricato come file di dati o immagine, il mapping viene eliminato definitivamente, ma il conteggio dei riferimenti non viene decrementato. In caso contrario, il conteggio dei riferimenti dll viene decrementato. Pertanto, è possibile chiamare FreeLibrary con qualsiasi handle restituito da LoadLibraryEx.

ricerca di DLL e dipendenze

La funzione LoadLibraryEx usa il percorso di ricerca standard nei casi seguenti:

• Il nome file viene specificato senza un percorso e il nome del file di base non corrisponde al nome del file di base di un modulo caricato e nessuno dei flag LOAD_LIBRARY_SEARCH viene usato.
• Viene specificato un percorso, ma non viene utilizzato LOAD_WITH_ALTERED_SEARCH_PATH.
• L'applicazione non ha specificato un percorso di ricerca DLL predefinito per il processo usando SetDefaultDllDirectories.

Se lpFileName specifica un percorso relativo, l'intero percorso relativo viene aggiunto a ogni token nel percorso di ricerca della DLL. Per caricare un modulo da un percorso relativo senza cercare altri percorsi, usare GetFullPathName per ottenere un percorso nonrelative e chiamare LoadLibraryEx con il percorso nonrelative. Se il modulo viene caricato come file di dati e il percorso relativo inizia con "." o "..", il percorso relativo viene considerato come percorso assoluto.

Se lpFileName specifica un percorso assoluto e dwFlags è impostato su LOAD_WITH_ALTERED_SEARCH_PATH, LoadLibraryEx usa il percorso di ricerca modificato. Il comportamento non è definito quando viene impostato LOAD_WITH_ALTERED_SEARCH_PATH flag e lpFileName specifica un percorso relativo.

La funzione SetDllDirectory può essere usata per modificare il percorso di ricerca. Questa soluzione è preferibile rispetto all'uso di SetCurrentDirectory o impostare come hardcoded il percorso completo della DLL. Tenere tuttavia presente che l'uso di SetDllDirectory disabilita in modo efficace la modalità di ricerca DLL sicura mentre la directory specificata si trova nel percorso di ricerca e non è thread-safe. Se possibile, è consigliabile usare AddDllDirectory per modificare un percorso di ricerca di processo predefinito. Per altre informazioni, vedere Dynamic-Link Library Search Order.

Un'applicazione può specificare le directory in cui cercare una singola chiamata LoadLibraryEx usando i flag LOAD_LIBRARY_SEARCH_*. Se si specificano più LOAD_LIBRARY_SEARCH flag, le directory vengono cercate nell'ordine seguente:

• Directory contenente la DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). Questa directory viene cercata solo per le dipendenze della DLL da caricare.
• Directory dell'applicazione (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
• I percorsi aggiunti in modo esplicito al percorso di ricerca dell'applicazione con la funzione AddDllDirectory (LOAD_LIBRARY_SEARCH_USER_DIRS) o la funzione SetDllDirectory. Se sono stati aggiunti più percorsi, l'ordine in cui vengono cercati i percorsi non è specificato.
• Directory System32 (LOAD_LIBRARY_SEARCH_SYSTEM32).

Windows 7, Windows Server 2008 R2, Windows Vista e Windows Server 2008: I flag LOAD_LIBRARY_SEARCH_ sono disponibili nei sistemi in cui è installato KB2533623. Per determinare se i flag sono disponibili, usare GetProcAddress per ottenere l'indirizzo della AddDllDirectory, RemoveDllDirectoryo funzione SetDefaultDllDirectories. Se GetProcAddress ha esito positivo, i flag di LOAD_LIBRARY_SEARCH_ possono essere usati con LoadLibraryEx.

Se l'applicazione ha usato la funzione SetDefaultDllDirectories per stabilire un percorso di ricerca DLL per il processo e nessuno dei flag LOAD_LIBRARY_SEARCH_* vengono usati, la funzione LoadLibraryEx usa il percorso di ricerca DLL del processo anziché il percorso di ricerca standard.

Se viene specificato un percorso e all'applicazione è associato un file di reindirizzamento, la funzione LoadLibraryEx cerca il modulo nella directory dell'applicazione. Se il modulo esiste nella directory dell'applicazione, LoadLibraryEx ignora la specifica del percorso e carica il modulo dalla directory dell'applicazione. Se il modulo non esiste nella directory dell'applicazione, la funzione carica il modulo dalla directory specificata. Per altre informazioni, vedere reindirizzamento della libreria a collegamento dinamico.

Se si chiama LoadLibraryEx con il nome di un assembly senza specifica del percorso e l'assembly è elencato nel manifesto compatibile con il sistema, la chiamata viene reindirizzata automaticamente all'assembly side-by-side.

osservazioni sulla sicurezza

Non usare la funzione SearchPath per recuperare un percorso di una DLL per una successiva chiamata LoadLibraryEx. La funzione SearchPath usa un ordine di ricerca diverso da LoadLibraryEx e non usa la modalità di ricerca sicura dei processi, a meno che non sia abilitata in modo esplicito chiamando SetSearchPathMode con BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Pertanto, è probabile che SearchPath cerchi prima nella directory di lavoro corrente dell'utente la DLL specificata. Se un utente malintenzionato ha copiato una versione dannosa di una DLL nella directory di lavoro corrente, il percorso recuperato da SearchPath punterà alla DLL dannosa, che LoadLibraryEx verrà quindi caricata.

Non fare ipotesi sulla versione del sistema operativo basata su un LoadLibraryEx chiamata che cerca una DLL. Se l'applicazione è in esecuzione in un ambiente in cui la DLL non è presente legittimamente, ma una versione dannosa della DLL si trova nel percorso di ricerca, è possibile caricare la versione dannosa della DLL. Usare invece le tecniche consigliate descritte in Recupero della versione di sistema.

Per una discussione generale sui problemi di sicurezza delle DLL, vedere Dynamic-Link Library Security.

Esempi

Nell'esempio di codice seguente viene illustrata una chiamata a 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;
}

Per un esempio aggiuntivo, vedere Ricerca di testo per i numeri di codice di errore.

Fabbisogno

Vedere anche

DllMain

Funzioni della libreria Dynamic-Link

ordine di ricerca della libreria Dynamic-Link

di sicurezza della libreria Dynamic-Link

FindResource

FreeLibrary

GetProcAddress

GetSystemDirectory

GetWindowsDirectory

loadLibrary

LoadResource

OpenFile

Run-Time collegamento dinamico

SearchPath

SetDllDirectory

SetErrorMode