Initially using the code name “Monad”, PowerShell was first shown publicly at the Professional Developers Conference in September 2003. There are currently two versions of PowerShell supported by Microsoft.
Every released version of Microsoft DOS
and Microsoft Windows
for personal computers
has included a command-line interface tool (shell
). These are
(in installations relying on MS-DOS
, including Windows 9x
(in Windows NT
-family operating systems). These are regular command line interpreters
that support a few basic commands. For other purposes, a separate console application
needs to be provided, to be invoked from these shells. They also include a scripting language (batch files
), which can be used to automate various tasks. However, they cannot be used to automate all facets of GUI
functionality, in part because command-line equivalents of operations exposed via the graphical interface are limited, and the scripting language is elementary and does not allow the creation of complex scripts. In Windows Server 2003
, the situation was improved,
but scripting support was still considered unsatisfactory.
Microsoft attempted to address some of these shortcomings by introducing the Windows Script Host
in 1998 with Windows 98
, and its command-line based host:
. It integrates with the Active Script engine
and allows scripts to be written in compatible languages, such as JScript
, leveraging the APIs
exposed by applications via COM
. However, it too has its own deficiencies: it is not integrated with the shell, its documentation is not very accessible, and it quickly gained a reputation as a system vulnerability vector
after several high-profile computer viruses
exploited weaknesses in its security provisions. Different versions of Windows provided various special-purpose command line interpreters (such as netsh
) with their own command sets. None of them were integrated with the command shell; nor were they interoperable.
By 2003 Microsoft had started to develop a new shell called Monad (aka Microsoft Shell or MSH). Monad was to be a new extensible command shell with a fresh design that would be capable of automating a full range of core administrative tasks. Microsoft published the first Monad public beta release
on June 17, 2005, Beta 2 on September 11, 2005, and Beta 3 on January 10, 2006. They announced on April 25, 2006 that Monad had been renamed Windows PowerShell
, positioning it as a significant part of their management technology offerings.
Release Candidate 1 of PowerShell was released at the same time. Release Candidate 2 of PowerShell was released on September 26, 2006 and released to web (RTW) on November 14, 2006. PowerShell for Vista was released on January 30, 2007.
The last community technology preview (CTP)
release of Windows PowerShell v2.0 was made available in December 2008.
PowerShell v2.0 was completed and released to manufacturing in August 2009, as an integral part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and are available for download for both 32-bit and 64-bit platforms.
There are four kinds of commands Windows PowerShell can execute:
- ‘cmdlets’, which are .NET programs, written by a developer, compiled into a dynamic-link library and loaded by a PowerShell script,
- PowerShell scripts (files suffixed by ‘.ps1’),
- PowerShell functions,
- executable programs.
If a command is an executable program, PowerShell launches it in a separate process
; if it is a cmdlet, it is executed in the PowerShell process. PowerShell also provides an interactivecommand line interface
, wherein the commands can be entered and their output displayed. The user interface, based on the Win32 console
, offers customizable tab completion
but lackssyntax highlighting
. PowerShell also enables the creation of aliases
for cmdlets, which are textually translated by PowerShell into invocations of the original commands. PowerShell also supports both named
and positional parameters
for commands. In executing a cmdlet, the job of binding the argument value to the parameter is done by PowerShell itself, but, for external executables, arguments are passed via the argv
(or equivalent) variable array to be parsed by the executable.
Another concept used by PowerShell is that of a pipeline
. Like Unix pipelines
, PowerShell pipelines are used to compose complex commands, allowing the output of one command to be passed as input to another. A pipeline is set up by piping
the output of one command (or pipeline) to another command, using the
operator. But, unlike its Unix counterpart, the PowerShell pipeline is an object pipeline
; that is, the data passed between cmdlets are fully typed objects
, rather than character streams. When data is piped as objects, the elements they encapsulate retain their structure and types across cmdlets, without the need for any serialization
or explicit parsing
of the stream, as would be the need if only character streams were shared. An object can also encapsulate certain functions that work on the contained data. These also become available to the recipient command for use.
For the last cmdlet in a pipeline, PowerShell automatically pipes its output object to the
cmdlet, which creates a formatted text representation of its data, writing it to the screen.
Because all PowerShell objects are .NET objects, they share a
.ToString() method, which retrieves the text representation of the data in an object. Windows PowerShell uses this method to convert an object to text. In addition, it also allows formatting definitions to be specified, so the text representation of objects may be customized by choosing which data elements to display, and how. However, in order to maintain backwards compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, and does not integrate with the PowerShell type system.
The PowerShell Extended Type System
) is based on the .NET type system, but with certain extensions. For example, it enables the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as specifying custom formatting and sorting behavior. These views are mapped to the original object using anXML
Cmdlets are specialized commands in the PowerShell environment that implement specific functions. These are the native commands in the PowerShell stack. Cmdlets follow a
naming pattern, such as Get-ChildItem
, helping to make them self-descriptive.
Cmdlets output their results as objects, or collections thereof (including arrays), and can optionally receive input in that form, making them suitable for use as recipients in a pipeline. But, whereas PowerShell allows arrays and other collections of objects to be written to the pipeline, cmdlets always process objects individually. For collections of objects, PowerShell invokes the cmdlet on each object in the collection, in sequence.
Cmdlets are specialized .NET classes
, which the PowerShell runtime instantiates and invokes when they are run. Cmdlets derive either from
, the latter being used when the cmdlet needs to interact with the PowerShell runtime.
These base classes specify certain methods –
– one of which the cmdlet’s implementation overrides to provide the functionality. Whenever a cmdlet is run, these methods are invoked by PowerShell in sequence, with
being called if it receives pipeline input.
If a collection of objects is piped, the method is invoked for each object in the collection. The class implementing the Cmdlet must have one .NET attribute
– which specifies the verb and the noun that make up the name of the cmdlet. Common verbs are provided as an enum
If a cmdlet receives either pipeline input or command-line parameter input, there must be a corresponding property
in the class, with a mutator
implementation. PowerShell invokes the mutator with the parameter value or pipeline input, which is saved by the mutator implementation in class variables. These values are then referred to by the methods which implement the functionality. Properties that map to command-line parameters are marked by
and are set before the call to
. Those which map to pipeline input are also flanked by
, but with the
attribute parameter set.
The implementation of these cmdlet classes can refer to any .NET API
and may be in any .NET language
. In addition, PowerShell makes certain APIs available, such as
, which is used to access PowerShell-specific functionality, such as writing resultant objects to the pipeline. Cmdlets can use .NET data access APIs
directly or use the PowerShell infrastructure of PowerShell Providers
, which make data stores addressable using unique paths
. Data stores are exposed using drive letters, and hierarchies within them, addressed as directories. Windows PowerShell ships with providers for the file system
, the certificate
store, as well as the namespaces for command aliases, variables, and functions.
Windows PowerShell also includes various cmdlets for managing various Windows
systems, including the file system
, or using Windows Management Instrumentation
to control Windows components
. Other applications can register cmdlets with PowerShell, thus allowing it to manage them, and, if they enclose any datastore (such as databases), they can add specific providers as well.
In PowerShell V2, a more portable version of Cmdlets called Modules have been added. The PowerShell V2 release notes state, “Modules allow script developers and administrators to partition and organize their Windows PowerShell code in self-contained, reusable units. Code from a module executes in its own self-contained context and does not affect the state outside of the module. Modules also enable you to define a restricted runspace environment by using a script.”
PowerShell, like Unix/Linux based shells, implements a pipeline. This pipeline enables the output of one cmdlet to be piped as input to another cmdlet. For example, the output of the Get-Process cmdlet can be piped to the Sort-Object process (e.g. to sort the objects by handle count) and then to the Where-Object to filter any process that has say less than 1 MB of paged memory, then finally to the Select-Object cmdlet to select just the first 10 (i.e. the 10 processes based on handle count).
While Unix/Linux systems have long employed the concept of pipelines, PowerShell differs in what is passed between stages in the pipeline. In Unix the output of one command is piped to the next stage of the pipeline typically as raw text. With PowerShell, the pipeline consists of .NET Objects. Using objects eliminates the need to parse arbitrary text output from one command to extract data since all objects export a consistent interface.
Windows PowerShell includes a dynamically typed scripting language
which can implement complex operations using cmdlets imperatively
. The scripting language supports variables, functions, branching (
), loops (
), structured error/exception handling and closures
, as well as integration with .NET. Variables in PowerShell scripts have names that start with
; they can be assigned any value, including the output of cmdlets. While the language is untyped, internally the variables are stored with their types, which can be either primitive types
or objects. Strings can be enclosed either in single quotes or in double quotes: when using double quotes, variables will be expanded even if they are inside the quotation marks. According to the variable syntax, if the path to a file is enclosed in braces preceded by a dollar sign (as in
), it refers to the contents of the file. If it is used as an L-value
, anything assigned to it will be written to the file. When used as an R-value
, it will be read from the file. If an object is assigned, it is serialized before storing it.
Object members can be accessed using
notation, as in C# syntax. PowerShell provides special variables, such as
, which is an array of all the command line arguments passed to a function from the command line, and
, which refers to the current object in the pipeline.
PowerShell also provides arrays
and associative arrays
. The PowerShell scripting language also evaluates arithmetic expressions entered on the command line immediately, and it parses common abbreviations, such as GB, MB, and KB.
function keyword, PowerShell provides for the creation of functions, which can take parameters. A common problem for people new to PowerShell is that function arguments are separated by spaces, not commas:
: Calls the function with two arguments. (These arguments may be bound to parameters declared in the function definition or accessed by position from the $args array.)
(, ): Calls the function with a single argument, a two element array.
PowerShell allows any .NET methods to be called by providing their namespaces enclosed in brackets (
), and then using a pair of colons (
) to indicate the static method.
. Objects are created using the
cmdlet. Calling methods of .NET objects is accomplished by using the regular
For error handling, PowerShell provides a .NET-based exception handling
mechanism. In case of errors, objects containing information about the error (
object) are thrown, which are caught using the
keyword. However, the action-or-error is configurable; in case of an error, PowerShell can be configured to silently resume execution, without trapping the exception.
Scripts written using PowerShell can be made to persist across sessions in a
file. Later, either the entire script or individual functions in the script can be used. Scripts and functions are used analogously with cmdlets, in that they can be used as commands in pipelines, and parameters can be bound to them. Pipeline objects can be passed between functions, scripts, and cmdlets seamlessly. However, script execution is disabled by default and must be enabled explicitly.
PowerShell scripts can be signed
to verify their integrity, and are subject to .NET Code Access Security
Another use of PowerShell is being embedded in a management application, which then uses the PowerShell runtime to implement the management functionality. For this, PowerShell provides a managed
. Via the APIs, the application can instantiate a runspace
(one instantiation of the PowerShell runtime), which runs in the application’s process
and is exposed as a
The state of the runspace is encased in a
object. When the runspace is created, the Windows PowerShell runtime initializes the instantiation, including initializing the providers and enumerating the cmdlets, and updates the
object accordingly. The Runspace then must be opened for either synchronous processing or asynchronous processing. After that it can be used to execute commands.
To execute a command, a pipeline (represented by a
object) must be created and associated with the runspace. The pipeline object is then populated with the cmdlets that make up the pipeline. For sequential operations (as in a PowerShell script), a Pipeline object is created for each statement and nested inside another Pipeline object.
When a pipeline is created, Windows PowerShell invokes the pipeline processor, which resolves the cmdlets into their respective assemblies
(the command processor
) and adds a reference to them to the pipeline, and associates them with an
objects, to represent the connection with the pipeline. The types are verified and parameters bound using reflection
Once the pipeline is set up, the host calls the
method to run the commands, or its asynchronous equivalent –
. If the pipeline has the
cmdlet at the end of the pipeline, it writes the result onto the console screen. If not, the results are handed over to the host, which might either apply further processing or display it itself.
The hosting APIs are used by Microsoft Exchange Server
2007 to provide its management GUI. Each operation exposed in the GUI is mapped to a sequence of PowerShell commands (or pipelines). The host creates the pipeline and executes them. In fact, the interactive PowerShell console itself is a PowerShell host, which interprets
the scripts entered at command line and creates the necessary
objects and invokes them.