Sign in to follow this  
Followers 0

Structs and DllCall under x64

20 posts in this topic

#1 ·  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

"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites



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


"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

#3 ·  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


SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

Share this post


Link to post
Share on other sites

#4 ·  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 <_<

"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

#5 ·  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


SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

Share this post


Link to post
Share on other sites

#6 ·  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 <_<

"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

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


SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

Share this post


Link to post
Share on other sites

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


"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

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


"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

#10 ·  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


SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

Share this post


Link to post
Share on other sites

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


"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

#12 ·  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

SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

Share this post


Link to post
Share on other sites

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


CoProc Multi Process Helper libraryTrashBin.nfshost.com store your AutoIt related files here!AutoIt User Map

Share this post


Link to post
Share on other sites

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


"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

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


GeorgeQuestion about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.*** The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else."Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

#16 ·  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

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

"If you can post in the forum, that there is an issue with the forum, then the forum is working spectacularly. All else is cosmetics, and can totally suck it."
- boththose, April 2015.

Share this post


Link to post
Share on other sites

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


SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

Share this post


Link to post
Share on other sites

#19 ·  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

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


SciTE for AutoItDirections for Submitting Standard UDFs


Don't argue with an idiot; people watching may not be able to tell the difference.

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