Question about importing DLL functions in C++

[Ben Hutchinson]

In VB6 you would use a simple line like this at the top of your program's code to import a function stored in a DLL file:
Private Declare Function GetDC Lib "user32.dll" (ByVal hWnd As Long) As Long

How do I do it in VC++2010? I found that there's __declspec(dllimport) but that I looked at that command's syntax on MSDN, and it is missing one critical piece of information that the VB6 Delcare statement has, the name of the DLL file. Yes I can type the code
__declspec(dllimport) int GetDC(int hWnd);
but that line of code is missing the DLL filename which is supposed to be "user32.dll". And looking at the MSDN info for the __declspec(dllimport) syntax, nowhere does it show how to specify the DLL filename.

If anybody here has any idea how to do this, I'm eager to hear it. Does VC++2010 have an equivalent command to VB6's Declare statement?

[andywestken]

__declspec(dllimport) does just (need to) tell the compiler that this function is imported from some or other DLL, but not which one.

The linker, when it's creating the final binary, searches all the import libraries it's been told about for the entrypoint and will resolve the call against the first library which provides a matching function.

The "Additional Dependencies" field of the "Linker"/"General" page of you project's properties is where you list project specific dependencies. Or you can use a pragma in your code (e.g.)

#pragma comment(lib, "user32.lib") (This is Microsoft specific.)

The standard C++ and C libraries are handled automatically (by default -- you can disable this if you wsh.)

If you go to the linker options for your project's properties and set "Show Progress" to "Display all progress messages" on the "Linker"/"General" page then you can see this in action.

(Sometimes the linker selects the wrong DLL (etc), so this is a useful trick to know about for diagnosing link problems.)

Andy

[Ben Hutchinson]

Ok thanks, but is there a way to use a Pragma comment line to import a DLL file, rather than a LIB file? I have a DLL file that does not have its own LIB file. VB6 is fine with handling DLL files that have no associated LIB file. You just use the Declare statement with the associated DLL file. Is there something similar in VC++?

I would prefer to use a DLL rather than a LIB, because LIB files are statically linked (they copy their code directly into the EXE file, which removes the need for a DLL file dependancy). DLL files are much better for use as plugins (like for graphics processing) because you can make a basic product, without a bunch of extra code copied into the EXE file from a LIB file, and simply supply an external DLL file, which can be used as a plugin for processing data such as an audio file or image file. Then you can simply distribute the DLL files that are plugins, rather than building and distributing a new version of the EXE file every time you want to add a new feature.

[andywestken]

No need to sell DLLs to me -- I have worked extensively with them in assorted guises inc. NSAPI plugins, Microsoft Office Add-ins, and in-process COM servers!

is there a way to use a Pragma comment line to import a DLL file, rather than a LIB file?

No.

The Visual Studio C++ linker needs an import library to build your app if you want to use implicit dynamic linking (when the DLL is loaded automatically when the exe is launched) rather than explicit runtime dynamic linking (where you have to load using LoadLibrary() and resolve the function addresses with GetProcAddress().)

An import library contains just the information the linker need to resolve the entry points, not the complete implementation like a static library. So linking to it won't bulk out or otherwise "contaminate" your exe.

When you build a DLL with Visual Studio you should end up with a DLL plus it's import library. And if you obtain a DLL from a 3rd party for use with apps you build yourself you should also get the associated header file(s) and import library.

If you do not already have the required import library it is possible to create one:
How To Create 32-bit Import Libraries Without .OBJs or Source
https://support.microsoft.com/en-us/kb/131313
(the article is about 32-bit DLLs, but I don't see an obvious reason why the same approach couldn't be applied to 64-bit DLLs.)

Andy

PS I recently learnt that the MINGW version of the GCC linker can use a DLL (if the DLL in unstripped) to resolved entry points as link time. But it doesn't understand #pragma lib, so it's a moot point.