Custom Query (3919 matches)

If I add a named resource to AutoItSC.bin with ResHacker, then compile a script, the resource name is mangled. For example:

ResHacker -add AutoItSC.bin, AutoItSC.bin, mydata.dat, rcdata, MYDATA, 1033

Viewing the resulting AutoItSC.bin in ResHacker:

RCData -> MYDATA -> 1033

Viewing the compiled EXE in ResHacker:

RCData -> M( -> 1033
(or some other mangled name)

The actual data seems intact. The same problem happens with named resources of types BITMAP and ICON as well. I do not know if aut2exe_x64 has this problem or not.

Considering the discussion a few weeks ago about BitShift being a *signed* shift in AutoIt, shouldn't the _WinAPI_HiWord function, and indeed all UDF functions where a DWORD needs to be split into hi and lo words by any means (the _WinAPI_HiWord function or manually via BitShift), be changed accordingly:

Func _WinAPI_HiWord($iLong)
    Return BitAND(BitShift($iLong, 16), 0xFFFF)
EndFunc   ;==>_WinAPI_HiWord

While an error likely won't occur very often, this is the only way to assure we are getting the correct hi word result, unless AutoIt changes the way it does BitShift to be unsigned.

I understand if you want to forgo this change in favor of waiting until AutoIt's internal number handling is revamped, but it is a viable patch in the meantime.

Parameters of type "float" are mangled when passed to DllCallbackRegister() callback functions under x64. The following script demonstrates the problem:

Local $hCallback = DllCallbackRegister("Callback", "none", "double;float;")
Local $pCallback = DllCallbackGetPtr($hCallback)
DLLCallAddress("none", $pCallback, "double", 1234, "float", 1234)

Func Callback($fDouble, $fFloat)
	ConsoleWrite("Double: " & $fDouble & @CRLF)
	ConsoleWrite("Float: " & $fFloat & @CRLF)
EndFunc

The double output is correct. Float output is mangled and changes with each invocation.