1(ORIGINAL) This is not a Windows PowerShell whitepaper nor is it an accurate description of how V1.0 works. This is a version of the original Monad Manifesto which articulated the long term vision and started the development effort which became PowerShell. Many of the elements described in this document have been delivered and those that have not provide a good roadmap for the future. The document has been updated for publication. Confidential information has been culled and examples are updated to reflect the current syntax.↩

2(ORIGINAL) Monads are Leibniz’s term for the fundamental unit of existence that aggregates into compounds to implement a purpose. In this philosophy, everything is a composition of Monads. This captures what we want to achieve with composable management. More information on Monadology can be found at: http://www.wise.virginia.edu/philosophy/phil206/Leibniz.html↩

3It should be noted that PowerShell very nearly didn’t exist because of its dependency on .NET. At the time, in 2004-2006, a startling number of high-profile managed code projects were failing, contributing to the delays in Windows Vista. Running around Microsoft preaching about some management scripting language written in .NET wasn’t politically correct at the time. In fact, it was so risky that the Exchange Server team actually built in entire intermediate API under their PowerShell cmdlets, on the theory that they could trash the cmdlets and switch to something else more easily, if needed.↩

4Version 1 of PowerShell shipped in 2006, and provided the implementation for these cmdlets. Cmdlets today are written in .NET languages, and consist of a single class per cmdlet. PowerShell provides a base class that does much of the heavy lifting; developers define properties of the class that become parameters, and override specific methods to participate in the pipeline lifecycle. Cmdlets, along with the overall environment, were the first of four major vision points proposed in the Manifesto.↩

5Remoting was introduced in PowerShell version 2, which shipped in the box with Windows Vista and Windows Server 2008. Remoting is the second of the four major vision points proposed in the Manifesto.↩

6Although never exposed as an MMC per se, PowerShell’s engine was implemented as a .NET class. Any .NET application can instantiate the engine, run commands, and translate the output into a GUI display. Exchange Server 2007 was the first product to do so, and remains one of the best examples of the “full-on PowerShell approach” to administration.↩

7APIs in fact, are the main differentiator between Windows and Linux/UNIX systems. On Linux/UNIX, everything essentially looks like a folder or a file, and nearly every bit of configuration is in a loosely-structured text file. Automating administration in that environment is easy, because you only have one API: text files. Windows is harder because to do anything, you’ve got to learn that something’s API - and all the APIs are different. Knowing how to add a user to Active Directory doesn’t help you create a site in SharePoint - they’re all different APIs.↩

8Misses, in other words, the point, because VBScript is basically a simplified way of dealing with APIs that were meant for developers. VBScript also assumes that product teams have created dedicated, VBScript-compatible APIs, which most didn’t. Getting anything done with VBScript was often complicated, and always hit-or-miss.↩

9(ORIGINAL) Administrative scripting is often the progression from ad hoc scripts to automated operations. Admins notice that they type the same commands over and over again so they build a script. The notice that their scripts contain lots of the same things so they produce parameterized subroutines and progress from there.↩

10Snover felt strongly about layering GUIs on top of command-line. That’s in part because it’s how many Linux/UNIX administrative GUIs do things, but it’s mostly because doing it that way forces you to ensure that everything can be done from the command-line. The GUI doesn’t become a special class of citizen holding special, unique powers; it’s just another consumer of the command-line. The command-line, in turn, can be much more easily consumed by other consumers than a GUI could be.↩

11Traditional in the Linux/Unix world; certainly not in Windows. This is in fact the change Snover was proposing: to make administrative administration work more like it does in Unix, since Unix is a decades-proven model for success. It probably didn’t hurt that Snover came from Digital Computer, a company with more than a passing familiarity with Unix variants and similar operating systems.↩

12These examples emphasize the influence mainframe and UNIX had on Snover’s design choices. ↩

13People who view PowerShell as a “linux-ification” of Windows should note that Snover wasn’t enamored of the Unix command-line model. He felt it was inconsistent (and, having grown organically, it is) and often lacked good semantics. In many ways, PowerShell was the first “second comer” to Unix’s command-line model, taking its strengths but re-thinking what had become somewhat obvious weaknesses.↩

14Practical upshot of this is that tools - cmdlets, in the PowerShell world - should do one thing, and one thing only. Get objects, process objects, or format objects into text - pick just one, and do only that. If you do more than one, you start creating a monolithic tool that’s less easy to re-use elsewhere. This do-one-thing concept has become a driving foundation for best practices in the PowerShell community, especially around toolmaking.↩

15There’s an enormous point here that’s often missed. When you write a tool that produces text, downstream tools have to know how to process that text in the exact format you produced it. Your data is unstructured. If you change the output of your tool, everything that used to work with it, won’t. Object orientation - that is, presenting data in a standardized structure that could be consumed by anything understanding “objects” - was one of the biggest differences between PowerShell and what had come before. Much of a Linux admin’s time is spent in the grep/sed/awk cycle, since they’ve got to parse out text so the next tool has data to work with; PowerShell all but eliminates that entirely ancillary work.↩

16Realistically, COM could have provided the same capabilities as it was object-oriented. However, by the time the Manifesto was written, COM was effectively deprecated and Microsoft had moved on to .NET.↩

17Meaning, most developers won’t implement interfaces that administrators can use to manage the application. At best, a “lazy” developer might simply put all their configuration information into a text file and call that “manageable.” Ironically, that’s essentially how Unix is built from the ground up, and it is manageable, because there’s little as easy as modifying a text file, especially if it’s structured (as in JSON or XML).↩

18ORIGINAL: UNIX has the getopt() call for simple command option parsing.↩

19ORIGINAL: VMS DCL and AS400’s CL are the exceptions to this. They provide a common command parser so the commands that use this have a high degree of syntactic consistency.↩

20Which is why developers hate making them and admins hate using them.↩

21ORIGINAL: There is a wonderful synergy between programmer’s desire to minimize the amount of code they write for management and customers desire to have a consistent management experience.↩

22This is the model PowerShell adopted. Cmdlets are instances of a class, which they inherit as their base. That class provides a ton of common functionality, so that the actual code in a cmdlet is around 99% focused on whatever it is that cmdlet is doing. The cmdlet developer doesn’t focus on parsing command-line arguments, validating mandatory items, etc.↩

23Prayer based parsing is when you parse the text and pray that you got it right. e.g. Cut off the first 3 (or was it 4?) lines, cut out column 30-40 (assuming that those spaces are not tabs), cast that as an integer (hmm. – does anyone use 64 bits?…well let’s just hope its 32 bits).↩

24An “object” in this sense is little more than a set of structured data, not unlike a database table or a spreadsheet. Each object represents some management component, and its properties represent bits of information about that object. Commands don’t have to parse these objects to find data, because .Net understands the object structure and can simply retrieve bits of information by referring to the property names.↩

25One of the first oblique references to what became PowerShell Remoting, which is indeed a web service based on WS-MAN (Web Services for Management).↩

26PowerShell never really went with specific base classes for these different scenarios, but this is the origin of PowerShell’s standardized list of verbs to be used in cmdlet names. This concept also drove the creation of the PSProvider and PSDrive abstraction, wherein any data store could be exposed as a “disk drive,” thus enabling a standardized set of commands to manipulate any data store so exposed.↩

27Briefly, during development, PowerShell’s “script cmdlets” (now, “advanced functions”) did have a syntax similar to this. In C#, cmdlet source code still looks a lot like this.↩

28ORIGINAL: “Get-EventLog application” is provided by the sample code above and the rest come from the Monad base commands. “Group source” counts the number of objects that have the same value for a particular property (i.e. how many times did a particular source show up?). “Select -First 5” truncates the set of objects to only have the first 5. “Format-Table” formats the objects and their properties a table↩

29Note that even in this document, Snover wasn’t consistent about “CmdLet” versus “Cmdlet.” Today, “cmdlet” is the standard. His original idea was to emphasize that a “cmdlet” wasn’t a “full command” with all the parsing and whatnot a traditional command implemented; instead, it was a portion of a command, with much of the overhead being provided by the automation engine’s base classes.↩

30Meaning, a .NET developer can tell the .NET runtime to perform certain standardized tasks. You see this a lot in PowerShell: for example, a function can declare a parameter as mandatory, and the shell will enforce that attribtue rather than the function developer having to write logic to do so.↩

31ORIGINAL: Msh will be able to seamlessly invoke legacy commands and legacy shells will be able to seamless invoke Msh CmdLets. (Msh will provide a mechanism to export CmdLets for access from the legacy shells) [In fact, PowerShell never implemented an easy way for legacy commands to invoke cmdlets]↩