Sign in to follow this  
Followers 0

Structs and DllCall under x64

20 posts in this topic

Posted (edited)

Many people, and indeed many of the AutoIt includes rely on the fact that when using DllCall/DllStruct that you can store a POINTER in an INT. This is incorrect and you need to understand that this will break.

Edited by Jon

Share this post


Link to post
Share on other sites



Posted

Repost from the other DllCall sticky which may help as well.

Windows Datatype = DllCall Type

HANDLE = "ptr"

HDC = "ptr"

HFONT = "ptr"

HICON = "ptr"

HINSTANCE = "ptr"

HKEY = "ptr"

HMENU = "ptr"

HMODILE = "ptr"

HWND = "hwnd" or "ptr"

Using "int" for any of these may work under x86 but will not work going forwards to x64.

Share this post


Link to post
Share on other sites

Posted

Repost from the other DllCall sticky which may help as well.

Windows Datatype = DllCall Type

HANDLE = "ptr"

HDC = "ptr"

HFONT = "ptr"

HICON = "ptr"

HINSTANCE = "ptr"

HKEY = "ptr"

HMENU = "ptr"

HMODILE = "ptr"

HWND = "hwnd" or "ptr"

Using "int" for any of these may work under x86 but will not work going forwards to x64.

I'll start looking thru the includes that I work on including these Structures

"int HwndFrom" should be "ptr HwndFrom".

hwnd will still work for these correct?

I think I would prefer to use the hwnd but if I must i'll use ptr for HWND

Gary

Share this post


Link to post
Share on other sites

Posted

I'll start looking thru the includes that I work on including these Structures

"int HwndFrom" should be "ptr HwndFrom".

hwnd will still work for these correct?

I think I would prefer to use the hwnd but if I must i'll use ptr for HWND

Gary

From AutoIt's point of view and the new underlying code hwnd is identical to ptr so use either. I think hwnd was the only "pointer" type in DllCall then "ptr" was retro-fitted after DllStruct code was written much later. At the time I doubt I'd even heard about pointer differences on 64 bit <_<

Share this post


Link to post
Share on other sites

Posted

From AutoIt's point of view and the new underlying code hwnd is identical to ptr so use either. I think hwnd was the only "pointer" type in DllCall then "ptr" was retro-fitted after DllStruct code was written much later. At the time I doubt I'd even heard about pointer differences on 64 bit <_<

Submitted updated Structures.au3, will take some time to go thru all the includes and see if the same needs to be applied.

Gary

Share this post


Link to post
Share on other sites

Posted

Submitted updated Structures.au3, will take some time to go thru all the includes and see if the same needs to be applied.

Gary

Thanks <_<

Share this post


Link to post
Share on other sites

Posted

Thanks <_<

Looks like 50% or more of UDFs will be broken

This wrapper function which made it easier will now be cause of broken code:

; #FUNCTION# ====================================================================================================================
; Name...........: _SendMessage
; Description ...: Wrapper for commonly used Dll Call
; Syntax.........: _SendMessage($hWnd, $iMsg[, $wParam = 0[, $lParam = 0[, $iReturn = 0[, $wParamType = "int"[, $lParamType = "int"]]]]])
; Parameters ....: $hWnd       - Window/control handle
;                  $iMsg       - Message to send to control (number)
;                  $wParam     - Specifies additional message-specific information
;                  $lParam     - Specifies additional message-specific information
;                  $iReturn    - What to return:
;                  |0 - Return value from dll call
;                  |1 - $ihWnd
;                  |2 - $iMsg
;                  |3 - $wParam
;                  |4 - $lParam
;                  |<0 or > 4 - array same as dllcall
;                  $wParamType - Specifies what type of additional information
;                  $lParamType - Specifies what type of additional information
; Return values .: Success      - User selected value from the DllCall() result
;                  Failure      - @error is set
; Author ........: Valik
; Modified.......:
; Remarks .......:
; Related .......: _SendMessageA
; Link ..........;
; Example .......; Yes
; ===============================================================================================================================
Func _SendMessage($hWnd, $iMsg, $wParam = 0, $lParam = 0, $iReturn = 0, $wParamType = "int", $lParamType = "int")
    Local $aResult = DllCall("user32.dll", "long", "SendMessage", "hwnd", $hWnd, "int", $iMsg, $wParamType, $wParam, $lParamType, $lParam)
    If @error Then Return SetError(@error, @extended, "")
    If $iReturn >= 0 And $iReturn <= 4 Then Return $aResult[$iReturn]
    Return $aResult
EndFunc   ;==>_SendMessage

same would apply to _SendMessageA wrapper

Share this post


Link to post
Share on other sites

Posted

Ah yes. Under x64 WPARAM and LPARAM are defined as UINT_PTR and LONG_PTR which are 64bits (pointer size). Actually that's exactly how the "ptr" type works so there may be a work around there. I wonder if it's worth me adding native "wparam", "lparam" types that are the correct size...

Share this post


Link to post
Share on other sites

Posted

I'd prefer to add native type with the same name for UINT_PTR LONG_PTR but we already used them. I wonder how much code I'd break by renaming long_ptr to ptr_long. Probably not much.

Edit: There's about 3 uses of int_ptr in current includes. Probably easy enough to rename to ptr_int.

Edit2: Actually the current system is a bit limiting with only 3 pointer_to types defined, maybe I should just make it so that any type with * is a pointer_to. Like "*int". Yeah, that's probably more sensible.

Share this post


Link to post
Share on other sites

Posted

I'd prefer to add native type with the same name for UINT_PTR LONG_PTR but we already used them. I wonder how much code I'd break by renaming long_ptr to ptr_long. Probably not much.

Edit: There's about 3 uses of int_ptr in current includes. Probably easy enough to rename to ptr_int.

Edit2: Actually the current system is a bit limiting with only 3 pointer_to types defined, maybe I should just make it so that any type with * is a pointer_to. Like "*int". Yeah, that's probably more sensible.

4 includes:

Inet.au3

Misc.au3

SQLite.au3

Visa.au3

Share this post


Link to post
Share on other sites

Posted

In my working copy I've deprecated long_ptr, short_ptr and int_ptr. They will be removed from the documentation and then totally removed after the next public non-beta.

Use * after any parameter type to indicate that it is to be passed by reference. i.e. int* = int_ptr.

I've also added "wparam" and "lparam" types which change size depending on if you are running AutoIt x86 or x64.

Share this post


Link to post
Share on other sites

Posted (edited)

In my working copy I've deprecated long_ptr, short_ptr and int_ptr. They will be removed from the documentation and then totally removed after the next public non-beta.

Use * after any parameter type to indicate that it is to be passed by reference. i.e. int* = int_ptr.

I've also added "wparam" and "lparam" types which change size depending on if you are running AutoIt x86 or x64.

I haven't used any of those 3 so i'm okay there.

Will just need to remove them from the help document for the _SendMessage functions for those that I just submitted. <_<

I'll wait to see the new types before making the final change.

Edited by GaryFrost

Share this post


Link to post
Share on other sites

Posted

Might be a stupid question but...

In the documentation on DllStructCreate ptr and hwnd are still defined as 32bit.

but if i would guess they are 64bit on x64, am i right?

Share this post


Link to post
Share on other sites

Posted

Might be a stupid question but...

In the documentation on DllStructCreate ptr and hwnd are still defined as 32bit.

but if i would guess they are 64bit on x64, am i right?

Yeah, that's right.

Actually now that variants can store pointers natively I could have done without DllCallbackGetPtr but I left it in for symmetry with DllStruct... Thinking about it more, DllStruct uses an abomination of an "array" type for storing it's data which adds unneccessary code to our variant class - it should just be stored as a handle to a structure in memory. I should probably fix that too but I get the fear when I go into the DllStruct code.

Share this post


Link to post
Share on other sites

Posted

I should probably fix that too but I get the fear when I go into the DllStruct code.

Don't get shakey now Jon. :P;)

Swimming in deep water is no different than swimming in shallow water.

Share this post


Link to post
Share on other sites

Posted

Jon, after doing all the work in assembly you've done lately, getting to work with pointers in C(++) should be a right treat.

Share this post


Link to post
Share on other sites

Posted

In my working copy I've deprecated long_ptr, short_ptr and int_ptr. They will be removed from the documentation and then totally removed after the next public non-beta.

Use * after any parameter type to indicate that it is to be passed by reference. i.e. int* = int_ptr.

I've also added "wparam" and "lparam" types which change size depending on if you are running AutoIt x86 or x64.

Oh, the wparam and lparam types are used primarily in SendMessage calls. So any SendMessage that use "int" for these will fail on x64.

Share this post


Link to post
Share on other sites

Posted

Oh, the wparam and lparam types are used primarily in SendMessage calls. So any SendMessage that use "int" for these will fail on x64.

I'll have to look into fixing for that.

Share this post


Link to post
Share on other sites

Posted

since the last post has been a while ago, I would like to know if this issue fixed in the latest beta?

Thanks for any info!

Share this post


Link to post
Share on other sites

Posted

since the last post has been a while ago, I would like to know if this issue fixed in the latest beta?

Thanks for any info!

Been fixed for a while.

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

  • Recently Browsing   0 members

    No registered users viewing this page.