I have third party dlls that I need to use with my application. The interface is defined in the third party dlls and I have to make the interface call from my application. I have the function prototype of the interface, but no lib files or header files. It looks like loadlibrary should be used, but is it possible without the header files ? Is there a way to generate such header files? Would also greatly appreciate some explanation for the loadlibrary, as I am still grasping the idea yet.
Thanks!
You can use QLibrary::resolve() (or its static convenience brethren) to lookup a symbol in a DLL, and call it.
You load the library with the API function LoadLibrary. After loading the DLL you use GetProcAddress to get the entry point for a specific function.
If it's a C++ library, you may have to care for the decorated names. The tools dumpbin and undname may help to identify what is really exported by the DLL.
Related
I am making a win32 console app using msvc++ that is going to use a really simple dll. I put my .lib and header for my dll (my dll only has one header) into my console applications folder.
When I run it, I don't get any compile or linking errors, but when the app is actually open, it says it cant find the dll. When I put the .dll file into the console app's folder and run, it actually works. I would like to know why this happens??????
Look at this link:
Dynamic-Link Library Search Order
Windows has a DLL search order. You can change it by functions specified in the above link.
Your import library is used to define information about functions in your DLL and so. You can use LoadLibrary("myDLL.dll") function to load DLL without header.
In this case you must use GetProcAddress(module, "function_name") function to get function adresses in your DLL.
GetProcAddress function
and here is the link where is some solution for GetProcAddress():
Calling functions in a DLL from C++
I know it's impossible to reverse a dll into a c++ code so I would like to collect as much as possible details from it.
It's not my dll, so I don't have the source code of course. Which program should I use?
Well, if you are skilled you can disassemble the DLL and understand all of its functions. This takes a substantial amount of time, but if you do that you can reverse it back to source by hand.
Otherwise, you can start by using a tool like Dependency Walker to get the DLLs and functions it depends on, and the functions it exports. From there you can find functions that interest you, and use a disassembler like IDA to see what they do.
You can see the list of exported functions by using the dumpbin tool. If C++ functions are exported, you might be able to infer parameters by the name mangling.
You can extract all the resources from the DLL by just "opening" it as a file for resource viewing in Visual Studio. If the DLL is a COM based DLL, there's a small chance the Type Library is embedded as a resource inside it. And if you have the Type Library, you can #import it to reconstruct the header files for the public interfaces.
That's about as good as it gets.
You need a PE file viewer. This will tell you the exports from the DLL and you can get the data in the .text section to see the machine code.
I don't know how to do the following:
I'm using MS Visual C++ 6.0
I have a Win32 DLL project which is compilable.
I have another project, this time a Win32 Console project which uses
the DLL by including it's header file and linking the .lib file of
the DLL.
Now I want to have another project, similar to the second BUT without using the header file and the lib file.
Is that possible? Everywhere I read you need either dll+lib+h or dll+h. If thought if you know the interfaces, a DLL file is sufficient?
Btw, by "using a DLL" I mean, using the Classes and Functions defined in the DLL.
It is possible if you just have plain "extern C" functions. If this is the case the approach could be loading the dll with LoadLibrary, and then import each function with GetProcAddress, of course you need to know the function signature to create a properly declared function pointer. Using classes per contrary is almost impossible.
If your DLL contains classes, there are good chances that it is a COM component.
If this is the case, the #import directive (that you use like #include) builds some temporary include files containing the interface details. You should use COM to access your objects.
Otherwise, if you have a 'plain' DLL with C++ classes, you could access the exported symbols using linker: instruct it to dump the map (see here), to know the mangled names. But I don't think that's possible to build manually the interface...
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.
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.
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.
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.
You may want to look at the Win32 API methods LoadLibrary and GetProcAddress.
I know that if I have an .a or .so file and a header file for that library (for example for SystemC), I should
1. include header file
2. link the appropriate library.
But I can't handle with only .dll file as I can link it as well, but don't have a hearer file to include and to use commands. Con someone explain me what kind of .dll-s exist and how they are possible to use? Is it possible to use any .dll file or it should be a specific kind of .dll to be able to integrate to my application?
A DLL is functionally equivalent to a .so file (also know as a 'shared object' or 'shared library'). You need a header to declare the functions that are available inside the DLL and you need to link against a library which handles the business of loading and executing DLL calls (mostly delegated to the OS).
It is possible to use a DLL without any sort of header. You can directly call Win32 API's which will dynamically load a DLL into your programs virtual address space and call other API's which will give you what are essentially function pointers. However, you need to know the signatures of the function pointers to use the properly so what you're effectively doing in that case is declaring a tiny subsection of the actual DLL header for your use.
This wikipedia article may help, especially the section on shared libraries
Unlike Linux, Windows libraries are seperated into two forms: DLL (for runtime linking) and LIB for symbol declarations. link.exe (the windows linker) expects .lib files to resolve symbols being used by your program's headers during build time. More information here:
http://msdn.microsoft.com/en-us/library/ba1z7822(VS.71).aspx
Note that if you load a DLL compiled in C++, you hvae to avoid passing object pointers across the interface, as they are in general not portable. You have to keep to basic C calls and calling conventions, as that is what is defined by the Windows or Linux platform ABI.