I am newbie in Qt, I have dll from 3rd party (NFC reader), this is C Win32 library (I don have header file, only dll file) so in C# i call it by using DLLImport Attribute. Now I want to using Qt to make the application and I don know how to do it. I hope somone will help me. Please explain clearly because I am very very fresh with Qt.
Thank you so much
Use QLibrary to load the library - it's a bit easier than using the native API (LoadLibrary etc.).
Use resolve("symbolname") on the QLibrary instance to get a pointer to a particular function. You then need to cast that pointer to the signature of the function you're actually going to call, and call via this cast pointer.
The documentation for your NPC Reader's DLL should describe the signatures of the functions, you needed that information for C# anyway.
Related
As we know, there are two methods of library loading.
1) Static libraries (.a): Library of object code which is linked with, and becomes part of the application.
2) Dynamically linked shared object libraries (.so), which will link at execution of application and it can be used in two ways.
a) Dynamically linked at run time but statically aware.
b) Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.
After compilation, we can check the library dependency of type 'a' as below
objdump -x usr/bin/flashcp
.....
Dynamic Section:
NEEDED libgcc_s.so.1
NEEDED libc.so.6
My question is how to check/detect type 'b' library dependency ? Please suggest is there any way to detect before execution ?
Thanks in advance
Thiru
There's no way to generally check for libraries that are loaded dynamically and whose functions are called via function pointers.
In some special cases, as a hack, you can attempt various ways of reverse-engineering the executable, e.g. statically analyzing code around the calls to LoadLibrary and GetProcAddress on Windows. You could derive some heuristics that would work on many executables, but there's no way that's guaranteed to work, other than executing the code in a virtual machine and intercepting all calls to LoadLibrary/dlopen as they happen.
I've developed a program and I am trying to make this program work with a controllable light source manufactured by some other company. I've emailed the company and they have agreed to send me their external library as a DLL.
I have developed all of my software using Qt 4.8.1 and it has been compiled using MSVC2008.
The controllable light's DLL was compiled in Visual Studio 2008 and was written in either C++ or C# (the manufacturer is uncertain). All I have been given is the DLL and a text file saying that I must:
Add the DLL as a reference to my project
Add using LightName; to the top of the class
Instantiate an instance of the object like so: LightName *ln = new LightName();
Call function void turnOn() with the newly created LightName instance.
Firstly, I find it odd that an external library requires me to instantiate an instance of their object especially when its for a simple piece of hardware.
Secondly, the other company has provided me with no interface files.
My question is:
How can I possibly link to a C++ DLL and expose the functions nested in this library without having an interface header file in a Qt environment? Is there someway to make an interface for an external library?
I have already attempted using QLibrary and doing the following:
QLibrary myLib("mylib");
typedef void (*MyPrototype)();
MyPrototype myFunction = (MyPrototype) myLib.resolve("mysymbol");
if (myFunction)
myFunction();
However, this doesn't work because the DLL I was given was not a C DLL and I have no interface so Qt doesn't have a clue about what symbols it needs to resolve.
I've attempted to display all the definitions exported from my DLL using the dumpbin /EXPORTS command. Unfortunately this was unable to produce anything. I was hoping that I would get some sort of mangled C++ from this that I could then unscramble to make my own header.
I've attempted to use the dependency walker(very useful tool) however it couldn't resolve any symbols to give me some function definitions.
QLibrary only helps you if the library has functions exported as C symbols. If that is C++ you can dump the symbol table and look if that is sufficient for you. Names must be demangled: try to look for dumpbin or similar. It is however possible that you can't do this, it depends on how the symbols have been defined. In that case you'll have to ask for the header: read this.
Well it's absolutely legal to ask you for "instantiating an instance of their object". It's been simply their design decision to make the dll interface object oriented (as contrary to plain extern "C"). QtCore.dll is just someone else's DLL too, and you are instantiating their objects all the time.
But it also means that you will have harder time to call the DLL. The symbols are not "C" symbols (you can't export class that way) so QLibrary can't do anything for you. You can try dumpbin /EXPORTS from the DLL and then tediously unmangle them to reconstruct the class declaration. Luckily there are tools to help you (even online)
But not providing a header file for such DLL is completely dumb in the first place.
I am new in java, I have spent hours for this problem. I will be really thankful for anyone who can help me.
Here is the problem.
My project, say ProjectA, need a
bunch of libraries to compile, but I
don't think I need a library called
LibraryB.jar. So the project
compiled correctly without LibraryB
in the class path.
At runtime, the program exited
without any error message. I didn't
know the reason until I put
LibraryB.jar in classpath when I run
my project
Could anyone tell me why this is happening? As I know, in java, If I referenced LibraryB.jar, it would be needed at compile and link time. Maybe I am wrong.
Lacking concrete examples, I can only give you a high-level overview:
If your project uses LibraryA that depends on LibraryB but does not actually expose any of LibraryB's classes in its interfaces (i.e. it only uses it internally), then you can easily come into a situation where you only need LibraryA to compile, but need LibraryB to actually run your code.
If your application exits without an error message, then it's your own fault, more often than not. Especially for people new to Java, a common cause for this is empty catch-blocks (don't do this!):
try {
someCodeThatCanThrowAndException();
} catch (Exception e) 7
// nothing
}
Well, I'm trying to achieve the following: add and ActiveX control (AxExpressViewerDll::AxCExpressViewerControl from AutoDesk) to a Qt form. But, there is no way to get the object to load from DLL, for example (the long number is the UUID taken from Visual Studio):
QAxWidget* wmp = new QAxWidget();
wmp->setControl("{55523A67-A054-4064-B88D-0070305C9F95}");
VS picks up the COM object fine, the .dll (AdView.dll) was registered with regsvr32, I even linked the dll directly to the project with the LIBS directive. I even tried this: link
I always get:
CoCreateInstance failure (Class not
registered)
QAxBase::setControl:
requested control
{55523A67-A054-4064-B88D-0070305C9F95}
could not be instantiated
Any help would be appreciated
answsered after months, but still might be helpful :
Maybe you should take look at the qtbrowser plugin : http://doc.qt.nokia.com/solutions/4/qtbrowserplugin/
Instead of developing and ActiveX and then embedding it into qt, use directly qt. Unless you want your activeX to be available outside qt...
Is it possible to find all interfaces (classes, parameters, ect..) normally registered with Component Object Model's (COM) TypeLib even though the TypeLib is completely empty? If so how would you go about doing this? I believe another term for this is an "Anonymous COM". I am sure that accessible interfaces exist for this COM because i have an application that is using a class that isn't listed in the TypeLib.
If the type library is blank, then there is no way that you can find information about the types in a COM library.
You need at least a coclass entry in the typelib to find an implementation of IUnknown.
If you have that, then you can actually create instances of the class and then call QueryInterface on IUnknown for the IDispatch implementation (if one exists).
If an IDispatch interface exists, you can then call GetTypeInfo to get information about the interfaces that are implemented.
If you need to make late-bound calls to IDispatch, then you will need to call the Invoke method.
Note, you mention the type library, but it is common practice for in-process COM servers to embed the type library in the dll that is the implementation of the types represented in the library. Are you sure that you haven't checked that as well? Or are you sure you have the type library and it is indeed blank?
If the type lib is indeed blank and the dll doesn't contain it, it's completely possible that the type lib was "private" in the sense that other clients were compiled against it. COM doesn't need a type-lib at runtime necessarily. The pattern for exposing IClassFactory interface implementations is to export a standard DLL function with a well-known signature.
One could easily call LoadLibrary, then call GetProcAddress and cast the result to IClassFactory. From there, they would use the private GUID and IID that they know (not from the type library) as well as the COM interfaces that they have defined privately and work from there.
The only reasoning I can think of for something like this is a form of obfuscation and/or addressing privacy/security concerns, only allowing clients the producer of the server approves of to call it.
It doesn't help you, but could explain why you are seeing a type library with no information in it and at the same time, see other clients consume the library.
Not using a type library in COM programming is fairly common. Any scripting language does, it uses IDispatch to discover supported methods and properties at runtime. IDispatch::GetIDsOfNames() or IDispatch::GetTypeInfo() gets that ball rolling. This is called late-binding. It is slow, but that doesn't matter in a scripting language.
Another standard way is through header files generated by MIDL from a .idl file that describes the interfaces and coclasses. You'll find many of them in the Windows SDK include directory, mshtml.h for example. But this is suitable only to unmanaged C/C++ code.
Using COM without a type library in a managed language like C# is difficult but not impossible. VB.NET is the better language, it supports late binding out of the box. C# will get better when version 4.0 arrives, it has a new "dynamic" keyword.