Run command works from source and U64-compiled but fails U32-compiled - Compiler Bug?

[JoeWinograd]

W10 64-bit v20H2
AHK v1.1.33.06 U64 (installed)

Problem is with the following script:

Code: Select all

Run,c:\temp\EXCEL.lnk

The Target field in the .LNK file is a shortcut to the Excel executable:

"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE"

The script works fine when run from source code (with U64 active) via both File Explorer and Total Commander. The script also works fine when compiled with U64, but it fails when compiled with U32 (and A32), giving this error dialog:

compile fail.png (8.46 KiB) Viewed 1584 times

Is this a compiler bug or an error on my part? Thanks much, Joe

[TAC109]

Hi Joe

You could narrow down the problem area by running your uncompiled script with the AutoHotkeyU32.exe interpreter by calling the U32 interpreter with the script file as the first parameter.

Cheers

[JoeWinograd]

calling the U32 interpreter with the script file as the first parameter

Hi TAC,
Thanks for jumping in. Here's a screenshot of doing that in a command prompt with the resulting error dialog underneath it:

U32 fail via command prompt.png (37.73 KiB) Viewed 1554 times

Does that help to narrow down the problem area? Regards, Joe

[TAC109]

@JoeWinograd
Well, it seems to eliminate the compiler!
Could you examine the shortcut and look for anything unusual in the various fields?
Also check if C:\temp\ is accessible from a script run from AutoHotkeyU32.exe? (Maybe 'Loop files'?)

[JoeWinograd]

Well, it seems to eliminate the compiler!

Indeed!

Could you examine the shortcut and look for anything unusual in the various fields?

There's nothing unusual in the fields. The Target is:

"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE"

The Start in is:

"C:\Program Files\Microsoft Office\root\Office16"

The Security tab has the usual four Permissions and the Compatibility tab has nothing ticked.

check if C:\temp\ is accessible from a script run from AutoHotkeyU32.exe

The issue is not C:\temp\. I did that just to have something simple to post. The "real" problem occurred in a 5,000+ line program where the shortcuts reside in other folders. But, to leave no stone unturned, I just moved the test script and the shortcut file to my D: drive (and not the root) with the same result:

U32 fail on D drive.png (9.45 KiB) Viewed 1543 times

Still runs fine with U64. This is strange!

[JoeWinograd]

Update: To test if a corrupt LNK file could be the problem, I just created a new shortcut by right-clicking on the Excel EXE file. It made a shortcut with the same Target as shown previously, but with nothing in the Start in field. It fails in the same way with U32 and works fine with U64.

[gregster]

Does it have to do with the different "Program files" default directories for 64 and 32 bit programs?
C:\Program Files versus C:\Program Files (x86)

[JoeWinograd]

Does it have to do with the different "Program files" default directories for 64 and 32 bit programs?

Hi gregster,

I don't think so...at least, I don't know how that would be the case. The EXCEL.exe file is in only C:\Program Files, not C:\Program Files (x86). It is a 64-bit file, but the Run command in a 32-bit AHK script can certainly run a 64-bit EXE, or a LNK file that is a shortcut to a 64-bit EXE.

I wonder if it's a bug in the AHK 32-bit interpreter, now that TAC's idea has shown that it is not a bug in the compiler. Regards, Joe

[JoeWinograd]

Can anyone following this thread reproduce the problem? It would be great to know if it is an issue peculiar to my environment. Thanks!

[TAC109]

@JoeWinograd

The next step would be to remove Excel from the equation. Make a shortcut to another program and see if that works. If so, try link to other programs, and narrow the problem down that way until you see a common factor.

Cheers

[anaglypta]

Based on what gregster said, you could try this:

Code: Select all

if A_Is64bitOS && (A_PtrSize!=8)
	DllCall("kernel32\Wow64DisableWow64FsRedirection", "Ptr*",0)

[JoeWinograd]

Make a shortcut to another program and see if that works.

Already did that. Created a 64-bit HelloWorld.exe and then created a .LNK to it. Worked fine! Btw, shortcuts to PowerPoint and Word fail the same as Excel, so it seems to be a Microsoft Office issue. Further supporting that, I put a shortcut to 64-bit Total Commander in the same folder as the Excel, PowerPoint, and Word shortcuts...the Total Commander link runs fine with the U32 script...all three Office links fail! So, what in the world is going on with Office?!

[JoeWinograd]

Based on what gregster said, you could try this

Thanks for the idea...tried it...no joy.

[anaglypta]

You could try the ShellRun function by Lexikos.

[TAC109]

@JoeWinograd
From memory, the Start Menu Office shortcuts are special. My ones are much larger than a standard shortcut. You may need to copy the Start Menu shortcut to use in your script. Another idea is to create a shortcut that points to the Start Menu shortcut.

Edit: Or just run the Excel shortcut that is in the Start Menu.

Cheers

[JoeWinograd]

My ones are much larger than a standard shortcut.

Mine are normal. Can you reproduce the problem there? What happens when you run (with U32) the one-line script that has a Run command to an Excel or Word shortcut?

You may need to copy the Start Menu shortcut to use in your script.

Did that...dragged-and-dropped the Excel shortcut from the Start menu to the Desktop (naming it Excel from Start menu), then put this in the script:

Run,c:\Users\Joe\Desktop\Excel from Start menu.lnk

Once again, works fine with U64 but fails with U32.

Edit: Or just run the Excel shortcut that is in the Start Menu.

Tried this:

Run,c:\Users\All Users\Microsoft\Windows\Start Menu\Programs\Excel.lnk

Same result...works fine with U64...fails with U32.

[JoeWinograd]

You could try the ShellRun function by Lexikos.

I don't see how that would apply to this situation.

[lexikos]

A test I performed:

• Create a shortcut to a program file within C:\Program Files.
• Use C:\Windows\SysWow64\cmd.exe (the 32-bit command interpreter) to run the shortcut file.
• Watch it fail, with "The specified path does not exist."
• Use C:\Windows\System32\cmd.exe (64-bit) to run the shortcut file.
• Watch the program open.

When you launch a shortcut file with ShellExecuteEx, most likely some code within that function executes within the current process to locate the appropriate command line and run it. If the current process is 32-bit on a 64-bit system, the command line is being run within the context of Wow64.

When you use ShellRun, explorer.exe launches the command-line. On 64-bit systems, the process is 64-bit.

ShellRun works for me.

[anaglypta]

The idea is that the 64-bit shell would open the file in a 64-bit way, rather than the 32-bit AutoHotkey open the file in a 32-bit way.

You could also try these 2 scripts (replacing Notepad with your file):

Code: Select all

Run, "explorer.exe" "C:\Windows\System32\notepad.exe"

Code: Select all

if A_Is64bitOS && (A_PtrSize!=8)
	DllCall("kernel32\Wow64DisableWow64FsRedirection", "Ptr*",0)
Run, "explorer.exe" "C:\Windows\System32\notepad.exe"

Please let me know if any of them work, thanks!

[JoeWinograd]

A test I performed

Thanks for performing those tests! Same results here.

ShellRun works for me.

Works here, too! And thanks for your comments on 32-bit/64-bit...very helpful.

The idea is that the 64-bit shell would open the file in a 64-bit way, rather than the 32-bit AutoHotkey open the file in a 32-bit way.

Yes, ShellRun works fine! I misunderstood what it does when you first mentioned it. Thanks!

You could also try these 2 scripts

Running explorer.exe via the Run command is currently the method in my "big" program. I want to replace it with my own GUI dialog rather than showing the File Explorer window.

Thanks to everyone who played in this...I really appreciate the help. And an extra tip-of-the-hat to lexikos for ShellRun. Regards, Joe