MSH (Microsoft Command Shell)

MSH, the Microsoft Command Shell, was the beta-era name of the shell and scripting language that Microsoft developed under the codename Monad. It was renamed Windows PowerShell in April 2006. From its first public demonstration in October 2003 until the rename, Windows administrators who joined the beta ran msh.exe, wrote .msh scripts and customised their shells with profile.msh. Its central idea was new for a mainstream shell: commands passed live .NET objects to each other instead of lines of text. MSH never shipped as a finished product under its own name. It shipped as PowerShell 1.0, and almost everything that defines PowerShell was first seen by the public in MSH.

About the name and the year. Microsoft used several names for this shell. In Snover’s 2002 Monad Manifesto, MSH stands for Monad Shell. Press coverage in 2003–04 calls it the Microsoft Shell. In 2005 Microsoft’s beta releases and TechNet Magazine call it the Microsoft Command Shell, and it installed to a folder of that name. The rename blog post says the team had expected the final name to be “Microsoft Shell or Management Shell”, which is why MSH had seemed safe to use. The encyclopedia catalogue dates MSH to 2006, the year the name was retired. This page uses 2003, the year of its first public demonstration.

History and Origins

The Monad Manifesto

The project started with Jeffrey Snover, then an architect at Microsoft. His white paper, the Monad Manifesto, is dated 8 August 2002 (version 1.2). It argued that Windows had simple GUIs for basic users and rich APIs for systems programmers, but lacked “the vital middle”: composable command-line tools for administrators. Unix filled that middle with shells and text utilities such as awk, grep and sed. Snover argued that this approach worked “despite serious drawbacks”, because each stage of a pipeline had to recover the data the previous stage had flattened into text. He called that “prayer-based parsing”.

His answer was a set of components, all named after Leibniz’s monads, the simple units that combine into everything else. One of them was the Monad Shell (MSH), “a .Net based script execution environment” that would expose small commands called Cmdlets through an interactive shell. The manifesto describes a working, if limited, prototype.

The version of the manifesto published later carries a note that it is “not an accurate description of how V1.0 works” and that its examples were “updated to reflect the current syntax”. Its code samples therefore cannot be treated as 2002-era MSH, and none are reproduced here.

From PDC to public beta

Microsoft first showed Monad in public at the Professional Developers Conference in Los Angeles in October 2003, the same PDC that introduced Windows “Longhorn”. It was widely expected to be Longhorn’s new command shell. Preview builds were distributed through Microsoft’s BetaPlace program in 2004. According to his InfoWorld review dated 29 October 2004, Jon Udell ran MSH on Windows XP with the .NET Framework 2.0 beta and pointed out, “You don’t need Longhorn, by the way.”

Releases under the MSH name were:

In June 2005, Senior Vice President Bob Muglia said Monad would not be in either the Longhorn client or server. Microsoft confirmed later that year that it would not be part of Windows Vista, and Exchange Server 12 became its first planned host product.

The rename

On 25 April 2006, Microsoft announced in Bob Muglia’s keynote at the Microsoft Management Summit that Monad was now Windows PowerShell and released RC1 the same day. The team blog headline was “Windows PowerShell (Monad) Has Arrived”. It explained that marketing had decided the technology deserved a “Marquee” name, meaning a name the company would put real marketing effort behind. The rename was more than cosmetic for users. msh.exe became PowerShell.exe, the script extension changed to .ps1, and developers were told to “search and replace MSH with PS” in the API names. TechNet Magazine added an editor’s note to its MSH article on 22 May 2006: “Monad has been renamed Windows PowerShell.” PowerShell 1.0 was released to the web on 14 November 2006.

Design Philosophy

The manifesto and the beta documentation describe the same goals:

• Objects, not text. “Instead of piping unstructured text, we pipe .Net objects.” A downstream command can use .NET reflection to find an object’s properties and methods, so it does not have to parse columns.
• Familiar to Unix administrators. The manifesto says the shell “is based upon and extends the Bourne Shell syntax and control structures facilitating the skill transfer of Unix Admins.” TechNet Magazine summed up the aim as a shell like the Korn or Bourne shells combined with “a rich programming language like Perl or Ruby”, built on .NET.
• One parser for every command. Unix tools each parse their own options. The manifesto names VMS DCL and AS/400 CL as the exceptions, because a shared command parser gave them consistent syntax. Monad adopted the same idea, so that every Cmdlet gets the same parameter parsing, error handling and messages.
• Composition. Cmdlets were meant to be small and do one task each. TechNet’s article says the team took the Leibniz idea of composition as the guide for “the syntax, naming conventions, and many other aspects of this product.”
• An engine, not just a console. Monad was a DLL that any application could host. msh.exe was one host. Management GUIs were meant to be others, so that an action taken in a GUI could also be repeated as a script.

Key Features

Cmdlets and verb-noun names

Cmdlets were .NET classes derived from a common base class and named with a verb-noun pattern: Get-Process, Get-Help, Clear-Host, Export-Csv. Aliases eased the move from older shells. Get-ChildItem answered to both dir and ls, and gm stood for Get-Member. These are examples from the 2005–06 beta articles:

get-process
get-process [rs]*
get-process w* -Exclude win*
get-help get-process

The beta articles also show the -WhatIf parameter, which describes what a command would do without running it.

An object pipeline

This example from Thomas Lee’s November 2005 TechNet Magazine column filters and sorts processes by a numeric property. No text parsing is needed, because $_ is the current Process object:

get-process | where {$_.handles -gt 500} | sort {$_.handles}

Udell’s 2004 review describes the same model. get-process produced System.Diagnostics.Process objects that could be filtered and passed to stop-process. Output could go to HTML, a .NET grid control or Excel, and objects could be converted to and from XML.

Variables are .NET objects

Variables start with $ and hold any .NET type. A type can be given with a cast. These lines are from the same TechNet column:

$one=1
$two=[int] 2
$one+$two

$dir=dir
$dir[1].name + " is " + $dir[1].length + " bytes long"
$dir | format-table Name, Length, Mode, LastWriteTime -auto

$date = [datetime]"10/1/2005"
$date.AddMonths(1)

Get-Member used reflection to list an object’s properties and methods. The column recommends it both for debugging pipelines and for learning the shell.

Providers

Providers presented different data stores as navigable drives, so the same Cmdlets worked on all of them. According to Lee’s column, the late-2005 beta included seven providers: Alias, Certificate, Environment, FileSystem, Function, Registry and Variable. Get-ChildItem listed files in a folder or subkeys in the registry.

Profiles, snap-ins and script security

• profile.msh: When msh.exe started, it ran a system-wide profile and then a per-user profile, both named profile.msh. Administrators used them for aliases and other customisations.
• MshSnapIns (Beta 3): An MshSnapIn grouped cmdlets and providers so they could be loaded into a running session with add-mshsnapin, unloaded with remove-mshsnapin and listed with get-mshsnapin. A Microsoft developer reportedly explained that the name meant “SnapIn from Msh” and was chosen to avoid confusion with MMC snap-ins. export-console saved the loaded set to a .mcf console file, which msh.exe could be told to load at startup through a command-line parameter (reportedly -m).
• Signed scripts: The shell had execution policies including AllSigned, RemoteSigned and Unrestricted. According to Lee Holmes of the Monad team, the betas used RemoteSigned, which required a signature only on scripts downloaded from the internet.

Evolution

MSH changed considerably during its three years in public view. Udell’s 2004 preview and the 2005 betas required pre-release versions of the .NET Framework 2.0. Beta 2 was reported to run on Longhorn builds, Windows Server 2003 SP1 and Windows Embedded. Beta 3, which BetaNews reported Microsoft describing as feature complete, added the snap-in model for loading cmdlets and providers at run time. Lee Holmes warned that older Monad scripts “may require slight adjustments” before they would run on newer builds. The release-candidate rename was the last big change. .msh scripts became .ps1 scripts, and Msh-prefixed types and cmdlets were renamed. The language that shipped as PowerShell 1.0 in November 2006 is a direct continuation of MSH, not a rewrite.

The “first Vista viruses”

In July 2005 a virus writer known as “Second Part To Hell” published proof-of-concept viruses written as MSH scripts. F-Secure named the family Danom, which is Monad spelled backwards. Several outlets called them the first Windows Vista viruses, because Monad was still expected to ship with Vista. Microsoft replied that they exploited no vulnerability and could affect only systems with Monad installed. Lee Holmes called the headline misleading: any shell that runs scripts can carry script malware. The episode shows how closely MSH was then associated with Longhorn. Redmond Channel Partner reported that Microsoft’s clarification that Monad would not be part of the Vista client was partly meant to correct those reports.

Current Relevance

MSH as a name and as a distribution no longer exists. No Microsoft download offers the beta builds, and .msh scripts need small changes to run under PowerShell. The language itself is still in wide use. PowerShell kept the object pipeline, verb-noun cmdlets, providers, $_, script blocks in braces and the -WhatIf parameter that MSH introduced. It became cross-platform and open source in later versions.

MSH therefore matters mainly as history. Its beta articles, blog posts and the O’Reilly book are the record of how the design looked before it was frozen as PowerShell 1.0.

Why It Matters

• It made the object pipeline mainstream. Other systems had passed structured data between programs, but MSH put the idea into a shell that Microsoft intended for every Windows administrator. The idea now appears in other shells: Nushell, for example, cites PowerShell as an inspiration.
• It changed how Microsoft builds management tools. The plan to build Exchange 12 and MOM on Monad, with GUIs layered over the shell, set a pattern that Microsoft server products followed for years.
• It is a clear case of a codename shaping a language. The Leibniz monad, a simple unit that combines into larger things, became the stated design principle behind Cmdlets, and the abbreviation MSH remained in the type names until the 2006 rename.

Sources

• Jeffrey P. Snover, Monad Manifesto, version 1.2, 8 August 2002, published version at jsnover.com.
• Thomas Lee, “Monad: The Future of Windows Scripting”, TechNet Magazine, November 2005 (editor’s update 22 May 2006). This is the source of the code examples, the provider list and the profile.msh details.
• Jon Udell, InfoWorld, 29 October 2004 (Monad review).
• Andy Oakley, “Hands-on: Learning Monad”, Computerworld, 17 January 2006 (get-process examples, -WhatIf).
• Microsoft blogs: “Monad Beta1 Released” (17 June 2005), “Mshsnapin (part 1)” (10 January 2006 per the original blog; the migrated devblogs copy is stamped 25 April 2006), “Single Shell vs Custom Shell” (Beta 3 snap-ins, .mcf files, export-console), “Windows PowerShell (Monad) Has Arrived” (25 April 2006).
• Lee Holmes, “Monad and the ‘First Vista Virus’” (4 August 2005) and “Monad Evolves to Windows PowerShell” (25 April 2006).
• eWEEK (9 June 2005), Redmond Channel Partner (14 September 2005), OSNews (17 June 2005 and 27 February 2006).
• Wikipedia, “PowerShell”, for the PowerShell 1.0 release date and the Beta 2 and Beta 3 day-level dates.
• Not independently verified: the exact Beta 3.1 build and date (OSNews headline only), the exact date of the PDC 2003 demonstration within the conference week, the Beta 1 announcement wording, the 1.3 MB Beta 2 size, the “SnapIn from Msh” explanation and the -m switch, and the Beta 2 platform list.