Sign in to follow this  
Followers 0
Kip

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

24 posts in this topic

#1 ·  Posted (edited)

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 by Kip

Share this post


Link to post
Share on other sites



#3 ·  Posted (edited)

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 by Kip

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

I think that subject has been talked about enough.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

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 by trancexx

♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

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 by Ascend4nt

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

#14 ·  Posted (edited)

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 by Ascend4nt

Share this post


Link to post
Share on other sites

#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?

Share this post


Link to post
Share on other sites

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.


♡♡♡

.

eMyvnE

Share this post


Link to post
Share on other sites

#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.

*GERMAN* [note: you are not allowed to remove author / modified info from my UDFs]My UDFs:[_SetImageBinaryToCtrl] [_TaskDialog] [AutoItObject] [Animated GIF (GDI+)] [ClipPut for Image] [FreeImage] [GDI32 UDFs] [GDIPlus Progressbar] [Hotkey-Selector] [Multiline Inputbox] [MySQL without ODBC] [RichEdit UDFs] [SpeechAPI Example] [WinHTTP]UDFs included in AutoIt: FTP_Ex (as FTPEx), _WinAPI_SetLayeredWindowAttributes

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

'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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0