As I understand it, .bat
is the old 16-bit naming convention, and .cmd
is for 32-bit Windows, i.e., starting with NT. But I continue to see .bat fi
everything working in a batch should work in a cmd; cmd provides some extensions for controlling the environment. also, cmd is executed by in new cmd interpreter and thus should be faster (not noticeable on short files) and stabler as bat runs under the NTVDM emulated 16bit environment
.cmd and .bat file execution is different because in a .cmd errorlevel variable it can change on a command that is affected by command extensions. That's about it really.
Still, on Windows 7, BAT files have also this difference : If you ever create files TEST.BAT and TEST.CMD in the same directory, and you run TEST in that directory, it'll run the BAT file.
C:\>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
C:\Temp>echo echo bat > test.bat
C:\Temp>echo echo cmd > test.cmd
C:\Temp>test
C:\Temp>echo bat
bat
C:\Temp>
These answers are a bit too long and focused on interactive use. The important differences for scripting are:
.cmd
prevents inadvertent execution on non-NT systems..cmd
enables built-in commands to change Errorlevel to 0 on success.Not that exciting, eh?
There used to be a number of additional features enabled in .cmd
files, called Command Extensions. However, they are now enabled by default for both .bat
and .cmd
files under Windows 2000 and later.
Bottom line: in 2012 and beyond, I recommend using .cmd
exclusively.
Here is a compilation of verified information from the various answers and cited references in this thread:
command.com
is the 16-bit command processor introduced in MS-DOS and was also used in the Win9x series of operating systems.cmd.exe
is the 32-bit command processor in Windows NT (64-bit Windows OSes also have a 64-bit version). cmd.exe
was never part of Windows 9x. It originated in OS/2 version 1.0, and the OS/2 version of cmd
began 16-bit (but was nonetheless a fully fledged protected mode program with commands like start
). Windows NT inherited cmd
from OS/2, but Windows NT's Win32 version started off 32-bit. Although OS/2 went 32-bit in 1992, its cmd
remained a 16-bit OS/2 1.x program.ComSpec
env variable defines which program is launched by .bat
and .cmd
scripts. (Starting with WinNT this defaults to cmd.exe
.)cmd.exe
is backward compatible with command.com
.cmd.exe
can be named .cmd
to prevent accidental execution on Windows 9x. This filename extension also dates back to OS/2 version 1.0 and 1987.Here is a list of cmd.exe
features that are not supported by command.com
:
^
(Use for: \ & | > < ^
)PUSHD
/POPD
SET /A i+=1
SET %varname:expression%
FOR /F
(existed before, has been enhanced)CALL :label
Order of Execution:
If both .bat and .cmd versions of a script (test.bat, test.cmd) are in the same folder and you run the script without the extension (test), by default the .bat version of the script will run, even on 64-bit Windows 7. The order of execution is controlled by the PATHEXT environment variable. See Order in which Command Prompt executes files for more details.
References:
wikipedia: Comparison of command shells
RE: Apparently when command.com is invoked is a bit of a complex mystery;
Several months ago, during the course of a project, we had to figure out why some programs that we wanted to run under CMD.EXE were, in fact, running under COMMAND.COM. The "program" in question was a very old .BAT file, that still runs daily.
We discovered that the reason the batch file ran under COMMAND.COM is that it was being started from a .PIF file (also ancient). Since the special memory configuration settings available only through a PIF have become irrelevant, we replaced it with a conventional desktop shortcut.
The same batch file, launched from the shortcut, runs in CMD.EXE. When you think about it, this makes sense. The reason that it took us so long to figure it out was partially due to the fact that we had forgotten that its item in the startup group was a PIF, because it had been in production since 1998.