Jump to content

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Find out more here. X
X


Photo

Structs and DllCall under x64


  • Please log in to reply
19 replies to this topic

#1 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 31 October 2007 - 10:47 AM

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, 22 June 2012 - 12:08 PM.








#2 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 31 October 2007 - 11:09 AM

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.

#3 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 31 October 2007 - 12:29 PM

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.


#4 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 31 October 2007 - 12:47 PM

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

#5 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 31 October 2007 - 02:13 PM

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.


#6 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 31 October 2007 - 02:33 PM

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

#7 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 31 October 2007 - 04:32 PM

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:

AutoIt         
; #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.


#8 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 31 October 2007 - 04:48 PM

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

#9 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 31 October 2007 - 05:00 PM

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.

#10 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 31 October 2007 - 05:11 PM

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.


#11 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 01 November 2007 - 11:20 AM

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.

#12 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 01 November 2007 - 11:29 AM

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, 01 November 2007 - 11:32 AM.

SciTE for AutoItDirections for Submitting Standard UDFs

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


#13 piccaso

piccaso

    Rock me, Amadeus!

  • MVPs
  • 893 posts

Posted 21 November 2007 - 06:38 PM

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?
Posted Image CoProc Multi Process Helper libraryTrashBin.nfshost.com store your AutoIt related files here!AutoIt User Map

#14 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 22 November 2007 - 09:08 AM

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.

#15 GEOSoft

GEOSoft

    Sure I'm senile. What's your excuse?

  • MVPs
  • 10,573 posts

Posted 22 November 2007 - 05:24 PM

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!"

#16 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 22 November 2007 - 09:09 PM

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

#17 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,619 posts

Posted 23 November 2007 - 10:13 AM

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.

#18 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 23 November 2007 - 03:07 PM

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.


#19 oliver369

oliver369

    Seeker

  • Active Members
  • 13 posts

Posted 31 January 2008 - 12:07 PM

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!

#20 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 01 February 2008 - 10:55 AM

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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users