Further to ++soonix's good questions: Are you in the 64-bit cmd.exe on both machines? You can check Task Manager, which shows cmd.exe *32 for the 32-bit cmd.exe, and just cmd.exe for the 64-bit version. Inside cmd.exe, you can also check (see here for details): run set, and look at especially the PROCESSOR_ARCHITECTURE and PROCESSOR_ARCHITEW6432: the first should be AMD64 or similar in a 64-bit cmd.exe, and x86 in a 32-bit cmd.exe; the second is only defined in 32-bit cmd.exe, and should be AMD64.
How this will help fix the problem, I am not sure... but it might point to where the difference lies.
| [reply]
[d/l]
[select] |
Verified in Task Manager, both are running 64bit cmd.exe. In fact, on both machines, the cmd.exe Is started in the same way. Our desktop support folks use MKS Toolkit. So, I have a perl script which chops MKS Toolkit out of the path, reorders Strawberry to the front, and sets up a few other environment variables before starting the cmd.exe.
| [reply] |
Mysterious. Perhaps perl is invoked on one computer using a .BAT file, and on on the other using a .CMD? If you open a command prompt, and enter DIR C:\ - does it show "Program Files" and "Program Files (x86)", or "PROGRA~1" and "PROGRA~2"?
and: is the PATH the same on both machines? | [reply]
[d/l] |
