Custom Query (3921 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (391 - 393 of 3921)

Ticket Resolution Summary Owner Reporter
#1283 Fixed aut2exe_x64 Ignores /pack Parameter When Compiling x86 Executable Valik wraithdu
Description

When run from the command line (or from AutoIt3Wrapper) on an x64 system, aut2exe_x64.exe ignores the /pack parameter when compiling an x86 executable and does not run UPX. Running aut2exe_x64.exe normally (GUI mode) allows UPX packing when compiling as x86.

aut2exe_x64.exe /in script.au3 /comp 4 /pack
#1284 Fixed minor fold hickup. Jos anonymous
Description
; fold hickup.
; + edit to trigger comment or above.
; - add character
; - fold 'then..endif'.
; + fold marker and 'random(1)' line disapear.
; - add other single-edit to active fold marker again, and fold + unfold to restore normal state.
If 0 And _
		0 And _
		0 And _;trigger, comment after multiline tag, preferably last.
		0 Then
	Random(1)
	Random(2)
	Random(2)
EndIf
#1285 Fixed Unexpected result when using BitShift Valik ProgAndy
Description

BitShift seems to return a wrong result if the input is a 64bit integer variable. In previous AutoIt versions it used to cut all numbers to 32bit, but now the 64-bit integer is shifted over the whole 64bit range, which leads to unexpected results.

;#BETA
$iNum1 = 4294967295
$iNum2 = 0xFFFFFFFF
$iNum3 = -1

MsgBox(0, 'Number tests', "$iNum1 = 4294967295 	-> " & $iNum1 & @CRLF & _
				"$iNum2 = 0xFFFFFFFF 	-> " & $iNum2 & @CRLF & _
				"$iNum3 = -1 		-> " & $iNum3 & @CRLF & @CRLF & _
				"$iNum1 = $iNum2 	-> " & ($iNum1 = $iNum2) & @CRLF & _
				"$iNum1 = $iNum3 	-> " & ($iNum1 = $iNum3) & @CRLF & _
				"$iNum3 = $iNum3 	-> " & ($iNum3 = $iNum3) & @CRLF & @CRLF & _
				"I expected $iNum1 and $iNum2 to be equal, since 0xFFFFFFFF is hex notation for 4294967295" _
				)

MsgBox(0, "+/- BitShift", "BitShift($iNum1, 16) -> " &  BitShift($iNum1, 16) & @CRLF & _ 
			"BitShift($iNum2, 16) -> " & BitShift($iNum2, 16) & @CRLF & _ 
			"BitShift($iNum3, 16) -> " & BitShift($iNum3, 16) & @CRLF & _
			"The BitShift for $iNum1 seems to be incorret." )

When declaring the variables for the example i noticed the different interpretation of 0xFFFFFFFF and its decimal representation (4294967295). I don't know if this is a bug and it exists in previous versions of AutoIt, too. 4294967295 is treated as a 64bit integer and keeps its positive value, whereas The Hex is treated as signed 32bit which results in -1. So the identical values can not be testet as equal

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.