Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

The answer to my other question (a while ago) was that a program I was using to run a command prompt was running the 32 bit version if the cmd prompt, instead of the 64 bit.

(In case you didn't see the other question, I'm using windows 7, 64 bits).

This was fine for a while, but now it has once again become a nuisance.

I am trying to open files (batch files, in this case) from any directory, by just typing their names. I added the files' directory to the PATH variable, for that to work.

Now, if I open a 64 bit cmd prompt (Run->cmd, per example), things work perfectly: typing "color-1" changes to the color specified in the "color-1.bat" file, per example.

However, when the 32 bit version is used, I just get a "not recognized" message.

So, I need to get that program to call the 64 bit version of the command prompt The program in question is PhraseExpress (no space), and, in the macro edition box I have

{#run -file "C:\windows\system32\cmd.exe"}.

Note I specified the path of the cmd.exe file I wanted, instead of just writing {#run -file cmd} in the hope that it would actually go for the 64 bit version, and not the 32 bit one, but no luck there: the command prompt process is always 32 bit (checked in the task manager).

I also tried creating a batch file that runs cmd (file simply has "cmd" -no quotes- written on it) and then calling it with PhraseExpress, but I get the same result. (file calls a 64 bit command prompt when double-clicked, but a 32bit version when called with PhraseExpress).

Right now, I am running out of ideas, so... can anyone think of something?

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

I think you just don't have your batch files in a path shared by both command environments. Unless your batch file contents are 64-bit specific, you should aim to get the path setup in both/all environments so they run in either, instead of trying to trick this program into using the cmd.exe you want.

But, to directly answer your question...

Since system32 is transparently redirected to sysWOW64 for 32-bit programs, they added a way to access the system32 folder that's native to the system's architecture (64-bit) -- the 'real' system32 folder.

So try referencing it via "sysnative".

ie: {#run -file "%WINDIR%\sysnative\cmd.exe"}

share|improve this answer
    
For the first part, I could do that, but there are other things I'm working on in which a 64bit cmd prompt is helpful. The sysnative reference worked, making the program call a 64bit cmd prompt. However, and this may be unrelated, the variable PATH in the called terminal is different than the variable PATH in one called using Run->cmd: it lacks the path I added in Advanced System Settings->Environment Variables. Is there another way I can alter the value of PATH?(I tried PATH=*my_path*, but it only works until I close that particular cmd prompt)btw,If this is unrelated, I'll accept the answer. –  Sampaio Sep 20 '13 at 0:44
1  
@Sampaio Are you sure? Here the changes in PATH, via "Advanced System Settings->Environment Variables", both user and system, are reflected in %windir%\System32\cmd.exe and %windir%\SysWOW64\cmd.exe. Try starting them both via run and check set path. –  Rik Sep 20 '13 at 7:43
    
The changes have finally kicked in, and all is well. I tested it just after turning the pc on, after turning it off last night and being off since. I did try a reboot at the time, but I guess the computer didn't think it was a long enough rest, or something... Anyway, problem(s) solved, answer accepted. Thank you for the help. –  Sampaio Sep 20 '13 at 21:11
    
Computers need sleep too ;-) –  Rik Sep 20 '13 at 23:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.