Structs and DllCall under x64

[Jon]

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 June 22, 2012 by Jon

[Jon]

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.

[GaryFrost]

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

[Jon]

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

[GaryFrost]

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

[Jon]

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

[GaryFrost]

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

[Jon]

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

[Jon]

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.

[GaryFrost]

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

[Jon]

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.

[GaryFrost]

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 November 1, 2007 by GaryFrost

[piccaso]

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?

[Jon]

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.

[GEOSoft]

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

Don't get shakey now Jon.

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

[Valik]

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

[Jon]

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.

[GaryFrost]

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.

[oliver369]

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!

[GaryFrost]

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.