How to recognize that runtime-loaded *.dll uses Qt?
I have such scenario: Application loads 3rd-party dll using LoadLibrary (winapi). Problem is that Application uses different version of Qt than dll does, which causes instability problems. Is there any simple way to check that dll uses Qt?
I could try to use pedump stuff to check what is inside dll, but it seems to be somewhat complex and I don’t know what to check to be sure that it becomes from Qt. Moreover, probably I should do this in separated process if I want to prevent loading such dll into Application memory space. Any other ideas?
In Win API, there are possibilities, to scan the binary file for it’s file dependencies. If there, some Qt libraries are found, you have a dependency :-)
But scanning a windows binary for dependencies is tricky:
the genral procedure is:
- map the dll into your memory as memory mapped file (read only)
- At the beginning of the file, something called the PIMAGE_DOS_HEADER is loacated
- You then have to extract the PIMAGE_NT_HEADER
- From that you can get the PIMAGE_IMPORT_DESCRIPTOR
- This one contains the names of the libraries to load
Sounds easy, but has some tricky stuff like offset calculation, pointeraritmethik etc needed.
If you need mor infor about that, use google with some of thees names, you will find some results.
Well, as I wrote, pedump stuff :-) Question is if it works for statically linked Qt? Moreover someone could change Qt binary name (I noticed this few times), so I would rather need for example a particular Qt function signature which exists inside all Qt binaries. Other thing is that such dll could need Qt indirectly, so probably I need to analyse all dependencies.
if Qt is linked statically, you will have problems, as you typically only find exported functions in the dll.
If it links dynamically, you can just check recursivly all loaded dlls.
If the Qt libraries are renamed, it’s getting interesting. You could check all dlls for some of the C-exported functions of QtCore…
It seems that I cannot check such dll. This way the only thing I can do is to load it in separated process, it would solve problem with different Qt versions. if Qt is linked statically, you will have problems, as you typically only find exported functions in the dll.
I’m wondering if QtCore signatures would be enough. Is there possibility to use other Qt binaries without linking with QtCore? If the Qt libraries are renamed, it’s getting interesting. You could check all dlls for some of the C-exported functions of QtCore…
AFAIK, all modules use stuff from QtCore, if they really link against it? never tried.
The usage of different QtVersion inside one process is impossible, unless you rename one of the versions. If you have multiple version, and they are only used by dlls, you have the same problem, as the versioj is searched by the path environment variable. Even if yozu call it from a different process, on windows you have no chance to check, which version the dll was linked against.
But if all are using default builds and the same compiler version, it is safe to just use the newest one.