I have a DLL(1) that uses another DLL(2).
My Problem is that the DLL(2) has far to many exports to link dynamically
DLL(1) does a check by LoadLibrary to see if DLL(2) exists.
Because the DLL(2) is in the import list of DLL(1). DLL(1) won't load if DLL(2) is not there.
So my question is, Is it possible to write a PE Loader for a DLL or EXE that will load the file regardless.
Then within the code check by using LoadLibrary to see if the DLL exists do use any of the functions.
My Problem is that the DLL(2) has far to many exports to link dynamically
DLL(1) does a check by LoadLibrary to see if DLL(2) exists.
Because the DLL(2) is in the import list of DLL(1). DLL(1) won't load if DLL(2) is not there.
So my question is, Is it possible to write a PE Loader for a DLL or EXE that will load the file regardless.
Then within the code check by using LoadLibrary to see if the DLL exists do use any of the functions.
I think /DELAYLOAD linker option could be of some help here.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/vcrefdelayload(delayloadimport).asp
http://www.microsoft.com/msj/1298/hood/hood1298.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/vcrefdelayload(delayloadimport).asp
http://www.microsoft.com/msj/1298/hood/hood1298.aspx
yep, delayload is probably a good way to go...
I have a question, though - is it possible to manually catch DelayLoad errors (DLL couldn't load, missing export, whatever), and handle it gracefully in your app... or are you stuck with the hard windows termination of the app? I think I heard some whispers that SEH can be used for this, but I haven't messed much with delay-load.
I have a question, though - is it possible to manually catch DelayLoad errors (DLL couldn't load, missing export, whatever), and handle it gracefully in your app... or are you stuck with the hard windows termination of the app? I think I heard some whispers that SEH can be used for this, but I haven't messed much with delay-load.
That done the trick, Many thanks.
Pliers.
Is there a list of linker option anywhere ?
Pliers.
Is there a list of linker option anywhere ?
so what is the max number of exports that can be dynamically linked with out the delay option and with it..
so what is the max number of exports that can be dynamically linked with out the delay option and with it..
Unlimited?
I guess Pliers meant it would be painful to do GetProcAddress() on too many exports.
It seems that LoadLibrary uses TLS memory and can fail if filled beyound it limits... it is talked about in the MSDN 2003 .NET
Windows 2000 and later 1088 indexes per process
Windows 98/Me 80 indexes per process
Windows 95
Windows NT 4.0 and earlier 64 indexes per process
Windows 2000 and later 1088 indexes per process
Windows 98/Me 80 indexes per process
Windows 95
Windows NT 4.0 and earlier 64 indexes per process
Declare a global variable to contain the TLS index. For example:
static DWORD gdwTlsIndex;
Use the TlsAlloc function during initialization to allocate the TLS index. For example, include the following call in the DllMain function during DLL_PROCESS_ATTACH:
gdwTlsIndex = TlsAlloc();
For each thread using the TLS index, allocate memory for the data, then use the TlsSetValue function to store the address of the memory block in the TLS slot associated with the index. For example, include the following code in your DllMain during DLL_THREAD_ATTACH:
LPVOID lpvBuffer;
lpvBuffer = (LPVOID) LocalAlloc(LPTR, 256);
TlsSetValue(gdwTlsIndex, lpvBuffer);
When a function requires access to the data associated with a TLS index, specify the index in a call to the TlsGetValue function. This retrieves the contents of the TLS slot for the calling thread, which in this case is a pointer to the memory block for the data. For example, include the following code in any of the functions in your DLL:
LPVOID lpvData;
lpvData = TlsGetValue(gdwTlsIndex);
When each thread no longer needs to use a TLS index, it must free the memory whose pointer is stored in the TLS slot. When all threads have finished using a TLS index, use the TlsFree function to free the index. For example, use the following code in your DllMain during DLL_THREAD_DETACH:
lpvBuffer = TlsGetValue(gdwTlsIndex);
LocalFree((HLOCAL) lpvBuffer);
and the following code during DLL_PROCESS_DETACH:
TlsFree(gdwTlsIndex);
It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. It is common for the entry-point function to create synchronization objects such as critical sections and mutexes, and use TLS. Do not call the registry functions, because they are located in Advapi32.dll. If you are dynamically linking with the C run-time library, do not call malloc; instead, call HeapAlloc.
static DWORD gdwTlsIndex;
Use the TlsAlloc function during initialization to allocate the TLS index. For example, include the following call in the DllMain function during DLL_PROCESS_ATTACH:
gdwTlsIndex = TlsAlloc();
For each thread using the TLS index, allocate memory for the data, then use the TlsSetValue function to store the address of the memory block in the TLS slot associated with the index. For example, include the following code in your DllMain during DLL_THREAD_ATTACH:
LPVOID lpvBuffer;
lpvBuffer = (LPVOID) LocalAlloc(LPTR, 256);
TlsSetValue(gdwTlsIndex, lpvBuffer);
When a function requires access to the data associated with a TLS index, specify the index in a call to the TlsGetValue function. This retrieves the contents of the TLS slot for the calling thread, which in this case is a pointer to the memory block for the data. For example, include the following code in any of the functions in your DLL:
LPVOID lpvData;
lpvData = TlsGetValue(gdwTlsIndex);
When each thread no longer needs to use a TLS index, it must free the memory whose pointer is stored in the TLS slot. When all threads have finished using a TLS index, use the TlsFree function to free the index. For example, use the following code in your DllMain during DLL_THREAD_DETACH:
lpvBuffer = TlsGetValue(gdwTlsIndex);
LocalFree((HLOCAL) lpvBuffer);
and the following code during DLL_PROCESS_DETACH:
TlsFree(gdwTlsIndex);
It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. It is common for the entry-point function to create synchronization objects such as critical sections and mutexes, and use TLS. Do not call the registry functions, because they are located in Advapi32.dll. If you are dynamically linking with the C run-time library, do not call malloc; instead, call HeapAlloc.