Call function at runtime

[leaf]

Hi,

How to call function at runtime,
based on a struct that contains the information for the function call:
struct func_to_call {
int function_id; // function id to call
unsigned int nparams; // number of parameters
unsigned long* parameter; // the parameter(s) to pass
}

to be passed to some function like this one:

call_function( int id, unsigned int nparams, unsigned long* params )
{
// ???
}

*as you can see functions have different number of parameters ( but all
are of type ULONG )
* function are called from a DLL.
* should i call_function via ordinal number?
--
young_leaf

[Victor Bazarov]

leaf wrote:

How to call function at runtime,
based on a struct that contains the information for the function call:
struct func_to_call {
int function_id; // function id to call
unsigned int nparams; // number of parameters
unsigned long* parameter; // the parameter(s) to pass
}

to be passed to some function like this one:

call_function( int id, unsigned int nparams, unsigned long* params )
{
// ???
}

*as you can see functions have different number of parameters ( but all
are of type ULONG )
* function are called from a DLL.
* should i call_function via ordinal number?

I think you need to invest a bit more time at reading about the things
known as "interprete rs". Mechanisms for function invocation are very
implementation- and system-specific, if you want to be reasonably
sophisticated.

In most simple cases you create a table of addresses of the functions you
expect to call and then match the function address (pointer) to the ID you
assigned to it.

V
--
Please remove capital As from my address when replying by mail

[n2xssvv g02gfr12930]

leaf wrote:

Hi,

How to call function at runtime,
based on a struct that contains the information for the function call:
struct func_to_call {
int function_id; // function id to call
unsigned int nparams; // number of parameters
unsigned long* parameter; // the parameter(s) to pass
}

to be passed to some function like this one:

call_function( int id, unsigned int nparams, unsigned long* params )
{
// ???
}

*as you can see functions have different number of parameters ( but all
are of type ULONG )
* function are called from a DLL.
* should i call_function via ordinal number?
--
young_leaf

Why not just use an STL vector for the parameters and either an array
or STL map of function pointers. I've used methods like this without
much difficulty, (OK I'm geeky about C++), so I suggest you learn about
STL vectors and function pointers.

JB

[leaf]

this article:
http://www.drizzle.com/~scottb/gdc/fubi-paper.htm

seems to be a solution to me,
its about 'Function Binding System'

using a bit of assembly, it calls a function with variable arguments i
think,
here's the code snippet:

DWORD Call_cdecl( const void* args, size_t sz, DWORD func )
{
DWORD rc; // here's our return value...
__asm
{
mov ecx, sz // get size of buffer
mov esi, args // get buffer
sub esp, ecx // allocate stack space
mov edi, esp // start of destination stack frame
shr ecx, 2 // make it dwords
rep movsd // copy params to real stack
call [func] // call the function
mov rc, eax // save the return value
add esp, sz // restore the stack pointer
}
return ( rc );
}

*as you can see its pretty much the one that i need i think,
the line that needs attention is this:
call [func] // call the function

what reference will ensure that that line would call the right
function?
from where?

---
young_leaf

[leaf]

i may have slipped in reading, but i think it uses symbol names
exported with dllexport to allow binding by name to exported symbols?

---
young leaf

[Victor Bazarov]

leaf wrote:

this article:
http://www.drizzle.com/~scottb/gdc/fubi-paper.htm

seems to be a solution to me,
its about 'Function Binding System'

using a bit of assembly, it calls a function with variable arguments i
think,
here's the code snippet:

DWORD Call_cdecl( const void* args, size_t sz, DWORD func )
{
DWORD rc; // here's our return value...
__asm
First of all, it's "asm" and not "__asm". Second, whatever you think you
know about assembly, has no relevance here. In C++ assembly code is not
standardized. It's totally implementation- and platform-specific.
[...]

*as you can see its pretty much the one that i need i think,
the line that needs attention is this:
call [func] // call the function

what reference will ensure that that line would call the right
function?
from where?

That is _not_defined_. Ask in a newsgroup that deals with your compiler
or with your platform, or both.

V
--
Please remove capital As from my address when replying by mail

[Victor Bazarov]

leaf wrote:

i may have slipped in reading, but i think it uses symbol names
exported with dllexport to allow binding by name to exported symbols?

Now you're totally off topic.

[Kaz Kylheku]

leaf wrote:

Hi,

How to call function at runtime,
based on a struct that contains the information for the function call:
struct func_to_call {
int function_id; // function id to call
unsigned int nparams; // number of parameters
unsigned long* parameter; // the parameter(s) to pass
}

This is not portable in portable C++. The number of functions passed in
a function call are determined at compile time, and comiple time is
something that occurs prior to execution time. C++ does not define any
way of dynamic compiling and loading.

What you can do is pre-compile some cooked function calls, and have a
big switch statement which selects one of these calls based on the
parameters.

For instance, suppose all the parameters are restricted to type int,
and the only variation is in the parameter number. Then, given a
pointer to the function ptr, and an array of integer arguments
int_arg[], you can do something like:

switch (number_of_argu ments) {
case 0:
{
void (*func)() = (void (*)()) ptr;
func();
}
break;
case 1:
{
void (*func)(int) = (void (*)(int)) ptr;
func(int_arg[0]);
}
break;
case 2:
{
void (*func)(int, int) = (void (*)(int, int)) ptr;
func(int_arg[0], int_arg[1]);
}
break;
/* ... other cases ... */
}

This kind of "glue" code can quickly explode in size, since you have to
write the source code for every kind of binary interface you want to
call, include it in the body of the program, and have a way to route
control to it.

There is a library (GNU GPL'ed though!) for constructing C function
argument lists dynamically and calling functions. The name of this
library is "libavcall" and it was originally written by Bill Triggs.

This library defines a set of macros which, loosely speaking, function
as "opposites" to the standard <stdarg.h> macros va_list, va_arg. That
is why the letter "AV" are used to name the library: VA backwards.

When you construct a list with a specific return type and arguments, it
is automagically copmatible with a function which has that signature,
so then all that is needed is a pointer to that function and you can
call it.

The avcall library is not written portably. It contains a lot of
compiler and platform specific code. It has to understand the calling
conventions of the architecture and operating system platform, so that
given any dynamically constructed av_list, it constructs the right kind
of function calling linkage and performs the right kind of cleanup
afterward.

[leaf]

One question:
When a you 'link' a DLL lib ( static linking ) into a Win32 application
for example;
can we call the functions ( we know that exist in the DLL ) via some
low-level means?
will the exported functions have an 'address/pointer or something' with
the application's process space?

to note:
functions that i need to call are from a DLL, exported using dllexport
for instance.

[Kaz Kylheku]

leaf wrote:

One question:
.... for a Win32 newsgroup, not for here.
When a you 'link' a DLL lib ( static linking ) into a Win32 application
for example;
DLL is not static linking (note the 'D'). The DLL's that are specified
on the linker command line when the program is built are still
dynamically loaded with LoadLibrary(). This is called "load time
dynamic linking" by MSDN. That term is used in the FreeLibrary page for
instance.

LoadLibrary will find an library that is already loaded and properly
increment the reference count on the handle. when you are done with
that reference, use FreeLibrary to drop it. This is true whether the
library was load-time linked or whether it was explicitly loaded by a
call to LoadLibrary().

There is also GetModuleHandle which doesn't increment the module
reference count. This is probably okay for those load-time linked
libraries which can be counted upon to remain valid over the lifetime
of the program.
will the exported functions have an 'address/pointer or something' with
the application's process space?
Yes, accessible by GetProcAddress
to note:
functions that i need to call are from a DLL, exported using dllexport
for instance.

That doesn't matter. The issues are the same. You end up with a pointer
to the function. Unless you have some dynamic calling mechanism like
that avcall library, you have to cast that pointer to the right type
and call it with the right arguments. That cast and call are written in
your program and compiled. If you have a small repertoire of type
signatures, you can just write the glue code.