AutoIt Plugin: Call a function using only it's pointer.

[Kip]

An AutoIt Plugin to call functions using only their pointer.

You'll need this when an external function returns a function pointer that you then need to call. But how??

Global Const $VOID      = 0;
Global Const $INT8      = 1;
Global Const $INT16     = 2;
Global Const $INT32     = 4;
Global Const $INT64     = 8;
Global Const $PTR       = 6;
Global Const $FLOAT32   = 7;
Global Const $FLOAT64   = 9;
Global Const $CSTRING   = 10;

PluginOpen("PtrCall.dll")

$hLib = LibOpen("User32.dll")
$pMessageBox = FuncPtr($hLib, "MessageBoxA")


$retval = CallPtr($INT32, $pMessageBox, _   ; int MessageBox(
                    $PTR, 0, _  ;   HWND hWnd,
                    $CSTRING, "Hi!", _  ;   LPCTSTR lpText,
                    $CSTRING, "Called without DLLCall()", _     ;   LPCTSTR lpCaption,
                    $INT32, 0)  ;   UINT uType );



msgbox(0, "Plugin",$retval)

The first parameter of CallPtr is the return type (can't be $CSTRING)

The second parameter is the pointer to the function ( Doesn't have to be the value returned from FuncPtr() )

And then in groups of two parameters: (just like DllCall actually)

- Param type (can't be $VOID)

- Param value

Download my plugin:

PtrCall.dll

Au3Check will probably popup saying there are some undefined functions. Stupid Au3Check, just hit "Continue Anyway".

Only works with 32-bit compiled scripts. ( But you can run it on a 64-bit machine)

Edited March 29, 2010 by Kip

[James]

What are the advantages of calling a function like this?

James

[Kip]

What are the advantages of calling a function like this?

James

Speed probably, but the main purpose of this is to be able to call functions if you don't know anything but their pointer. (No name, no library, nothing) except the parameters.

Edited March 29, 2010 by Kip

[wraithdu]

How hard would it be for the devs to integrate this into DllCall()? I mean, it actually one less step in the DllCall process, right? They just skip GetProcAddress to look up the function and use the provided pointer. Is there a feature request on Trac somewhere for this?

[Kip]

How hard would it be for the devs to integrate this into DllCall()? I mean, it actually one less step in the DllCall process, right? They just skip GetProcAddress to look up the function and use the provided pointer. Is there a feature request on Trac somewhere for this?

Not I'm aware of.

[wraithdu]

Actually, I found an old feature request for it (17 months old). I commented in it for reconsideration. A lot has happened in AutoIt in 17 months, and I think it's a worthwhile feature enhancement at this point, especially with the release of AutoItObject.

[James]

Imagine AutoItObject features in AutoIt core. Wow, if only.

[Kip]

Imagine AutoItObject features in AutoIt core. Wow, if only.

I think that subject has been talked about enough.

[wraithdu]

Yeah, not gonna happen. But native pointer function calls would simplify a chunk of the AIO code.

[trancexx]

There are no advantages, except you get to call pointer.

This wouldn't be faster from the usual DllCall(). Why would it?

Every function you call from plugin dll is going through the same procedure as any other call to any dll function.

Seems like PluginOpen is wrapper for LoadLibraryA and plugin functions addresses are get by call to GetProcAddress (every time you call them). So when you think of it there can't be any speed improvement (unless by accident).

Devs are aware of the need of some to be able to pass pointer to DllCall(). Nothing more to say there. It's their call.

Btw, I would guess no one actually tried Kip's plugin.

Kip, your dll is a mess. Do something with it.

Edited March 30, 2010 by trancexx

[Ascend4nt]

My whole problem with this is that there aren't any scenarios given as examples of when such functionality would be needed. This likely would be how the AutoIT developers view this as well if you beg them to implement a pointer-based DLLCall. When are you getting addresses to things to call that aren't in a DLL lookup table? If it's not something of practical use to most of the users, its probably not going to be added to the language.

I coded a multithreaded Asynchronous-DLLCall myself last year just to see if it could be done (yup, it can). It was a pain in the arse, especially dealing with 'str' variants and pointers to data ('int* '), and especially the x64 implementation which has a completely different calling scheme (using a mix of registers, stack-based variables, and stack alignment techniques).. but anyway, in the end I found that there were hardly any good scenarios I could think to use it for, other than simple things like 'Beep' or 'MessageBox' which would otherwise pause the script.

I realized after coding that though, that it was much wiser to just create code for the specific scenarios I could think of, rather than to have that 'general-use' functionality that would never find any practical general use.

..Which I believe is why the AutoIT developers will reject any pointer-based calling scheme. Where's the practical use for this? And how many people using the language would actually use it.

A plugin is fine, though I still can't see where there will be a use for it, other than hacking into something.. please by all means prove me wrong.

Edited March 30, 2010 by Ascend4nt

[wraithdu]

There are two very practical uses, which I specified in my post to the Trac ticket:

1) Calling functions from embedded, memory loaded DLLs (MemoryDll UDF)

2) Calling functions from COM objects that do not implement IDispatch (native AutoIt object support), and instead implement only IUnknown. This was a manual process before AutoItObject was released. But this feature could still simplify a nice chunk of the AutoItObject code.

[Kip]

There are two very practical uses, which I specified in my post to the Trac ticket:

1) Calling functions from embedded, memory loaded DLLs (MemoryDll UDF)

2) Calling functions from COM objects that do not implement IDispatch (native AutoIt object support), and instead implement only IUnknown. This was a manual process before AutoItObject was released. But this feature could still simplify a nice chunk of the AutoItObject code.

I actually created this to call COM functions.

And trancexx, why is my dll a mess? Does it not work?

[Ascend4nt]

wraithdu,

#1 doesn't make sense, as memory-loaded DLL's is something not very practical for the AutoIT community as a whole

#2 - What types of COM objects are we talking about? How many people would use them, and would AutoIT be the language to use for those COM objects? DirectX for example is ridiculous to code for using a scripting language, though where there's a will there's a way.

I'm not knocking people's use for doing crazy things in the language (I myself do insane things), but I'm just saying - if hardly anyone is going to use it, why add it to the language?

Okay - maybe one less step could be avoided (GetProcAddress call), but how much of an improvement would that make in an interpreted scripting language..

*edit, just to clarify - for #1 I meant the MemoryDLL project - otherwise all DLL's that are called are loaded into memory

Edited March 30, 2010 by Ascend4nt

[Kip]

#2 - What types of COM objects are we talking about? How many people would use them, and would AutoIT be the language to use for those COM objects? DirectX for example is ridiculous to code for using a scripting language, though where there's a will there's a way.

And what about all the other hundreds of interfaces?

[trancexx]

And trancexx, why is my dll a mess? Does it not work?

That would depend on the environment.

Seems you think every person in the world have Visual C++ 2008 installed.

[ProgAndy]

#2 - What types of COM objects are we talking about? How many people would use them, and would AutoIT be the language to use for those COM objects? DirectX for example is ridiculous to code for using a scripting language, though where there's a will there's a way.

Take the new Win7 Superbar feautures as an example (progressbar on button + jumplists). They are based completely on IUnknown-interfaces.

[Ascend4nt]

And what about all the other hundreds of interfaces?

That's just it.. I'm trying to get you guys to shed some light on why this stuff should be natively supported. 'Hundreds of interfaces' is too vague. What's needed is better (more tangible) examples of things that support the idea that adding pointer-based function calls, or enhanced COM functionality, would be beneficial to the general scripting public and thus be practical to add to the language. I haven't seen alot of people here who are in dire need of extra COM functionality.. just a select few. Which is why your plugin, or a standalone DLL, would be fine for those few people that need it.

Take the new Win7 Superbar feautures as an example (progressbar on button + jumplists). They are based completely on IUnknown-interfaces.

That's an interesting example. I don't know how many scripters would use it though (especially since its only one O/S)?

Anyway, I certainly don't have a say in what goes into AutoIT, I was just trying to get people to give enough compelling reasons for the developers to implement the extra functionality being asked for.

[Kip]

That would depend on the environment.

Seems you think every person in the world have Visual C++ 2008 installed.

If you could tell me how to compile it without having the need of Visual Studio installed then: please.

AutoIt is compiled with Visual C++, right? That doesn't depend on the redistributable.

[wraithdu]

'Hundreds of interfaces' is too vague

What, you want someone to list every COM interface that would need this functionality? Are we quantity over quality now?

The question should be why is it not supported. DllCall internally gets function pointers from the DLL and function names. This is actually two fewer steps to call by pointer. Unless there's some technical hangup that I could not know about, I don't see the pitfall.

Just cause you don't have a use for it doesn't make it unimportant. And I hardly think any of us is qualified to speak for the AutoIt community as a whole.