We do quite some scripting and little helpers with batch files (xyz.cmd) at work. Windows 7 is only now starting to become widespread here, and obviously, we hit the problems associated with the different environment variables of 32bit vs. 64bit windows.

Specifically, if you run C:\Windows\system32\cmd.exe on a 64 bit Windows, you'll get:

ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files

whereas, if you start C:\Windows\SysWOW64\cmd.exe on a 64 bit Windows, you'll get:

ProgramFiles=C:\Program Files (x86)         <-- NOTE
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files

It also so happens, that because this cmd.exe is a 32bit process, it also gets all the other SysWOW64 redirections "for free" -- any invocation of regedit will go to the 32bit registry, etc.

This can be extremely useful if the batch file is supposed to do some tasks related to a 32bit application, e.g. path + registry stuff.


GIven that I have a class of batch files that I would wish to always run with the 32bit version of cmd.exe, is there an -- easy! -- way to force these batchfiles to always use the 32bit cmd.exe on 64bit versions of Windows and run normally on 32bit versions of Windows?

Obviously I can add a "header" to each such batch-file to change environment variables and regedit invocations and/or obviously I could just tell users to "run this batch file via the SysWOW64 cmd.exe", but neither of these solutions seems very attractive :-)

  • 2
    You make mention of 63-bit Windows please edit your question, so your talking about 64-bit, of course you should only be calling C:\Windows\system32\cmd.exe and your batch command figures out what should be done base on the existence of C:\Program Files (x86)** or not. **C:\Program Files (x86) does not exist on a 32-bit installation of Windows 7. – Ramhound Nov 28 '11 at 15:37
  • 1
    @Ramhound - You completely miss the point. These batch files are "32 bit batch files". The are made for stuff regarding 32 bit applications. (As I already explained in the question.) Windows already comes with all the necessary "figures-out", and this is done automatically when I use the 32bit version of cmd.exe. Now, what would be nice would be being able to tell Windows to automatically use that. That's what this question is all about, as I think I've explained very openly in the question already. – Martin Nov 30 '11 at 7:10
  • 1
    @Martin, then why not just hard code an if statement? IF exist "c:\program files (x86)" then prog==c:\program files (x86), else prog==c:\program files... or similar. – William Hilsum Jan 23 '12 at 22:22

I have three possible solutions for your problem:

1) Use a wrapper batch file

In a company I used to work for, we had a single wrapper batch file for everything we ran. We did this to simplify interaction with our users, but it would work similarly. If you wanted, you could create a wrapper for each batch file (in essence, creating two batch files), or create a single wrapper that allows you to select each batch file from a menu (as described http://http-server.carleton.ca/~dmcfet/menu.html). You could have each menu selection identify the path to the batch file to run, and then you could have the wrapper choose the correct cmd.exe to launch it with.

2) Use the batch file as a self-wrapper

For each batch file, you could include a header which determines what OS you are on (32 or 64-bit). If you are on a 64-bit OS, you would know that, by default, you are launching it using the 64-bit version of cmd.exe. You could have that file then launch the 32-bit version of cmd.exe with the same batch file, but you could also pass the batch file a flag which tells it to ignore the 64-bit check. It would then run under the correct 32-bit cmd.exe.

For example:


::Check if 64-bit check skip flag exists

IF %1 == /skipcheck (goto run)

::Check if OS is 64-bit

IF %processor_architecture%==AMD64 (<path_to_32-bit_cmd> /c "<path_to_batch_file>\<name_of_my_batch_file>" /skipcheck)
IF %processor_architecture%==AMD64 (goto end)


echo Hello World!


I haven't tested the above code, so I might have some quotes or parenthesis in the wrong spot, but this is the general idea.

3) Migrate to PowerShell

PowerShell is available for all Windows OSes XP and newer. PowerShell is designed by Microsoft to eventually replace the simple cmd.exe, and provides a rich language for doing nearly any task. Most batch programs are actually runnable in PowerShell, and at most may require minimal tweaking.

  • 1
    the self-wrapper approach seems a good solution! – Martin Jan 24 '12 at 10:15
  • I always had the impression that Powershell works very differently from cmd. Can I really run normal cmd commands from Powershell?? – Martin Jan 24 '12 at 10:18
  • From one point of view, PowerShell is very different from cmd. However, Microsoft has made PowerShell compatible with most of the commands and calls possible from cmd. It also added a number of *nix calls (like ls), as well as expanded the world of possibilities using cmdlets. Obviously, you'd want to test any code thoroughly if you migrate, but the changes you'd have to make should be minimal. – Nick2253 Jan 24 '12 at 19:33
  • any examples of how to do #2? – rogerdpack Feb 3 '12 at 17:01
  • See example above. There are really a thousand and one ways to do that, but this is just one way I slapped together after seeing your question. – Nick2253 Feb 4 '12 at 2:17

You should explicitly run the cmd.exe version you want and have it execute your batch file:

For executing in 64-bit: C:\Windows\system32\cmd.exe /C path\to\batchfile.cmd
For executing in 32-bit: C:\Windows\SysWOW64\cmd.exe /C path\to\batchfile.cmd

The /C parameter executes the supplied command and terminates. (Yes, that's a link to XP documentation).


I am re-writing that wrapper to be more efficient and universal, just dump the header in and go, there is nothing to configure.

This will handle these scenarios not in the accepted answer:

  • Running on Systems without the "process architecture" variable (Older than XP) through Windows 10.
  • Running on x86 or x64 systems
  • The OS being Installed on drives and paths other than "C:\Windows"
  • Getting the script's Name and path to re-run itself automatically.
  • Passing all command line Arguments to the new iteration that is run.

Just dump the header in and go.

    REM check for Only state where we are not in a 32 bit CMD
    ECHO."%PROCESSOR_ARCHITECTURE%_%ProgramFiles%" | FIND /I "AMD64_" | FIND /I /V "86"  >NUL && (
        CALL "%SystemRoot%\SysWOW64\cmd.exe" /c ""%~f0" %*"
        GOTO :EOF


   EXIT /b

.com files created on a 32 bit machine only run on 32 bit machines. If you compile it as an exe file, then rename its extension to .com, then only 32 bit machines can run it.

Its not very conducive if your constantly editing the script, but I think its the best method, since it hides your code too.

  • 1
    This answer is not correct. I'm running 64 bit windows and programs in \windows\system32 such as format.com and tree.com run just fine. – DavidPostill Oct 12 '14 at 17:24
  • 1
    What .com files? This is an extension for 16-bit DOS applications. It has absolutely no relation to the OP’s problem. – Daniel B Oct 12 '14 at 17:46
  • 1
    Hi. I am downvoting your answer because I think it is totally besides the point. – Martin Oct 12 '14 at 18:31
  • 1
    He wants to work with .bat files, not compile them. If he were to compile them to a 16-bit .com application, how would that help with running them in 32-bit cmd.exe on a 64-bit system? They won’t run at all! Your idea is simply a non-solution. – Daniel B Oct 13 '14 at 8:30
  • 1
    First, I think you have misunderstood that I "only want to run on 32 bit machines". I'm fine with these running on a 64bit OS, the just should run in a 32 bit context. So if I were to compile anything, a 32bit exe file would be just fine, no need for a com file. – Martin Oct 13 '14 at 20:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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