Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate

Programs run with AHK have unusual environment (Win 64-bit)


  • Please log in to reply
6 replies to this topic
edbert
  • Guests
  • Last active:
  • Joined: --
This is a weird one, it's probably not even an autohotkey issue...

I use Autohotkey to launch, well, everything. But i noticed some unusual differences when I run things with Autohotkey, and when I run things with explorer.

For example, I have cmd.exe assigned as a hotkey.

When I run cmd.exe from autohotkey, i cannot find certain files (i.e. defrag.exe).

when I run cmd.exe from start->run->cmd.exe, I can find the files.

This appears to be windows somehow hiding the files from processes launched from Autohotkey. Any idea what this could be?

I'm running on a Windows XP 64-bit build with SP2

Thanks!

ManaUser
  • Members
  • 1121 posts
  • Last active: Dec 07 2016 04:24 PM
  • Joined: 24 May 2007
Have you checked if the PATH environment variable comes out different when you start cmd that way?

edbert
  • Guests
  • Last active:
  • Joined: --
Hi,

PATH variables are the same.
What's different is the following...

AHK launched CMD environment:
CommonProgramFiles=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
ProgramFiles=C:\Program Files (x86)
ProgramW6432=C:\Program Files
__COMPAT_LAYER=LUA

Run->CMD environments:
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramW6432= does not exist
PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_ARCHITEW6432= does not exist
ProgramFiles=C:\Program Files
ProgramW6432= does not exist
__COMPAT_LAYER= does not exist

My guess is that the ProgramFiles environments are causing something wrong, why there is a difference in env variables I have NO idea.

Thanks again for any insight.

ManaUser
  • Members
  • 1121 posts
  • Last active: Dec 07 2016 04:24 PM
  • Joined: 24 May 2007
It sounds like Windows is giving AutoHotkey a different set of environment variables because it isn't a 64 bit program.

One possible solution would be to change them to the correct values with EnvSet before launching cmd.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
On 64-bit versions of Windows, 32-bit applications such as AutoHotkey run inside WOW64.

Source: MSDN: Running 32-bit Applications
WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows.

Source: MSDN: File System Redirector
Whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to a new directory, %windir%\SysWOW64.

This is important for application compatibility because System32 contains 64-bit files, while SysWOW64 contains 32-bit files. Since cmd.exe is in System32, "Run cmd.exe" actually runs a 32-bit version of cmd.exe which is located in SysWOW64. Try the following instead:
DllCall("Wow64DisableWow64FsRedirection", "uint*", OldValue)
Run cmd.exe
DllCall("Wow64RevertWow64FsRedirection", "uint", OldValue)


edbert
  • Guests
  • Last active:
  • Joined: --
wow, thanks for the response! You guys are good.
Lexikos, your solution worked!

I'm not sure I fully understand it tho. I'll read up on the links you provided.
How odd that System32 contains 64bit files, while SysWOW64 contains 32bit ones...you'd think it would be the other way around.

Anyway, I did quickly run a test of running SysWOW64\cmd.exe vs system32\cmd, and it confirmed the difference I was seeing in the command environments (everything except the __COMPAT_LAYER=LUA entry).

I guess windows 64 is doing some additional work behind the scenes. It also seems to hide access to certain files in the system32...interesting

Thanks again everyone for the valuable assistance. I hope someone else finds this helpful.

Cheers

edbert
  • Guests
  • Last active:
  • Joined: --
Mods maybe we can change the title of this post to reflect is for 64 bit windows...i should get an account :|

[Moderator's note: Done. I had to shorten "Autohotkey" to "AHK".]