C / C++ / MFC

Christian Graus30-May-05 14:35

Christian Graus

30-May-05 14:35

Are the PSDK includes at the top of the list, so they get searched first ?

Christian Graus - Microsoft MVP - C++

User 1278230-May-05 15:24

User 12782

30-May-05 15:24

Yeah, they're on top already.

modified 12-Jul-20 21:01pm.

Ravi Bhavnani30-May-05 15:39

Ravi Bhavnani

30-May-05 15:39

Try adding these lines to your stdafx.h:

    #define _WIN32_WINNT 0x0501
    #ifndef WINVER
      #define WINVER 0x0501
    #endif

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

dynamically calling dll functions

User 1278231-May-05 13:26

User 12782

31-May-05 13:26

Now I get thread and other API errors in addition to the other ones. I don't get what changed, it just stopped compiling without any changes I'm aware of.

modified 12-Jul-20 21:01pm.

Tom Archer30-May-05 11:10

30-May-05 11:10

In some dynamic scenarios, I'm accustomed to calling LoadLibrary and GetProcAddress to load and call a function at runtime. However, in those cases the function pointer is defined in my code that specifies the function's signature. What if I don't know the signature?

Let's say I don't know the DLL and function name until runtime. Obviously, I can call the GetProcAddress as it simply requires a FARPROC address. However, how will I be able to call the function and pass params to it at this point?

One possibility is directly controlling the stack in code since I can't define what I want in code and have the compiler do that for me. Any ideas?

Cheers,
Tom Archer - Archer Consulting Group

"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe

Ryan Binns30-May-05 17:55

30-May-05 17:55

Tom Archer wrote:
Let's say I don't know the DLL and function name until runtime. Obviously, I can call the GetProcAddress as it simply requires a FARPROC address. However, how will I be able to call the function and pass params to it at this point?

Do you know the number and types of parameters the function takes?

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Tom Archer30-May-05 18:51

30-May-05 18:51

The DLL name, function name and parameter and return info are all passed to me via XML elements.

Cheers,
Tom Archer - Archer Consulting Group

"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe

munawar196830-May-05 19:08

munawar1968

30-May-05 19:08

Here goes..

//define your func
typedef DWORD (__stdcall *pFunction)(DWORD, DWORD, etc etc);

pFunction MyruntimeFunc;

//call it
int execute(char * runtimelib, char *runtimefunc)
{
char *TmpPtrToRuntimeFunc,MyRuntimeLib[150] ;
strcpy(MyRuntimeLib,runtimelib);
TmpPtrToRuntimeFunc=runtimefunc;
hLib = LoadLibrary(MyRuntimeLib);
if(hLib)
{
MyruntimeFunc = (pFunction)GetProcAddress(hLib,TmpPtrToRuntimeFunc);
if(MyruntimeFunc)
{
MyruntimeFunc(Param1,param2....);
return 0;
}
}
return -1;
}

//Hope it helps

Cedric Moonen30-May-05 21:20

Cedric Moonen

30-May-05 21:20

I think this is not exactly what he is looking for (if I understood it well). The number and types of arguments are only known at runtime thus it is not possible to use a typedef for the function...

munawar196830-May-05 22:09

munawar1968

30-May-05 22:09

If you dont know the params either, two solutions

1. as you said... manipulate the stack itself. asm required. push each param onto the stack and call the func address. get ret value from eax.

2. Run-time compilation. Check "http://www.c-sharpcorner.com/Code/2003/Feb/RuntimeCompiler.asp" for a sample.

Tom Archer31-May-05 2:50

31-May-05 2:50

munawar1968 wrote:
1. as you said... manipulate the stack itself. asm required. push each param onto the stack and call the func address. get ret value from eax.

Agreed. But this is precisely what I don't know how to do.

Cheers,
Tom Archer - Archer Consulting Group

"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe

Tom Archer31-May-05 2:49

31-May-05 2:49

Thanks for the reply, but this was precisely what I said I can't do as I don't know the fcn signature until runtime.

Cheers,
Tom Archer - Archer Consulting Group

"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe

Ryan Binns30-May-05 22:46

30-May-05 22:46

Tom Archer wrote:
The DLL name, function name and parameter and return info are all passed to me via XML elements.

Can you be certain they're correct? If the parameter info is wrong, then disaster could follow. Also, are you certain of what the calling convention is (C vs pascal etc.) as this affects how you should call it.

If you're sure it's safe, then the easiest way is probably to push the parameters on the stack in the right order and then call the method directly - some assembly required. It won't be very easy because you'll have to make sure that any intermediate operations you do in between pushing parameters (such as loading the next value, checking its type etc...) don't modify the stack (or at least leave it in the same state it began in). The return value (if there is one) will always be held in the EAX register (for an 8-bit to 32-bit return value) or EDX:EAX for a 64-bit value. For structures, I believe the EAX register hold the address of the return structure, but I'm not certain.

The other option is to dynamically compile some code that does the same thing, but again you'll run into difficulties passing the parameters.

One way I've had success in passing arbitrary parameter lists in the past is to assemble a block of memory that looks like the stack should, and then allocate space on the stack and copy the memory into it just before you call the function - much easier than managing pushes at the right time.

It would be much easier if you could narrow down the types and number of parameters a bit.

Anyway, I hope that helps a bit.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Tom Archer31-May-05 2:52

31-May-05 2:52

Hi Ryan,

The client is responsible for the function desc. If it sends the wrong data, then it's expected that bad things will happen. I kinda figured that inline assembler would be needed to push the params onto the stack, but that's exactly what I don't know how to do.

Cheers,
Tom Archer - Archer Consulting Group

"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe

Ryan Binns31-May-05 3:21

31-May-05 3:21

Tom Archer wrote:
I kinda figured that inline assembler would be needed to push the params onto the stack, but that's exactly what I don't know how to do.

OK. I'll give a few examples. Hopefully you can extend them.

Say you've got the address of a function in a variable called funcPtr and you need to pass a float and an int and the function returned a char, then you could do something like this (assuming C style calling convention):

char callFunction(void *funcPtr, float parm1, int parm2)
{
  __asm push parm1
  __asm push parm2
  __asm call funcPtr
}

Of course this can be extended for more arguments, and it should work for doubles (64-bit values) as well. I'm not sure how it works for values less than 32 bits. I think the compiler pushes an entire zero-extended 32-bit value, so you'll need to take that into account (store smaller values in a 32-bit temporary variable first).

You should be able to put this in a loop as follows:

char callFunction(void *funcPtr, int *values, int numValues)
{
  for (int i=0; i<numValues; i++)
  {
    __asm push values[i]
  }
  __asm call funcPtr
}

It should work alright, but I have never had to do this, so I'm not 100% certain. If it has trouble with the array index, assign values[i] to a temporary variable first (make sure it's local to the function, not the for loop, or you'll have problems with stack corruption).

As I mentioned before, another way I've done it is to allocate a block of memory for the actual parameter contents as they would appear on the stack, and the copy it all in one go. It makes the inline assembly much easier and predictable:

char callFunction(void *funcPtr, void *stackPtr, int stackSize)
{
  // Make room on the stack for the parameters
  __asm sub esp,stackSize
  // Copy the parameters to the stack
  __asm mov esi,stackPtr   // Source address
  __asm mov edi,esp        // Destination address
  __asm mov ecx,stackSize  // Number of bytes to copy
  __asm rep movsb          // Copy the bytes
  // Call the function
  __asm call funcPtr	
}

This version I have taken directly from some code I have written and tested, so I know it works. This is what I would recommend doing, as you can then assemble the stack information without using inline assembly (pointer arithmatic is much easier to understand Wink | ;)

) and just copy the data and call the function using a simple consistent method.

[edit]If you use the last technique, remember that for the C calling convention the parameters are passed in such a way that the highest address has the right-most parameter.[/edit]

Hopefully that gives you enough information to get it working.

Cheers,

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Ryan Binns31-May-05 4:09

31-May-05 4:09

I just realised my first two examples were wrong D'Oh! | :doh:

The parameters should be pushed in the opposite order for both of them. The third is still correct though.

Sorry about that Blush | :O

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Tom Archer1-Jun-05 1:32

1-Jun-05 1:32

Thanks Ryan for all your help.

Cheers,
Tom Archer - Archer Consulting Group

"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe