PowerShell vs CMD: Unlocking the Power of Windows
We explore the power of Powershell, and why it's a worthy successor to the command line crown
Scratch the surface of the Windows operating system even a little, and you'll quickly run into PowerShell. It's the tool of choice for thousands of Windows admins and goes far beyond the company's previous command line interfaces (CLIs). What is it, why did Microsoft build it, and why is it better than what came before?
Let's begin with a little history. Microsoft's CLIs began with command.com, which was the interpreter for MS-DOS and the shell in Windows 9x systems. Microsoft superseded this in NT with CMD.exe, which added goodies like better error messages, command line completion, and native access to the command history.
If command.com was the Lada of CLIs, then CMD.exe was the Ford Escort. It remained the Windows CLI du jour until 2006, when Microsoft introduced its Maserati: PowerShell.
PowerShell began as a project called the Microsoft Shell (AKA Monad) in 2002, but it wasn't until 2006 that the company renamed it and integrated it into Windows 7. Since then, PowerShell has been an integrated component in the Windows OS. Although CMD.exe coexists with PowerShell, its influence is gradually eroding. Microsoft officially replaced it with PowerShell as the default command shell accessible from File Explorer in November 2017.
So why the shift to PowerShell? CMD.exe was a limited tool. You could use it to run basic administrative commands on a machine, but what about if you wanted to manage 400 of them at once? What about managing things remotely, such as virtual servers in the cloud?
Whereas CMD.exe doesn't do those things, PowerShell supports add-on functionality to manage machines in Microsoft's Azure cloud, such as creating, controlling, and monitoring virtual machines, and configuring cloud storage.
Jeffrey Snover, the head of the PowerShell project team, designed the tool as the missing link between Microsoft's GUI-based administrative tools and the rich set of application programming interfaces (APIs) that expose the company's .NET framework.
He wanted a single command line tool to support both developers and administrators. In this sense, PowerShell was one of the first forays into what became DevOps, a practice that promotes collaboration between developers and operations teams.
Unlike CMD.exe, PowerShell is an object-oriented tool. Objects are representations of things like files and directories that have their own properties and actions that you can call upon in the CLI. PowerShell understands everything in Windows as an object, but also lets you create your own object types.
PowerShell enables admins to get at these objects using more sophisticated commands than you'll find in CMD.exe. One of the tool's key innovations is its use of commandlets (CMDlets). These are small programs (as little as a dozen lines of code) that can carry out specific tasks using .NET's APIs. They can execute an object's methods, query and change its attributes, and return objects as their results.
CMDlets come in a simple verb-noun form and enable you to get things done quickly. For example, typing Get-Member gives you information about an object, like its properties or attributes.
Get-Member won't do much on its own, though. You need a pipeline - which is another thing that wasn't available in CMD.exe. Unix and Linux users have enjoyed pipelines for decades, and it's just one command that PowerShell supports from the Bash shell that's common to those systems.
A pipeline lets you take the output of one command and 'pipe' it to another, which takes it as input. You depict a pipeline using |. Say you want to create an object in PowerShell:
$message = Write-Output 'PowerShell is awesome'
You've just used the Write-Output CMDlet to assign some text to what many languages would call a variable. Except in PowerShell, it's not a variable; it's an object with its own methods and properties. You can list them all by piping the $message object to Get-Member:`$message | Get-Member'
You can pipe lots of CMDlets together to create extensive chains of commands, like a conveyor belt of workers adapting something and passing it on to the next person.
Piping aside, this kind of object-oriented programming will be familiar to developers who work in languages like Python. You can even make the object give up certain information about itself using the object's name, a dot, and the property name. For example:$message.Length returns 21
You can create CMDlets yourself in a variety of languages, like Microsoft's own C#. An alternative approach to creating your own PowerShell programs is to write scripts, which are collections of PowerShell commands collected together into a file that you can run. Although cmd.exe also allows scripts, PowerShell provides its own interactive scripting environment (PowerShell ISE) with a range of extra features like Intellisense, which gives you context-aware method and property options as you're typing.
There's another thing PowerShell gives you that cmd.exe doesn't: the ability to create modules. These are packages of related scripts and/or CMDlets that call upon each other to help carry out a bigger task. You can share lots of complementary scripts and CMDlets far more easily as a module. Sharing is a big part of the PowerShell story. For example, there's a PowerShell gallery containing thousands of scripts and modules from developers.
PowerShell isn't standing still, either. In 2016, Microsoft open-sourced it as PowerShell Core, and it's now available on Linux and Mac computers as an alternative to the common Bash shell. Be warned, though; installing it on those machines means forklifting .NET Core, the pared-down open source counterpart to native Windows .NET, onto your system. You'll also lose functionality (it doesn't support the ISE scripting environment, for example).
PowerShell has expanded over the years, with new facilities including classes (objects that you can use as templates for other objects), and integration with tools like Visual Studio Code (available in both PowerShell and PowerShell Core).
Should you use PowerShell? The learning curve isn't as steep as you'd think, and the features it brings you are worthwhile. You might not need them all if you're just tinkering with your own machine, but isn't it better to have a powerful toolbox with some tools you won't use, rather than relying on a 20-year-old set of pliers?
What you need to know about migrating to SAP S/4HANA
Factors to assess how and when to begin migrationDownload now
Your enterprise cloud solutions guide
Infrastructure designed to meet your company's IT needs for next-generation cloud applicationsDownload now
Testing for compliance just became easier
How you can use technology to ensure compliance in your organisationDownload now
Best practices for implementing security awareness training
How to develop a security awareness programme that will actually change behaviourDownload now