Windows PowerShell should rightly be seen as a replacement for batch file scripting (Cmd.exe shell scripting), but for some reason, many people seem to be unwilling to leave batch behind. This article begins a series that’s designed to help you break the batch habit and move forward with PowerShell. 

Before I get into the details in this multi-part series, I want to first provide some history about batch files and why you should write all your new scripts using PowerShell instead of the old-style, batch file code.

History of Batch Files

Batch files have a very long history. One of the first microcomputer operating systems, CP/M, had a Submit command that ran each line of a text file as a series of commands. It was very simple (memory being at a premium) and did not support any kind of conditional branching. 

When MS-DOS was developed, Microsoft included a similar batch processing feature in the Command.com command interpreter: Put your commands in a text file, name it with a .Bat extension, and the command interpreter would run each command in the file. 

Over time through subsequent DOS versions, Microsoft extended batch files in various ways. They added labels, the Goto statement, the If command for branching, and more. The important point is that the batch “language” wasn’t designed; it grew out of the CP/M Submit command.

Windows NT And Cmd.exe

Fast forward to Windows NT (1993). Microsoft included a console-mode application called Cmd.exe, which to this day presents the legendary “C: prompt” to the user. Cmd.exe is a superset of the old Command.com command interpreter from MS-DOS and even uses many of the exact same commands. The command similarities, of course, were by design to preserve backward compatibility for users who wanted to use their old batch files from DOS. Cmd.exe will even run a “batch file” if it has the .Bat extension. 

The similarities between Cmd.exe and Command.com, the backward compatibility for .Bat files, and Microsoft’s initial choice for the Cmd.exe icon (the “MS-DOS” logo) has led to many years of confusion. To this day, Windows message boards are littered with questions asking how to do something “in DOS” (what they are asking, of course, is how to do something in Cmd.exe, which has nothing to do with DOS). 

The Cmd.exe command interpreter has more features than Command.com, and accordingly the batch “language” was extended as well. Among these are For /f iteration, simple subroutine support using the Call command, and environment localization (Setlocal and Endlocal). While these enhancements make the batch “language” more useful, it still has numerous quirks that can make writing anything other than a very simple batch file a vexing experience.

Windows Script Host

Starting in Windows 2000 (1999), Microsoft added to its scripting power by introducing the Windows Script Host (WSH) and two real, built-in, programming languages (VBScript and JScript--Microsoft’s version of JavaScript). WSH scripts rely on COM objects to interface with the operating system and applications. While WSH is extremely useful and powerful, it’s limited to COM objects that are installed on the computer and doesn’t provide a command-line interface.

Enter Windows PowerShell

Batch files and WSH scripts don’t provide consistency, because they are essentially separate tools with different interfaces (batch file scripting and WSH scripting are completely different things). Microsoft realized this wasn’t ideal, so they released the first version of Windows PowerShell in 2006. PowerShell is based on the .NET Framework, and provides a single command-line and scripting interface for managing the Windows operating system. 

Now that we have Windows PowerShell, there is no longer any need to write old-style batch files (Cmd.exe shell scripts). Moving forward, you should focus your efforts on learning PowerShell, particularly since Microsoft has positioned PowerShell as the primary means of automating the Windows operating system and enterprise applications.

Why You Should Stop Writing Batch Files

Here are five good reasons why you should no longer write batch files (Cmd.exe shell scripts) and instead write new scripts in PowerShell. 

1. PowerShell is the future. Microsoft has positioned PowerShell as the primary means of automating Windows and Microsoft enterprise applications. Third-party vendors are also supplying PowerShell libraries to manage their products. You’re going to have to learn PowerShell anyway, so you might as well start now.
2. Batch files are arcane and have numerous quirks. I frequent a number of question-and-answer sites about scripting, and I’ve lost count of the number of times I have seen questions about why environment variables don’t expand correctly or why the Start command isn’t working properly. There’s no need to frustrate yourself with Cmd.exe’s batch language quirks and limitations; write the script using PowerShell’s scripting language instead.
3. PowerShell supports batch files and command-line tools. Moving to PowerShell doesn’t mean you have to abandon batch files or command-line tools. Old batch files will still run in PowerShell, and command-line tools still work just fine.
4. PowerShell’s script language is a real programming language. You don’t have to be a programmer to benefit from PowerShell, but when you need to express complex logic in a script, it will be simpler to express the logic in PowerShell than in a Cmd.exe batch file. In many cases, a single PowerShell command line can replace hundreds of lines of batch file code.
5. PowerShell works with objects, not text. Cmd.exe and other text-based shells only work with textual output of commands. PowerShell commands, on the other hand, work with .NET objects. Things that are annoyingly difficult, awkward, and/or complex in a Cmd.exe batch script (for example, date and time parsing) become surprisingly straightforward and simple in PowerShell. 

Leave Batch Behind

Cmd.exe isn’t going away any time soon, but there’s no reason to learn the peculiarities of the old-style batch language. Leave batch behind and focus your efforts on PowerShell instead.

Up next: We’ll get into some of the differences between batch file (shell script) syntax and PowerShell. Stay tuned.