Calling Functions in Files?

Programming, for all ages and all languages.
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Post by AJ »

Hi,

Just another thought - why not parse the header file for parameter information and only let the user enter functions found in the provided header - kind of like how code completion works? That way you could provide code completion as additional functionality too.

Cheers,
Adam
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

The point of the program is that it asks the user to type/select a function, then enter in it's arguments, then run the function.

It's my job on the project to write the actual nitty-gritty part of things - the functions that call the function in the file. To get more info, go to SourceForge and find APICaller.

While you're at it, take a look at my project, MLC... it's not much yet but I'm getting there :D ...
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

ok, if i understand correctly you just want to call a user specified function from a user specified dll/exe with user defined parameters. The first two are rather easy but that latter might give some headaces.

Code: Select all

#include <windows.h>
int main(int argc, char * argv[]) {
    //- argv[1] contains dll.
    //- argv[2] contains func.
    //- argv[3] onwards should contain the parameters.
    DWORD func;
    HMODULE hmod;

    if((hmod = LoadLibrary(argv[1])) != 0) {
        if((func = GetProcAddress(hmod, argv[2])) != 0) {
            //- ok, we have got the requested address. now call it.
           <<see below>>
        }
    }
}
the difficulty is now how to call the function with the different parameters as each function can have a different number of parameters as well as different types and even different call methods cdecl, stdcall, fastcall etc. so you first have to study the different call methods and then mimic the behaviour and problably use assembly to call the function. for instance cdecl uses the stack. so you could:
1) build a local stack
2) push the parameters in the correct order
3) call the function (assembly using the local stack)
4) save the return value
5) restore the program stack
6) return the saved return value

The concept is rather easy but getting it to work might not be. good luck.
Author of COBOS
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Post by Solar »

Combuster wrote:And yes, using getprocaddress is bad for security, but then again, who runs winamp as admin and leaves the plugin directory open for non-admin users? (or: why not find another hole in IE instead)
You shouldn't run MSIE as admin, either - that doesn't mean that it's OK to turn a blind eye towards its bugs. Consider the combination of such an easy stack-smashing attack and a user priviledge escalation bug in a different component...

In my eyes, telling management "shouldn't be done" is a very valid technical decision. At least get your doubts stated in writing, so they won't hang you out to dry when things go wahoonie-shaped.
Every good solution is obvious once you've found it.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Post by Brendan »

Hi,
pcmattman wrote:It's my job on the project to write the actual nitty-gritty part of things - the functions that call the function in the file. To get more info, go to SourceForge and find APICaller.
I did...

As a utility intended for quality assurance and test purposes I can't see what the point is, considering that most functions rely on "state" (e.g. global data and/or data loaded from files), and that most people who have access to source code usually have access to "cut & paste".

I'd also be skeptical of a project where the leader knows less than you do (unless you're being paid well, in which case grab the cash while you can). :)

Compare this paragraph (from the main page):

"API Caller is a software for extracting API functions from any executable and can be used to call them. With this tool, quality can easily be checked by calling functions and checking them if they are error-free."

To this paragraph (from the tracker):

"coding a function in API caller for calling the APIs itself, this function
can used with any type of parameters (e.g. bool, int, char) and can also
return any type. And also any number of parameters. Also, please make
another separate function to load the executable and the header in C++, if
necessary also it's library. It's up to you how the function is named and
how the parameters can be entered. If there's a problem, please tell me.
Thanks for your help.
"

Is it just me, or does this sound a lot like "I'm building a time machine, but I can't figure out how to travel through time. All help appreciated..."... ;)

Once you've done all of the hard work (um, written the little function) what will the "project leader" add to the project? Some user interface fluff, or a little documentation?


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Post by Solar »

A pretty twisted approach to what is generally refered to as "test drivers". You usually want them to reside in code, alongside the stuff that is being tested, because the real value of a test driver is that it can be run repeatedly so you can compare results...
Every good solution is obvious once you've found it.
Post Reply