4

I am attempting to delay load wintrust.dll and crypt32.dll in my application (these are used to perform digital signature/publisher checks in a DLL). I am using VS2008. After adding these two DLLs as entries in the Delay Load property in the Linker section of my project properties, I still get LNK4199 warnings that nothing was loaded from the DLL and LNK2019 errors unable to resolve symbols such as WinVerifyTrust.

Adding the following as entries to Additional Dependencies alleviates this problem: crypt32.lib and wintrust.lib. I now get no issues with linking. However, what I am wondering is how do I make sure this isn't being linked to the static lib? I do not want to link to the static lib because of potential licensing issues. I want to dynamically load the DLLs that are installed in Windows, and was hoping DelayLoad could help me do this without having to resort to LoadLibrary and GetProcAddress function calls.

Any information about all the different library usage/linking options would be greatly appreciated!

Thanks.

sohum
  • 3,207
  • 2
  • 39
  • 63

4 Answers4

4

Delay loading doesn't free you from having to link to the lib file. Normally, DLLs are loaded as soon as your application starts. Delay loading just delays this until the first time you call a function from that DLL. Either way, you need to link to the lib file so that the linker can verify that the functions you are calling are actually present in the DLL.

If you don't want to link to the lib files, your only way out is to use LoadLibrary and GetProcAddress.

casablanca
  • 69,683
  • 7
  • 133
  • 150
3

There is no static .lib for these. The SDK libraries are always import libraries, not static .libs because the corresponding Windows API lives in a DLL. No need to worry about this.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

One tool that can help you determine if things are being linked as you expect is DependecyWalker: http://www.dependencywalker.com/ - specifically, in the case of delay-loads it marks them with a special symbol.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
0

You may want to look at the Win32 API methods LoadLibrary and GetProcAddress.

Joshua Rodgers
  • 5,317
  • 2
  • 31
  • 29
  • I don't follow... I already mentioned that I'd like to do this without having to use LoadLibrary and GetProcAddress by using DelayLoad to load the DLL. – sohum Oct 14 '10 at 18:54
  • It's the only way I'm aware of being able to load a DLL at run-time without having to link to some library defining the symbols. – Joshua Rodgers Oct 14 '10 at 18:56
  • 1
    I guess my bigger question is that it inherently seems that I'm linking to that library statically when doing this. Is this not the case? – sohum Oct 14 '10 at 18:57
  • The .lib file for a DLL really only specifies the addresses and symbol names in the DLL so the linker can resolve the symbols in code. – Joshua Rodgers Oct 14 '10 at 19:00
  • Practically, Joshua is right that static import .lib files seem to be just addresses and symbol names. But from the perspective of the LGPL it's not clear whether or not implicit linking using a static import library still qualifies as "dynamic linking" or if `LoadLibrary` explicit linking is the only legal way to do dynamic linking with LGPL components on Visual Studio without having to release all object files. The LGPL seems to have been written with GCC in mind, and GCC can link directly to .so and (MinGW) .dll files without involving a .lib file. – jrh Mar 29 '21 at 15:12