AutoIT installation fails to use 64-bit versions on 64-bit OS Win 2008

[rboucher]

When I've installed AUTOIT on either real or virtualized version of Windows 2008, the 64-bit versions of the following components are not used. The 64-bit versions are present, but are not run by the AutoIT interface.

C:\Program Files (x86)\AutoIt3\Aut2Exe directory

Au3Info.exe
AutoIt3.exe

C:\Program Files (x86)\AutoIt3\Aut2Exe directory

Au2exe.exe
AutoITSC.bin

There may be others as I have not tried using AutoITx.

A simple rename using the _64x version of these files in these directories fixes the issue. That is

AutoIt3.exe ==> renamed ==> AutoIt3_x32.exe
AutoIt3_x64.exe ==> renamed ==> AutoIt3.exe

Side effects
Programs look like they are run and compiled correctly, but bugs appear in APIs involving use of text. RegRead and ControlTreeView are two examples.

Following code in any script will show this problem.

ConsoleWrite("OS Version is " & @OSARCH & @CRLF)
ConsoleWrite("AutoIT 64bit Version Running? 1 if so -->" & @AutoItX64 & @CRLF)

; if you add the key first, will fail on 64 bit OS but succeed on 32 bit. Works fine once exx rename is done.

$RegKeyExists = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName", "") ;default value

Run("c:\windows\system32\compmgmt.msc")
$WindowUp = WinWaitActive("Computer Management","", 10)
If NOT $WindowUp Then
$WindowHandle = WinGetHandle("Computer Management")
$treeviewRolesHandle = ControlGetHandle ( "Computer Management", "", "[ID:12785]")
ConsoleWrite('Window Handle ' & $WindowHandle & ' Tree view role handle' & $treeviewRolesHandle & @crlf)
$answer = ControlFocus("Computer Management", "", 12785)
Sleep(1000)

;Works regardless
ControlTreeView ("Computer Management", "", $treeviewRolesHandle, "Expand", "#0")
ControlTreeView ("Computer Management", "", $treeviewRolesHandle, "Expand", "#0|#0")
ControlTreeView ("Computer Management", "", $treeviewRolesHandle, "Expand", "#0|#0|#1")

; Does not work due to use of 32-bit exes. once exe's replaced with 64-bit versions, code works
ControlTreeView ("Computer Management", "", $treeviewRolesHandle, "Select", "Computer Management (Local)|System Tools|Device Manager")

[Valik]

Do not report two separate issues in the same ticket. Your first problem may or may not be an issue. The second problem is not an issue. A 32-bit process accessing certain registry keys has them reflected to another key entirely. In short, the 32-bit and 64-bit processes aren't reading the same key even though you think they are. Turn off reflection or access the key by it's real path, not the reflected path.

Now, as for your first problem, the path gives me a clue that you didn't install correctly for 64-bit (or there is an issue in installing for 64-bit). I don't think the program would be in "Program Files (x86)" if it was properly installed in 64-bit mode.

[Jpm]

Autoit install under "Program Files (x86)" both X86 and X64 versions.
When you install you get a window which ask you to configure the x64 tools, choose Yes.
If you don't like "Program Files (x86)" you can choose later on another one. Remember that the x86 will also be installed under.
When clicking on a .au3 file you will get x64 version running

[rboucher]

The two issues I reported with RegRead and ControlTreeview are how I found the problem after hours of trouble shooting why they didn't work, but they are not the main issue. Sorry if I clouded things including them.

On install.
I did choose "yes" to install the 64-bit versions of tool. Didn't matter. The install detects that I'm on a 64-bit OS, but it does not correctly install the 64 bit versions. When I run AutoIT from the installed icons, it's using the 32-bit versions for everything.

On what directory is uses (Program Files (x86) - I'm just going where the start menu icons are pointing. As I mentioned in the bug, it does put the 64-bit versions of the program files in the same directory.

And I've installed this 6 times with the same exact results.

So this seems an install problem and not user error.

[Jpm]

Replying to rboucher:

The two issues I reported with RegRead and ControlTreeview are how I found the problem after hours of trouble shooting why they didn't work, but they are not the main issue. Sorry if I clouded things including them.

On install.
I did choose "yes" to install the 64-bit versions of tool. Didn't matter. The install detects that I'm on a 64-bit OS, but it does not correctly install the 64 bit versions. When I run AutoIT from the installed icons, it's using the 32-bit versions for everything.

On what directory is uses (Program Files (x86) - I'm just going where the start menu icons are pointing. As I mentioned in the bug, it does put the 64-bit versions of the program files in the same directory.

And I've installed this 6 times with the same exact results.

So this seems an install problem and not user error.

How can you proof that the install is wrong?
what is the result of the execution of the script I post above.
under Vista the start menu is a the start menu.png I just post. You can see that both X86 and X64 can be exercised.

[rboucher]

On second thought - It's possible that it could be the script editor install.

When I run your script I get the following message box in the attached PNG

I'm quite clear on the PNG that you posted. I'm chosing the x64 option every time I install. But when I'm using SciTE, it's running the 32-bit versions. The start menu icons for AutoIT are pointing to _X64, but I'm not using those. I'm doing everything from inside SciTE

The install is in the Program Files (x86) directory even if I choose X64 option.

I do this

install AutoIT
install extended version of the SciTE4AutoIT3 script editor.

(There are no options in the script install that I can see about using x64)

I go to Program Files
There is no AutoIT3 folder
I go to Program Files (x86)
There's the AutoIT3 folder.
I run the script editor. There are two links to it in the start menu, but both point to same place. c:\Program Files (x86)\AutoIt3\SciTE\SciTE.exe

I know it's wrong because it's invoking the 32-bit version when I'm trying to run it. The X64 versions have a different filesize.

My checking code below tells me when there is a mismatch.

ConsoleWrite("OS Version is " & @OSARCH & @CRLF)
ConsoleWrite("AutoIT 64bit Version Running? 1 if so -->" & @AutoItX64 & @CRLF)

When I run these with a fresh install, @AutoITX64 = 0.

If you want a video of the install as I'm doing it that's fine too. That would be from download from the site to install to execution.

[rboucher]

Results of running JPMs script

[rboucher]

Install directories for AutoIT even when chosing 64-bit option

[rboucher]

SciTE running the 32-bit version of AutoIT while on Win2008

[Jpm]

In fact if you run from Scite you always exercised the 32 bit version.
Il almost sure that if you run the script from the explorer you will get the 64 bit version by default
I am not sure that tou can run your script in 64bit mode from Scite which is a 32bit application as you did

[Jpm]

I don't know if the beta version of autoitWrapper correct it but I found the error nothing related with the 32/64 bit interaction just AutoitWrapper.au3 mistyping
HKCR\AutoIt3Scrip -> HKCR\AutoIt3Script

[Jpm]

I just test the beta version the bug is still there

[Jos]

I will have a look this evening and upload a fixed version.

Jos

[Jos]

Uploaded a new Beat version of AutoIt3Wrapper with fixes for the wrong REGKEY.
Let me know if this works, because I can test it.

Jos

[Jpm]

For me it is working, Just the consolewrite at line 40 is a little confusing

CPU: @OSArch

it should be

CPU: @CPUArch OS: @OSArch

[rboucher]

It is important to you that I test on my end so that bug can be closed? I can install on a Win2008 VM and verify that it fixed.

Rob

[Jpm]

Replying to rboucher:

It is important to you that I test on my end so that bug can be closed? I can install on a Win2008 VM and verify that it fixed.

Rob

no need I am sure of the test, Jos will close it when he want.
You can use the AutoIt3Wrapper.exe in the download beta area of SciTE
Thanks for your help

[TicketCleanup]

Automatic ticket cleanup.