DllCall description Topic is solved

Discuss the future of the AutoHotkey language
User avatar
vvhitevvizard
Posts: 211
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: DllCall description

13 Jan 2019, 03:24

nnnik wrote:
12 Jan 2019, 17:20
So no you dont get valid 32 bit results.
AHK's int32 data type should not use bits 32..63 and lower bits 0..31 contain a valid 32 bit result. :D
User avatar
nnnik
Posts: 3685
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: DllCall description

13 Jan 2019, 03:36

vvhitevvizard wrote:
13 Jan 2019, 03:24
AHK's int32 data type should not use bits 32..63 and lower bits 0..31 contain a valid 32 bit result. :D
I'm not quite sure what you mean here.
You said that using Ptr instead of Int would be fine on 64 bit, since the 32 bit values will be fine. But no they won't be fine.
So I don't understand this remark here as AHKs own 32 bit capabilities are never used inside the DLLCall scenario we just played through.

Or are you finally agreeing that the default return type should be Int?
Recommends AHK Studio
Helgef
Posts: 3418
Joined: 17 Jul 2016, 01:02
Contact:

Re: DllCall description

13 Jan 2019, 03:40

@ vvhitevvizard
Ahk variables uses only two number types, int64 and double, it's the same on all builds.
User avatar
vvhitevvizard
Posts: 211
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: DllCall description

13 Jan 2019, 12:12

Helgef wrote:
13 Jan 2019, 03:40
Ahk variables uses only two number types, int64 and double, it's the same on all builds.
Alright, the matter relates only to the NumGet/NumPut/DllCall operands. Thx for the correction! :thumbup:
nnnik wrote:
13 Jan 2019, 03:36
Or are you finally agreeing that the default return type should be Int?
At the moment, scripts that use DllCall w/o retval declaration and expect ptr will fail on rare occasions due to ptr being truncated with AHK64.

Now let's imagine, the default retval size is changed from int (int32) to int64, scripts that run with AHK64 and expect int (int32) will either fail instantly in most cases (easy to pinpoint) if the callee doesn't clean up the upper DWORD or will work w/o issues if the callee does clean up full rax before returning eax.

And I've seen quite a few system DLL functions that do xor rax, rax (clean up the whole rax) just before the final retval assignment even if they r expected to return just eax or even ax, al.

Anyways, I would just love the three NumGet/NumPut/DllCall to have a unified default retval. Easy to memorize.
User avatar
nnnik
Posts: 3685
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: DllCall description

13 Jan 2019, 14:44

Now let's imagine, the default retval size is changed from int (int32) to int64, scripts that run with AHK64 and expect int (int32) will either fail instantly in most cases (easy to pinpoint) if the callee doesn't clean up the upper DWORD or will work w/o issues if the callee does clean up full rax before returning eax.
Thats an assumption - it might or might not be hard to spot. Just like the inverse might or might not be hard to spot.
And I've seen quite a few system DLL functions that do xor rax, rax (clean up the whole rax) just before the final retval assignment even if they r expected to return just eax or even ax, al.
Thats relying on undocumented features and continuing the current bad practice of incorrectly defining the return type.
Anyways, I would just love the three NumGet/NumPut/DllCall to have a unified default retval. Easy to memorize.
I think the best option here is to force the users to define a data type in all three cases and remove a default type.
That would fix the underlying problems instead of making it easier for one group of people.
Recommends AHK Studio

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 2 guests