10

I am in desperate need of help, I need to manage an application dependency in Visual Studio. The application links to a DLL only on a specific version of windows, lets say Windows 7. and on other environments, the DLL should not be loaded. How will I be able to achieve that using DLL Delay Loading as this topic is completely new to me and there isn't any good references online for this particular matter.

Regards

Zaid Amir
  • 4,355
  • 4
  • 42
  • 98

3 Answers3

11

Your project can specify that a dll it depends upon should but be loaded when needed, by specifying it in the Linker/Input/Delay Loaded DLLs field. This setting can be different for different build configurations.

xtofl
  • 38,207
  • 10
  • 95
  • 177
  • Thx for the reply man but can you giva an example or code snippet if its applicable :) – Zaid Amir Sep 07 '09 at 09:28
  • 5
    That's the point of delay loading: it's a configuration thing, not a code thing. – xtofl Sep 07 '09 at 09:29
  • The wording appears wrong: When you say "The DLL you're depending upon should have been linked with the delay-load capacity", you're seem to be referring to the creation of that DLL from its constituent .obj's. The /DELAY flag is actually applied to the module that does the _importing_, not the _imported_ module. That's also the reason that you can delay-load Windows 2000 DLLs, which would have been built without this support. – MSalters Sep 07 '09 at 10:06
  • @MSalters: You're right: the first option is for the dll to support _unloading_. Corrected for that, thanks. – xtofl Sep 07 '09 at 11:04
11

MSDN has a pretty good description here.

Basically what you are doing is setting the DLL in question to be in the delay load section. It will then not load that DLL until you make a call to a function that is in that DLL.

From the above link:

The Visual C++ linker now supports the delayed loading of DLLs. This relieves you of the need to use the Windows SDK functions LoadLibrary and GetProcAddress to implement DLL delayed loading.

Before Visual C++ 6.0, the only way to load a DLL at run time was by using LoadLibrary and GetProcAddress; the operating system would load the DLL when the executable or DLL using it was loaded.

Beginning with Visual C++ 6.0, when statically linking with a DLL, the linker provides options to delay load the DLL until the program calls a function in that DLL.

An application can delay load a DLL using the /DELAYLOAD (Delay Load Import) linker option with a helper function (default implementation provided by Visual C++). The helper function will load the DLL at run time by calling LoadLibrary and GetProcAddress for you.

You should consider delay loading a DLL if:

Your program may not call a function in the DLL.

A function in the DLL may not get called until late in your program's execution.

The delayed loading of a DLL can be specified during the build of either a .EXE or .DLL project. A .DLL project that delays the loading of one or more DLLs should not itself call a delay-loaded entry point in Dllmain.

Community
  • 1
  • 1
Goz
  • 58,120
  • 22
  • 114
  • 192
2

Instead of using delay loading, have you considered using dynamic loading with LoadLibrary and GetProcAddress? This is likely to be simpler to use.

typedef void (WINAPI *PGNSI)(LPSYSTEM_INFO);

// Call GetNativeSystemInfo if supported or GetSystemInfo otherwise.

PGNSI pGNSI;
SYSTEM_INFO si;

ZeroMemory(&si, sizeof(SYSTEM_INFO));

pGNSI = (PGNSI) GetProcAddress(
   GetModuleHandle(TEXT("kernel32.dll")), 
   "GetNativeSystemInfo");
if(NULL != pGNSI)
   pGNSI(&si);
else GetSystemInfo(&si);
1800 INFORMATION
  • 119,313
  • 29
  • 152
  • 234
  • 12
    How is it simpler to write code that can be automatically generated by the linker? – xtofl Sep 07 '09 at 09:31
  • 2
    its fine if you only have 1 function you wish to call ... otherwise its a plain bad choice, imo. – Goz Sep 07 '09 at 09:35
  • 4
    -1 - the support for delay loading in the linker is specifically aimed at preventing you having to deal LoadLibrary() and GetProcAddress()! – Bids Oct 29 '10 at 10:46
  • 4
    In the case of this question, (we assume) he knows that the DLL will be available on Windows 7 so he can detect the OS version before invoking a function call to the delayloaded DLL. However, it is sometimes the case that you can't know if a DLL is available on a system or what version (and thus what exported functions) are available. In those cases, using run-time dynamic linking is the appropriate albeit tedious solution. If you don't have some manner of detecting the presence of the DLL and required exported functions with 100% certainty, then delay loading may just be delay crashing. – Zach Burlingame Sep 09 '11 at 23:07
  • I second xtofl and Bids. So much more work to use runtime loading. – xiay Oct 01 '17 at 01:18