Smarter dllcall()

[arcticir]

The recent progress of V2 is surprising
I found that PY calls DLL without specifying the parameter type. This is very convenient, using DLL becomes very simple. So can we achieve the same effect in V2?

[lexikos]

What is PY?

There are two ways to avoid specifying the parameter type:

1. Use only predefined functions, for which the parameter types are known.
2. Make assumptions about the parameter type.

In neither case is the actual function call smarter, but one might be more or less efficient, (un)safe, etc.

As far as I can tell,
Python's CFFI uses #1. It takes a full C definition of a function and produces a function object. In some cases it invokes a C compiler.
Python's ctypes uses #1 or #2. If you don't tell it what arg types the function has, it makes assumptions based on what values you pass.

For #1, you can just write wrapper functions, or use AutoHotkey_H and #DllImport.

For #2, if we assume that the parameter should be "str" for any string, "double" for any floating-point number and "ptr" otherwise, you won't have to specify the type, but:

• Functions that do not accept a UTF-16 string would require you to manually convert the string before passing it (or call a function that we add for that purpose; e.g. AStr(value)).
• There would be no way to specify that the parameter is for output. Instead, you will have to pass a buffer and read from it afterward.
• You would need to manually reinterpret the return value as the appropriate data type, or find a new way to specify the return type that isn't ambiguous with a parameter value.
• You would not be able to specify other types without the use of additional functions (i.e. converting the value to a "ptr").

It does not make using a dll simpler. If the parameter types aren't predefined, you must be even more careful to pass the appropriate type of value, or do even more work to convert values to a type appropriate for the function.

It can be done in script, but not very efficiently.

[vvhitevvizard]

What is PY?

Its definitely .py Python

I found that PY calls DLL without specifying the parameter type. This is very convenient, using DLL becomes very simple. So can we achieve the same effect in V2?

It was partially tackled in AHK_H V2 branch (by @HotKeyIt) with DllCall's equivalent named DynaCall.

Code: Select all

DllCall	DynaCall equivalent
Int	i
Str	s
AStr	a
WStr	w
Short	h
Char	c
Float	f
Double	d
PTR	t
Int64	i6

HotKeyIt happened to generate many brilliant ideas, but I prefer Lexikos's mainstreamed AHK V2 branch, yet I would like to have abbreviated types for dllcall. Oh, and some abbr. (like i6) look awkward: int64 -> i64, ptr -> p, ptrp (ptr*) -> pp
DllCall could actually support both notations - regular and abbreviated at the same time for compatibility sake.

[nnnik]

Instead of i64 maybe l for long?

[vvhitevvizard]

Instead of i64 maybe l for long?

yeah that one is even better.
Sorry for necroposting but the current dllcall type strings take a lot of space.

[lexikos]

No, it isn't better. long and long int are 32-bit (on all the platforms AutoHotkey runs on).

If you want to save characters, there are numerous solutions that can be implemented in script, with DllCall.Bind, now without the need for %% or .Call. The cost of calling via BoundFunc is negligible even for very small/fast functions like MulDiv, and would only become less significant with larger functions. If the alternative DllCall wasn't automatically optimized by having its function address resolved at load time, doing that manually and binding the address will give a better result.

[vvhitevvizard]

My bad, It was a hasty reply w/o a proper thinking for a moment forgetting that 32bit "long" is opposite to 16-bit "short" well, it might be q (qword from assembler language) then.

with DllCall.Bind, now without the need for %% or .Call. The cost of calling via BoundFunc is negligible even for very small/fast functions like MulDiv, and would only become less significant with larger functions.

Thank u for reminding of this feature! I might rethink of rewriting dllcalls into shorthanded v128+ function call variants!
PS: It would be great if the documentation would have such an example. Default dllcall syntax is somewhat awkward. )

[nnnik]

No, it isn't better. long and long int are 32-bit (on all the platforms AutoHotkey runs on).

If you want to save characters, there are numerous solutions that can be implemented in script, with DllCall.Bind, now without the need for %% or .Call. The cost of calling via BoundFunc is negligible even for very small/fast functions like MulDiv, and would only become less significant with larger functions. If the alternative DllCall wasn't automatically optimized by having its function address resolved at load time, doing that manually and binding the address will give a better result.

Of course in C long is not a 64 bits integer.
In most other languages it is though - to the point where that notion has become a convention.
I only checked Java and Visual Basic for now but I could probably find a selection of languages that choose to use long for 64 bit integers.

Tying AutoHotkey to C conventions just because it is written in C++ means that it needs to be rewritten to get rid of poor design choices made in C.
So I actually do not think that thats an argument.

So in the end it comes down to your personal preference - which is fine imo but there is no need to sugarcoat it.

[lexikos]

No, it is not a matter of preference. Long is a bad choice because it has different meanings in various languages (even in different versions of the same language, such as VB, and different platforms with the same language), it has no particular meaning to the uninitiated, and it generally means a 32-bit integer in documentation for the majority of functions that DllCall is used with.