I have two projects under one solution in VS2010.Project Application is dependent on project Module.
I can't access application pointer in Module due to dependency.
But I know using a callback function I can get application pointer in Module.How to do it?
You can just extern a pointer from Module in one of Module's headers. Otherwise, you just call a function and return a pointer. Declare this function in a header and then call it from your application.
Related
Apologies in advance for noob mistakes. This is my first question here. First, some background:
I am trying to create a module for a program using dependency walker to find C++ functions in a .dll that I don't have the lib or any source code for. You can also assume that I can't get support from the original developer. Basically, I checked another file that accesses it to see what the minimum functions were to get it working. Here is an example of the undecorated names that are output:
void foo::bar::baz(float)
float foo::bar::qux(void)
foo::bar::bar(void)
class foo::bar & foo::bar::operator=(class foo::bar const &)
The top two functions obviously take float or void and return float or void. I got a similar function working using something like:
HINSTANCE THEDLL = LoadLibrary("C:\\dllFolder\\theDll.dll");
typedef float (*quxType)(void);
quxType qux = (quxType)GetProcAddress(THEDLL, "quxMangledName");
So those are not a problem.
Now, the third on the list looks like another function that takes void, but it doesn't have an explicit return type. Does this mean I should just use an implicit type for it, is it void, or is it not really a function? If not, what is it?
I have no idea what to do with the fourth one. Is it even possible to handle without the associated .h file?
I looked around, but I couldn't find any information on what to do when the function doesn't look like a normal function with an explicit return type. Despite using basically the same code that I used to get a function working in a similar .dll, I keep getting an access violation crash when I try to use function #2 here (I really just need function #2). So I am guessing that the .dll needs more information or needs something initialized first, which is why I am interested in the others on the list.
I realize this is a complicated problem, so there probably won't be a "Right answer" solution to get it working, but if I am making any obvious mistakes, or if there are any general suggestions for how to attack the problem (even alternatives to dependency walker), let me know.
The 3rd one is the default constructor of bar.
The 4th one is the copy assignment operator of bar.
I think you need to instantiate the class first, in order to call the 2nd method. Otherwise the method would be called with an invalid 'this' that causes access violation.
The problem is how you instantiate it?
If you can find a factory function that returns a bar in the DLL, you can try to use it.
If you don't see a factory function and you don't have the lib file, you can refer to answers here on how to create a lib from a DLL: How to make a .lib file when have a .dll file and a header file
You also need to create header file for the class, with the correct order and types of members. This way you don't have to use LoadLibrary and GetProcAddress, just use the class as normal.
You may still use LoadLibrary and GetProcAddress without the lib and header though, this blog shows how to manually allocate memory, call constructor, gets an object and pass that object to call a method: http://recxltd.blogspot.com/2012/02/working-with-c-dll-exports-without.html
I'm having a problem with function pointers and nothing I found on the net helped me to solve this problem.
I have a function from a C API which take a pointer of a void function :
extern int APIFunction(int, void (*func)(int));
I have a class with the function I would like to put when I call the API function.
class MyClass
{
public:
void myFunction(int status, otherAPi arguments...);
};
Then, I created a pointer to my member function and created a new instance of my class
typedef void (MyClass::*MyClassFunctionPointer)(int stat, otherAPi arguments...);
MyClassFunctionPointer fctPointer= &MyClass::myFunction;
LicenseSecurity instance;
I get an error when I try to call my APi function with the function pointer I created:
int stat = APIFunction(5, fctPointer ); // -> error 1
int stat = APIFunction(5, instance.*fctPointer ); // -> error 2
I got errors respectively in the first and second case:
E2034 Impossible to convert 'void (MyClass::*)(int, otherAPITypes...)' into 'void (*) (int, otherAPITypes...)'
E2342 Bad type correspondence in the parameter 'func' ('void (*)(int, otherAPITypes...)' desired, 'void(int, otherAPITypes...)' obtained)
I don't have access to the API function so I can't modify it. To summary the problem: how How to get a "simple" C function pointer to put in argument of a function from a member function of my class?
Thanks
Unfortunately, you can't. Sorry.
Ideally, your API would accept something like std::function that would allow you to wrap free functions or member functions. But if you can't modify the API, then you have no choice but to provide a free function.
You can't get a "simple" function pointer to a non-static member function because the function requires a this pointer when called. If you were to create a function pointer like that then when the function was called there would be no this pointer for it to reference.
With an ancient C API like that, you unfortunately don't have any way to do this.
What you have to do is make a static or non-member function to take the callback, and then figure out which instance of the object to call the member on. Some C APIs allow a user data to be passed to the callback, and in that case you use that to store the this pointer in question. If that's not an option you can use a global or singleton object and only allow a single such callback to be registered.
You can declare the callback as either a standalone function or as a static method of the class. The tricky part is accessing a class instance pointer inside the callback.
Ideally, a well-designed API allows you to specify a user-defined value to callbacks. That allows you to easily pass in a class instance and access it directly inside the callback. But it sounds like you are not working with such an API, so you need to use a workaround.
If you have only 1 class instance being used with the API at a time, you can store the instance pointer into a global variable, and have the callback use the global variable to access the instance.
But if you have multiple class instances being used at the same time, you are looking for a thunking solution, similar to the VCL's MakeObjectInstance() function, which allows TWndMethod-signatured class methods to be used as Win32 window procedure callbacks. Essentially, a block of executable memory is dynamically allocated, stub assembler code is written into the block, and the instance pointer and class method pointer are stored in the block as well. The block is then passed to the API as if it were a function pointer. When the API calls the "function", the stub code gets executed, which has to manipulate the call stack and CPU registers to call the stored class method pointer passing the stored instance pointer as its hidden this parameter, while preserving the semantics of other parameters, the call stack, function result, etc.
Nothing in C++ really accomplishes that kind of thunking natively. It is not difficult to implement manually, but it is not trivial either (have a look at the source code for MakeObjectInstance() in the VCL's Classes.pas source file). The hardest part is coming up with the necessary stub code that matches the semantics of your particular class method's signature.
I just want to know if there is any way to call a c++ class into our nsis script ?
Thanks.
NSIS can call functions in DLLs but the calling convention is somewhat limited and there's no direct support for classes. You will not be able to easily call class function.
You might be able to "hack" it by making extern "C" wrapper functions for every class member function, along with function that create and destroy instances of the class as necessary. You'd have to somehow passes something that represents the newly created instances back to NSIS, which then would pass it into the wrapper functions along with any necessary parameters/arguments.
Sounds like more trouble than it's worth...
In my opinion the easiest way to call your function will be to export it to dll and then call them from nsis using System::Call function.
I am loading a function from a .SO 'plugin' file in my code. The plugin will define 3 very specific functions, the full API for each function is defined ahead of time (the point is allow different instances of the same program to modify their behavior via the use of a different plugin. Due to the amount of it's use, need for speed, and my general laziness I decided to use a static function pointer which can store the plugin functions rather then passing the function pointer around various objects.
It's possible for a plugin not to exist, in which case I want to run what is essentially a 'no-op' function in place of the function that would have been read form the plugin. For general safety I want to ensure that the static function pointers point to my no-op functions.
For whatever reason I can't seem to do this. If I try to define the no-op funciton in the .h file and assign my function pointer to it I get all kinds of errors for defining a function in a .h. If I try to declare only the prototype of the method in the .h and assign the function pointer to the prototype I get an undeclared funciton exception, even if the function is defined in a .cpp file.
I know I can easily assign the funciton pointer to a no-op in my main() function. But is there a way to do this so that the .H file gaurentees that the pointer defaults to my no-op function even if I (or someone later) don't properly assign it in my main() method?
Header (say, PluginInterface.h):
extern void (*my_plugin_function_ptr)(...);
Source (say, PluginInterface.cpp):
#include "PluginInterface.h"
static void default_plugin_function(...) {/* does nothing */};
void (*my_plugin_function_ptr)(...)=&default_plugin_function;
How would I go about calling an unexported function in Win32 C++?
Calling unexported functions that are defined in the same module (DLL/EXE) as your code is easy: just call them like any other C++ function. Obviously this isn't what you're asking about. If you want to call unexported functions in a different module, you need to find out their addresses somehow.
One way to do this is to have the first module call an exported function in the second module which returns a function pointer. (Or: a struct containing function pointers, a pointer to an instance of a class, etc.) Think factory pattern.
Another way is to export a registration function from the first module and have the second module's initialization code call it, passing it pointers to unexported functions along with some sort of identifying info. (Better also have a corresponding unregistration function which is called before the second module is unloaded.)
Yet another way is to grovel through the debug symbols using dbghelp.dll. This would not be recommended for a real-world application because it would require distributing debug symbols and would be extremely slow, not to mention overly complex.
Additionally to bk1e's answer, there's still another method (not recommended as well).
Obtain the relative Adress of that function in the dll (e.g. via disassembly). This has to be done manually and before compiling.
In the program, you now have to obtain the startadress of the dll in memory (for example using an exported function and some calculation).
Now you can directly call that function using the relative Adress of the function + the startadress of the exported function.
I don't recommend this though. It works only on one defined version of that dll. Any recompile and the adress may change. Or that function may not be needed any more and gets deleted. There must be a reason, why this function is NOT exported. In general - you try to archive something the author of the library intentionally did not want you to do and that's "evil" most of the time.
You mentioned the ida-name. This name includes the startadress.
No two ways about it, you'll have to study the disassembly to figure out what gets pushed on the stack, and how it's used to determine the types.