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.
Related
Apologies if this sounds like a silly question. I'm not very experienced with how things are linked/bundled/assembled under the hood.
Before I begin, I'd like to say that I've tried reading documentation (such as https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing) to find the answer, but was unable to.
If I have a Xamarin.Forms solution and I reference a .Net Standard project:
Question 1: Does all the code from this project get compiled and included into the app such that it may be disassembled later, or is it only code from classes that I actually make use of that gets included?
Bit more elaboration:
For example, I may have a School class that expects an IStudent (inject via DI), and a Student class that implements IStudent. Both of these exist in the .Net Standard project that I reference in the Xamarin.Forms project. However, if I only actually make use of the Student class (by registering it with type IStudent in my IoC container), will the code from School get included in the built app as well?
Question 2: If all the code from the project does get included, is there a way to forcefully specify which classes to include/exclude by way of some configuration setting, attributes, 3rd-party library, or something else?
As far as i know everything in the NETStandard project get compiled and shipped with the app.
If you want to remove unused code from compiled assemblies you have to use the linker.
To link everything, you have to select "Sdk and User Assemblies".
The linker tries to dont strip away mthods and fields you are using, but often is too aggressive (for example, methods referenced only by reflection will be stripped).
Luckily there are few methods where you can fine-tune the linker behaviour and make it work. Some link to elaborate on:
Linker in iOS and Android
https://learn.microsoft.com/en-us/xamarin/ios/deploy-test/linker
https://learn.microsoft.com/en-us/xamarin/android/deploy-test/linker
Official doc about the linker config:
https://learn.microsoft.com/en-us/xamarin/cross-platform/deploy-test/linker
Useful blogposts:
https://xamarinhelp.com/xamarin-linker/
https://medium.com/#harrycblum/reduce-your-xamarin-app-size-with-linking-26247edc87f6
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 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.
A friend of mine is working on a legacy VB6 project. I haven't touched that language in ten years, so I'm pretty rusty. Anyway, is there any kind of reflection API for VB6? Specifically, he needs a way to iterate the properties (and types) of a user-created Class. (In other words, not an external COM object, but an internal "Class Module" as it's called.)
How can this be done?
Jay's answer is the way to go if your project is an ActiveX (ActiveX EXE, DLL, or OCX, as opposed to Standard EXE), and if the classes are public.
However, you mentioned that your friend wants to do this with "internal class modules". I'm not sure if you are referring to private .cls files (classes), or .bas files (modules), but either way, you can only use the TypeLib Information Object Library to reflect on public classes, user-defined types, constants, or enumerations.
You cannot use the library to reflect modules, private classes, or anything else that is declared private.
As a general rule of thumb, you can only use reflection on the things that you can see in the Object Browser when viewing your project's contents from another project. That is, if you compile your project, create a new project, add the first project as a reference, and then view the first project's contents in the Object Browser, anything you can see in the Object Browser can be accessed via the TypeLib Information Object Library. If something is not listed in the Object Browser, then you won't be able to use the TypeLib Information Object Library to reflect it.
VB6 doesn't have any built-in support for run-time reflection or introspection. Using the TypeLib Information Object Library for reflection works for ActiveX VB6 projects because ActiveX projects are compiled in COM components with embedded type libraries, but as mentioned you can only access the data types that are publicly exposed in the compiled component's type library. Using the Object Browser is a quick way to determine what is in the type library because the Object Browser actually inspects the component's type library to populate what you see in the Object Browser, as long as you are viewing the component's contents from a separate project (if you view the component from its own VB6 project, it will display public and private data structures, i.e. everything that is visible in the IDE).
Is this the sort of thing you're looking for:
Visual Basic: Inspect COM Components Using the TypeLib Information Object Library
It's discussed on this thread here on SO: Self Inspection of VB6 UDTs
I've never tried this stuff myself.
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.