Modify

Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#879 closed Bug (Fixed)

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

Reported by: rboucher Owned by: Jos
Milestone: Future Release Component: SciTE4AutoIt
Version: 3.3.0.0 Severity: None
Keywords: Cc:

Description

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")


Attachments (6)

autoit_install_x64.PNG (22.2 KB) - added by Jpm 10 years ago.
Display AU3 default.au3 (1.9 KB) - added by Jpm 10 years ago.
start menu.PNG (30.0 KB) - added by Jpm 10 years ago.
script results.png (171.2 KB) - added by rboucher 10 years ago.
Results of running JPMs script
Install_directory_autoIT.png (198.3 KB) - added by rboucher 10 years ago.
Install directories for AutoIT even when chosing 64-bit option
SciTE running 32 bit version.png (180.1 KB) - added by rboucher 10 years ago.
SciTE running the 32-bit version of AutoIT while on Win2008

Download all attachments as: .zip

Change History (22)

comment:1 Changed 10 years ago by 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.

Changed 10 years ago by Jpm

Changed 10 years ago by Jpm

comment:2 Changed 10 years ago by 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

comment:3 follow-up: Changed 10 years ago by 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.


comment:4 in reply to: ↑ 3 Changed 10 years ago by 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.

Changed 10 years ago by Jpm

comment:5 Changed 10 years ago by 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.

Changed 10 years ago by rboucher

Results of running JPMs script

Changed 10 years ago by rboucher

Install directories for AutoIT even when chosing 64-bit option

Changed 10 years ago by rboucher

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

comment:6 Changed 10 years ago by 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

comment:7 Changed 10 years ago by 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

comment:8 Changed 10 years ago by Jpm

  • Component changed from AutoIt to SciTE4AutoIt
  • Owner set to Jos

comment:9 Changed 10 years ago by Jpm

I just test the beta version the bug is still there

comment:10 Changed 10 years ago by Jos

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

Jos

comment:11 Changed 10 years ago by 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

comment:12 Changed 10 years ago by 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

comment:13 follow-up: Changed 10 years ago by 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

comment:14 in reply to: ↑ 13 Changed 10 years ago by 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

comment:15 Changed 10 years ago by Jos

  • Resolution set to Fixed
  • Status changed from new to closed

comment:16 Changed 10 years ago by TicketCleanup

  • Milestone set to Future Release

Automatic ticket cleanup.

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The owner will remain Jos.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.