Loading function from a DLL

[Suji]

Hi again @kshegunov

OK, I'll try this. When you talk about "the headers", which are they ?

The X.dll is a DLL built in VS2013 by a company, they gave me a device + example code and the dll. I'm trying to import the device's functions from this dll in my own soft, in order to pilot the device through their functions. I'm building my own soft because I want to master all which is inside the software, and for more clarity because I'm a rookie. ;)

I did the .lib and .def from the dll like this :
http://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll

(sorry for the long link! But bold, link buttons etc... doesnt work)

Thanks for your help and your patience.

edit : I have the header you're talking about, didn't know I had to bring it with the dll. Should I include the X.h into my MainWindows.cpp so ? I though all definitions etc was included in the .lib or .dll...

[kshegunov]

@Suji
Okay, so provided you have the header(s), the lib and the dll you put the lib and dll where your application is residing (usually the build folder when developing). Then you #include the header(s) where you want to use the functions that come from the dynamic library and finally you add the linker flags to your .pro file telling what library/ies have to be linked and where to search for the header(s) you're using. After all that you're ready to build your application.

More concretely:

1. Suppose your project is in C:/myproject and the application is built in C:/myproject/bin-debug
2. Let's say the library is called libExternalLibrary.dll with corresponding .lib file libExternalLibrary.lib and you have a header that's in C:/external_library/external_library.h.
3. You copy libExternalLibrary.dll and libExternalLibrary.lib in C:/myproject/bin-debug
4. You open your project file (the one that has a .pro extension) that is inside C:/myproject and add the following to it:

INCLUDEPATH += C:/external_library
LIBS += -L. -lExternalLibrary

5. In your code, where you want to use the library functions you include the header (at the top):

#include <external_library.h>

And then you can use the functions that are declared in that header (and defined in the dynamic library).

I hope this helps.
Kind regards.

[Suji]

So fine ! Thanks a lot @kshegunov ! Your answers are so so clear, I love it!

I want to ask you something : why I have to do this instead of simply add in my MainWindow.h the prototype of my function which is on my X.h ?

//MainWindow.cpp

#include <MainWindow.h>
#include <X.h>
Q_DECLARE_METATYPE(QCameraInfo)

QLibrary myLib("path\\to\\X.dll");

ParametersDialog::ParametersDialog()
{...}

void MainWindow::activateSetAutoWhiteBalance()
{
   MyPrototype funcSetAutoWhiteBalance = (MyPrototype) myLib.resolve("X_SetAutoWhiteBalance");
    if (funcSetAutoWhiteBalance)
       funcSetAutoWhiteBalance(TRUE);
}

//MainWindow.h

#include <QLibrary>

class MainWindow: public QMainWindow
{
    Q_OBJECT

public:
    MainWindow();
    ~MainWindow();

public slots:
    void activateSetAutoWhiteBalance();

(The activateSetAutoWhiteBalance function is connected to a QcheckBox)

//X.h
#include <windows.h>

typedef BOOL (*MyPrototype) (bool );

I really don't understand why using the .dll, .lib etc... Is there something more special inside the dll I dont understand ?

[kshegunov]

Hello,
Firstly, the resolve method has some limitations as noted in the documentation. Secondly, including the vendor header will ensure function prototypes match, which is important! And lastly, this line:

#include <windows.h>

is windows specific, meaning that if the vendor library actually has different variants for different OS-es your header will not work on anything but windows. Now, I want to make a step back and elaborate on the second point.

Consider that in the library someone has put a function like this:

extern "C" __declspec(dllexport) void someFunction(int);

if you declare that in your own header as this:

void someFunction(int, char);

and then make the QLibrary::resolve call (which will succeed!), you're in a big trouble. Calling that function as:

someFunction(0, 10);

will cause all kinds of weird and unexpected behavior (crashes included). So even if you're loading the library at runtime, use the vendor's header(s)!

ADDENDUM:
Sorry for the edits, it's been years since I've actually developed on windows.

Kind regards.

[Suji]

Hi again @kshegunov !

Another very clear answer. I appreciate it so much ! If only I could have a programing teacher like you... :)

Thanks a lot for all the time you took for me, and your patience.

Have a very nice day !

[kshegunov]

@Suji
You flatter me sir, thank you! I try, although not always succeed. :)

[Ni.Sumi]

hi @kshegunov & @Suji ,

I have question , hopefully a valid question :)

@Suji Said: The X.dll is a DLL built in VS2013 by a company,

@kshegunov If @Suji is working with Qt Creator , then the .dll built by VS 2013 will work inside the program built by Qt Creator?

I am sorry, if it is not related question here.

[kshegunov]

@Ni.Sumi
Hello,

I have question , hopefully a valid question

It is a valid question. It will work no matter the compiler used for building the external library. This is because he's resolving the symbols at runtime (and they are exported as C-linkage, meaning no symbol decorations). C-linkage functions symbol names have the the same structure on any compiler (at least they're supposed to), so he could as well be linking it and it shouldn't cause a problem.
So when QLibrary::resolve is called, an address (hopefully) is found in the library that correspond to the name provided as a parameter to the function, and this address is manually cast to a function pointer type. This is the scary part, because any misstep with the casting is (usually) fatal for the program. Then, when invoking the resolved function, you do that through the pointer.
Basically, what you do, is what the loader of the corresponding OS would have done - load the binary in memory and map the symbols (thus getting an address).

Kind regards.

[Ni.Sumi]

@kshegunov Okay. I understand it. Thanks for the time and explanation.

[kshegunov]

@Ni.Sumi
It's no hassle at all. I've corrected a grammar mistake in the post, but the meaning should remain the same. :)

Kind regards.