Search the Community

Hi guys, Bitwise operations in Autoit is possible only till 32 bit integers, but sometimes WinAPI requires to process 64 bit vectors... so? So you can use this little UDF to handle properly those integers! Func _BitAND64($iValue1, $iValue2) If Not ((VarGetType($iValue1) = "Int64") Or (VarGetType($iValue2) = "Int64")) Then Return BitAND($iValue1, $iValue2) $iValue1 = __DecToBin64($iValue1) $iValue2 = __DecToBin64($iValue2) Local $aValueANDed[64], $i For $i = 0 To 63 $aValueANDed[$i] = ($iValue1[$i] And $iValue2[$i]) ? 1 : 0 Next Return __BinToDec64($aValueANDed) EndFunc ;==>_BitAND64 Func _BitOR64($iValue1, $iValue2) If Not ((VarGetType($iValue1) = "Int64") Or (VarGetType($iValue2) = "Int64")) Then Return BitOR($iValue1, $iValue2) $iValue1 = __DecToBin64($iValue1) $iValue2 = __DecToBin64($iValue2) Local $aValueORed[64], $i For $i = 0 To 63 $aValueORed[$i] = ($iValue1[$i] Or $iValue2[$i]) ? 1 : 0 Next Return __BinToDec64($aValueORed) EndFunc ;==>_BitOR64 Func _BitXOR64($iValue1, $iValue2) If Not ((VarGetType($iValue1) = "Int64") Or (VarGetType($iValue2) = "Int64")) Then Return BitXOR($iValue1, $iValue2) $iValue1 = __DecToBin64($iValue1) $iValue2 = __DecToBin64($iValue2) Local $aValueXORed[64], $i For $i = 0 To 63 $aValueXORed[$i] = (($iValue1[$i] And (Not $iValue2[$i])) Or ((Not $iValue1[$i]) And $iValue2)) ? 1 : 0 Next Return __BinToDec64($aValueXORed) EndFunc ;==>_BitXOR64 Func _BitNOT64($iValue) If Not (VarGetType($iValue) = "Int64") Then Return BitNOT($iValue) $iValue = __DecToBin64($iValue) For $i = 0 To 63 $iValue[$i] = Not $iValue[$i] Next Return __BinToDec64($iValue) EndFunc ;==>_BitNOT64 Func __DecToBin64($iDec) Local $tDec = DllStructCreate("int64 num"), $aBin[64], $bBit, $i $tDec.num = $iDec For $i = 0 To 63 $bBit = (Mod($tDec.num, 2) ? 1 : 0) $aBin[63 - $i] = $bBit $tDec.num = Floor($tDec.num / 2) Next Return $aBin EndFunc ;==>__DecToBin64 Func __BinToDec64($aBin) Local $tDec = DllStructCreate("int64 num"), $i If $aBin[0] Then $tDec.num += 0x8000000000000000 ;2^63 = 9223372036854775808, but for Autoit the world ends at 9223372036854775807 (2^63 - 1) For $i = 1 To 63 If $aBin[$i] Then $tDec.num += 2 ^ (63 - $i) Next Return $tDec.num EndFunc ;==>__BinToDec64 If you are working with unsigned 64 bit integers and these functions return a negative value, don't worry, bitwise operations come out well, but Autoit manages all numbers as signed integers.

Hi! Looking for working code to get full path of process - both 32 & 64 bit. I tryed this bellow, but it works only for 32-bit processes, even if compiled for x64... Thanx for suggestions! Func _ProcessGetPath($vProcess) ;get the program path done by MrCreatoR Local $iPID = ProcessExists($vProcess) If NOT $iPID Then Return SetError(1, 0, -1) Local $aProc = DllCall('kernel32.dll', 'hwnd', 'OpenProcess', 'int', BitOR(0x0400, 0x0010), 'int', 0, 'int', $iPID) If NOT IsArray($aProc) OR NOT $aProc[0] Then Return SetError(2, 0, -1) Local $vStruct = DllStructCreate('int[1024]') Local $hPsapi_Dll = DllOpen('Psapi.dll') If $hPsapi_Dll = -1 Then $hPsapi_Dll = DllOpen(@SystemDir & '\Psapi.dll') If $hPsapi_Dll = -1 Then $hPsapi_Dll = DllOpen(@WindowsDir & '\Psapi.dll') If $hPsapi_Dll = -1 Then Return SetError(3, 0, '') DllCall($hPsapi_Dll, 'int', 'EnumProcessModules', _ 'hwnd', $aProc[0], _ 'ptr', DllStructGetPtr($vStruct), _ 'int', DllStructGetSize($vStruct), _ 'int_ptr', 0) Local $aRet = DllCall($hPsapi_Dll, 'int', 'GetModuleFileNameEx', _ 'hwnd', $aProc[0], _ 'int', DllStructGetData($vStruct, 1), _ 'str', '', _ 'int', 2048) DllClose($hPsapi_Dll) If NOT IsArray($aRet) OR StringLen($aRet[3]) = 0 Then Return SetError(4, 0, '') Return $aRet[3] EndFunc

During the AutoIt installer it gives the option to install 32bit or 64bit tools. Most systems these days are 64bit. Should I be creating autoit programs for both? Do autoit compiled applications really benefit from being 64 vs 32? If compiled for 64bit will there be a problem using the mass of UDFs available or does that not matter? Under what circumstances is compiling for 64bit going to make my program run better? Are there any downsides? Any differences in how I develop, use UDFs, DLLs, anything? Also, if I install 64bit Autoit tools can I still compile for 32bit and what about IE browser controls will they then be the 64bit IE? Thanks.

Hello, I will put it as simple as possible Why this code runs perfectly on 32bit and it fails on 64bit? Local $hWND = WinGetProcess("[CLASS:LSS_app]") ConsoleWrite($hWND & @LF) Local $hModuleList = _WinAPI_EnumProcessModules($hWND) If @error Then ConsoleWrite("Error: " & @error & @LF) For $i = 0 To $hModuleList[0][0] - 1 ;~ If StringInStr($hModuleList[$i][1], "sysCap64.dll") Then ConsoleWrite($hModuleList[$i][0] & @LF) ;~ EndIf Next As the title says EnumProcessModules returns error 10 which I have no clue what it is. It must be something with autoit or my lack of coding because a similar code in C# will work like a charm on both x86 and x64 Process[] Processes = Process.GetProcessesByName("winLSS64Cap"); Process nProcess = Processes[0]; Handle = OpenProcess(0x10, true, (uint)nProcess.Id); for(int i = 0; i < nProcess.Modules.Count; i++) { Console.WriteLine(nProcess.Modules[i].ModuleName); }

hello, i have a script which can handle huge data. i feed it with textfiles, it reads each line into array, then compare the lines, do some string operations. this all happens in a for.to.next loop. the script only use 15% cpu of my 8core.amd can i force the script to use more cpuload an therefore being faster? would it make a speed difference to compile it as 64bit exe on 64bit systems? thank you for commemts :)

As documented here, it is possible to bypass registry redirection when running a 32bit application on a 64bit Windows installation, using HKLM64 or HKCR64. I quote: In this thread, >this feature's existence is denied. Also, if this feature exists and works, does it work on both production and beta? And can I also specificy HKEY_LOCAL_MACHINE64 and HKEY_CLASSES_ROOT64 instead of HKLM64 and HKCR64?

I had a problem getting a connection to "SQL Server" on 64 bit PCs (running XP) even though 32 bit PCs connected easily. Even compiling for 32bit was (initially) insufficient and to get it working at all on a 64bit PC, I ended up forcing its use of TCP/IP protocol by specifying a port number (that is apparently picked up as a default by 32 bit PCs once "SQL Server" has been added with it configured in "Control Panel --> Administrative Tools --> Databases(ODBC) --> Add --> SQL Server --> Client Configuration" This worked for me on a 64bit PC, but only when compiled in 32bit: $sqlCon = ObjCreate("ADODB.Connection") $sqlCon.Open("DRIVER={SQL Server};SERVER=name.of.server,port_number;DATABASE=name_of_database;UID=logon_ID;PWD=password;") If @error Then MsgBox(0, "Problem", "SQL Connection Failed") Else MsgBox(0, "Success", "SQL Connection OK") EndIf Also, I found that the "SQL Server" needed to be added to the Databases(ODBC) as shown above (and tested OK) before the AutoIT script worked but (strangely) it could be later removed from Databases(ODBC) and it still worked (perhaps it just needed to setup defaults). Does anyone know how I can get the above working when compiled in 64bit too? On a X64 bit PC, the above script it will fail to work with: #AutoIt3Wrapper_UseX64=y but works OK with #AutoIt3Wrapper_UseX64=n

Hello - I've got a situation for which I'd like to get some insight from those more knowledgeable than I: I have an Autoit application that I deploy as an executable. I can be deployed (I hope) to any level of Windows (2K - 8) both 32 and 64 bit. I has a sub-component that is a java app (BaseX XML database). I develop on a Win 7 Pro 64bit machine. Just recently (last 4 months), I had not touched it since its last version and I started coding/testing again for another release. It no longer worked! I'd not changed the code but both the compiled and non-compiled versions now failed on my development machine. Banged my head for quite a while to figure out what the deal was! I finally narrowed it all down to: This command: Local $pid = run(@ComSpec & " /c " & "java -cp BaseX.jar org.basex.BaseXServer","C:\Users\David\DOCUME~1\OPENSO~3\TESTIN~1\OPENSO~1\BaseX",@SW_HIDE,$STDERR_MERGED) ;starts the basex server to facilitate queries worked when I commented out: #AutoIt3Wrapper_UseX64=n when it was NOT commented out (I had it uncommented to create 32bit executables for multi-architecture deployment) I received this message from the run command: 'java' is not recognized as an internal or external command, operable program or batch file. I've uninstalled ALL of java and then just reinstalled the most recent version to see what that would do - same behavior. I'm guessing that perhaps java, in more recent versions, has changed the way it is deployed for distinguishing between 32 and 64 bit machines. So it would appear that my tactic to develop and deploy as a single 32-bit application that would cover all 32 and 64 bit machines will no longer work. Is my only choice to create/use an installer that installs EITHER the 32 bit or 64 bit executable? Or is there some way to change my Run command such that it finds "java" no matter how it is intalled on my machine? Thanks!

_GUICtrlTab_FindTab($currentprinter & " Printing Preferences", "Page Setup") On all 64bit systems that I have testes this on, it seems to fail or return -1. I compiled the scripts with beta 3.3.9.4 I am trying to grab the tab control from running rundll32 printui.dll,PrintUIEntry /e /n What am I doing wrong here?