Search the Community
Showing results for tags '32bit'.
-
I'm using the following: Autoit 3.3.14.5 newly installed Beta 3.3.15.5 SQlite version 3380000 aka 3.38.0 I put sqlite3.dll and sqlite3_x64.dll in C:\Windows\System32 since many scripts depend on them. I extended the output of _SQLite_Startup() with: ConsoleWrite("@AutoItX64 " & @AutoItX64 & @CRLF) ConsoleWrite("$sDll_Filename " & $sDll_Filename & @CRLF) ConsoleWrite("_SQLite_LibVersion=" & _SQLite_LibVersion() & @CRLF) Also using the script from https://www.autoitscript.com/autoit3/docs/libfunctions/_SQLite_Startup.htm for testing. >Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3.exe "R:\Download\aasdf.au3" @AutoItX64 0 $sDll_Filename sqlite3.dll _SQLite_LibVersion=0 >Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3_x64.exe "R:\Download\aasdf.au3" @AutoItX64 1 $sDll_Filename sqlite3_x64.dll _SQLite_LibVersion=3.38.0 >Running:(3.3.15.5):C:\Program Files (x86)\AutoIt3\Beta\autoit3.exe "R:\Download\aasdf.au3" @AutoItX64 0 $sDll_Filename sqlite3.dll _SQLite_LibVersion=0 >Running:(3.3.15.5):C:\Program Files (x86)\AutoIt3\Beta\autoit3_x64.exe "R:\Download\aasdf.au3" @AutoItX64 1 $sDll_Filename sqlite3_x64.dll _SQLite_LibVersion=3.38.0 Why doesn't it work in 32bit, despite me having the 32bit sqlite.dll? Autoit urges running scripts in 32bit mode and Scite starts scripts just in 32bit mode without the flag? With #AutoIt3Wrapper_UseX64=Y it just works, both normal Autoit and beta! sqlite3.dll sqlite3_x64.dll
-
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'm making program(using AutoIt) that would connect to server. I need help converting numbers to VarInt. About VarInt: About VarInt: https://developers.google.com/protocol-buffers/docs/encoding#varints I can't understand how VarInt works, maybe somebody could help me? 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); }
-
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?
-
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!