San Diego (CA) – At this morning’s session of the Microsoft Management Summit, the company’s senior vice president Bob Muglia is expected to announce that the next-generation command line tool for Windows – to this point, code-named “Monad” – will formally become a Windows component during the fourth quarter of this year, to be shipped via Web-based distribution. Beginning today, the product will be known as Windows PowerShell.
In an exclusive interview yesterday with PowerShell’s lead architect, Jeffrey Snover, and Microsoft spokesperson Scott Ottaway, it was revealed to TG Daily that Release Candidate 1 of PowerShell will be available for public download today from Microsoft’s Web site. PowerShell will also play a key role in Microsoft Exchange Server 2007, whose formal name will also be unveiled by Muglia this morning.
Beginning today, Ottaway told us, Microsoft will begin referring to PowerShell as the company’s command line tool for Windows. However, it will be cmd.exe – the command prompt based on MS-DOS – that will continue to be shipped with the installation disks of Windows Vista, as well as “Longhorn” server (whose own name is expected to be unveiled soon as “Windows Server 2007”). But Muglia is expected to reveal today that, as Microsoft slowly incorporates more and more support for PowerShell into its plans and marketing, PowerShell will indeed become a component that ships with the next editions of Windows – perhaps including the one code-named “Blackcomb” – to finally replace cmd.exe, said Ottaway, within the next two to four years.
In the months since it was revealed that Monad, a long-time project of Snover’s team, was due at some time in its future to become the Windows command line, the tool has amassed a broad and enthusiastic support base. The Microsoft Management Console has been, and will likely continue to be, the graphical tool which administrators will be trained on, knowledge of which will be critical for admins to receive certification. But the movement for, if not Microsoft, someone to build a reliable lexical tool for professional admins – many of whom were first trained in the verbal scripting environment of UNIX – has been building ever since Windows NT was first forked off into a server-oriented product line.
Rather than simply adapt someone else’s scripting language, or build some kind of “super-DOS” utility, Snover chose to start from byte one to create an entirely new, scriptable language that would characterize Windows in a way that DOS simply cannot. While UNIX and Linux admins were honing their skills on extensive, lexical tools like the Korn shell, Windows admins, unable to utilize the DOS-oriented command prompt for anything remotely close, were forced to find ways to automate processes in a graphical environment – to this day, with only marginal results. Knowing how complex a system Windows had already become, it was clear to Snover that any new lexicon would have to be thorough and extensive. So his goal was to let the language itself be replete with terms, but to craft the syntax of that language to be simple, straightforward, and consistent.
To say that the Snover team’s project goes against the grain, or swims against the current, or flies into the face of the tornado, is to understate their dilemma over the years. The guiding principle which drove all Windows development to date (which some say may have been borrowed from Apple, or if you go back further, from Xerox) boiled down, Snover said, to “recognition vs. recall. The argument in favor of the GUI is that, with the prompt, you have to recall what to type,” whereas a graphical environment always shows you what you can do. The benefit of GUIs is that they “contextualize the surface area,” as Snover visualizes them verbally, so that the functionality a program offers has some tangibility, some surface, to it. Yet that benefit only extends insofar as the surface can be made relatively flat, and the selections simple, Snover said. In demonstrations over the past few years, he’s reminded admins how many selections in Microsoft Management Console are over a dozen tiers deep. In such a case, “the advantage becomes not so much of an advantage.”
How the lexical pipeline works in PowerShell
While a lexical system of verbal commands is demonstrably more difficult to use for simple applications, its learning curve becomes less steep as the application grows more complex, compared to the learning curve for graphical environments. As a result, Excel can be kept simple, but MMC can become a maze of confusion.
Here’s an example of the kind of lexical environment Snover’s team has put together: There are dozens of PowerShell commands, called cmdlets (“command-lets”), but in the interest of absolute consistency, they all have a verb-noun syntax. For example, to retrieve the list of running processes in Windows, the command is get-process; the command for retrieving a property of a process or other item in memory is get-member; the command for assigning a value to a variable is set-variable; and for calling the help system, it’s get-help. Unlike BASIC or Python or any other scripting language, commands are not boiled down to their most abbreviated form; instead, they’re crafted to be consistently replete and self-descriptive, to help admins remember them.
It helps to think of PowerShell as like a pocket calculator in one important respect: The operations you perform on a calculator typically impact the value that you see in the display. PowerShell always has something that your commands are acting upon; once you invoke get-process, for instance, you can assume that PowerShell has “memorized” the results. So any successive cmdlet you invoke on the same command line will assume those results as its parameter. You connect cmdlets together using the | pipe character. So, for example, an instruction that retrieves the list of all addressable COM components in all running processes would look like this:
get-process | get-member
Similarly, the list of all COM components belonging to the running copy of Microsoft Word can be retrieved with this instruction:
get-process “WINWORD” | get-member
As you build up the command, you can retrieve just the list of addressable COM properties in Word:
get-process “WINWORD” | get-member -MemberType “Property”
Notice the switch syntax still applies to -MemberType, which describes the attribute you’re searching for. Then, as you’re building a script and you need a variable term to refer to the table of entries you’ve just acquired into memory, you can use another pipe to connect the results to the set-variable cmdlet, like this:
get-process “WINWORD” | get-member -MemberType “Property” | set-variable WordProps
This creates a variable that the script will refer to hereafter as $WordProps (all PowerShell variables are prefixed with a $). Or, you can create a log file that lists the results in something you can pull up in Notepad, like this:
get-process “WINWORD” | get-member -MemberType “Property” | format-list | out-path “C:WordProps.txt”
The result is what PowerShell calls a pipeline instruction. It’s long, and there’s a lot of typing involved, so Jeffrey Snover reminded us there will be tools to help the admin along, such as tab completion – a version of IntelliSense that fills in the rest of a command that you’ve already started, and that already has enough characters typed to be complete. In PowerShell RC1, Snover said, this feature will have been extended to complete, for instance, filenames and directory names in local storage.
One of PowerShell’s more exciting and distinguishing features involves the prompt itself: Typically, a prompt shows you what part of the system you’re “in” at the time, and historically, you’re in a directory – part of the file system. With PowerShell, your “drive” may start out as a directory, but it can become almost anything at all that’s addressable in a tabular data format. For example, the prompt can be “in” the Windows System Registry. Using either cmdlets or DOS-derived alias terms, a PowerShell user can peruse the Registry, and can “mount” the registry as though he’s changing drives. For example, the cmdlet set-location HKLM: has PowerShell mount the HKEY_LOCAL_MACHINE base tier of the Registry, where application classes are listed. The alias cd works in place of set-location as well. So typing cd software would take you in this case to the Software tier of the Registry, and the prompt would show you that. From there, aliases such as copy, move, and delete work on Registry entries in exactly the same way they work on file entries in MS-DOS.
Security, and the uncertain future
Although PowerShell itself is a small distribution (just a few megabytes in size), it does require .NET Framework 2.0; it is, in fact, a .NET language implementation, interfacing with .NET’s Common Language Runtime (CLR). So PowerShell is indeed the “.NET language” that users were expecting back when Microsoft first announced .NET to an eager public back before the turn of the decade.
Over the last several months, Snover told us, the wellspring of independent support for the Monad project has been not only gratifying to him, but unlike anything Microsoft may have seen before. Users have helped build this product, he said, even though it’s far from being an “open source” project; they’ve hardened the concepts and help rigidify the underpinnings of the syntax, to help keep this product consistent with its original goals, in a way that hasn’t been possible with Microsoft products whose development processes have been kept under wraps.
Soon after news of the Monad project was made public last year, a scare arose that something this potentially powerful could be easily utilized maliciously. Thus it was that rumors of the first “Monad virus” or even “Vista virus” became spread. Indeed, there was no virus; there was only an attempt at a proof-of-concept which, it was not reported at first, didn’t even actually work. But concerns remained: Since VBScript had been exploited so successfully in the past to build the “ILOVEYOU” Outlook e-mail virus, and all its many derivatives, couldn’t PowerShell be leveraged in a similar fashion, perhaps with more cunning?
Security, Jeffrey Snover told TG Daily, is one of this product’s guiding principles. “You can’t swing a dead cat without hitting a security feature in this product,” he said. First of all, after it’s installed, PowerShell’s script-ability is turned off by default, for what is called restricted mode. It can execute instructions from the command line, but nothing from a file. To enable it to run scripts, an admin can set PowerShell to run only those scripts that have been digitally signed (all-signed mode), or more leniently, to only run scripts from remote locations that have been digitally signed, but all local scripts without challenge (remote-signed mode), or to simply run all scripts. However, the latter mode (unrestricted) will not be recommended, and users will still see “Are you sure?” prompts before launching. Furthermore, Microsoft Outlook’s ability to run any PowerShell scripts (or its Monad predecessors) will be permanently disabled. You can send the text of scripts via e-mail, though that text cannot be executed from the message itself.
Starting today, Microsoft will begin making its already extensive collection of educational material and product support for PowerShell (some of which, admittedly, still refers to “Monad”) available through its new Web site. From now on, we’re told, server admins should expect to see cmdlet capabilities shipping with server and administrative tools, including about 50 cmdlets for Microsoft Operations Manager (whose new name may also be revealed today), and about 400 cmdlets for Exchange Server 2007. Conceivably, new Microsoft applications may make available, or at least make way for, packages of cmdlets that enable their scriptability and control by administrators and power users.
Not everyone will want to use PowerShell (not everyone likes to use the DOS Command Prompt), but long-time Windows users who have grown perturbed at its lack of responsiveness and its resistance to being directly addressed, will likely embrace this new tool, perhaps as the very thing that will make Windows truly usable. Like Ray Ozzie’s projects with Windows Live, Jeffrey Snover’s big adventure has become part of the wave of change at Microsoft, the trend toward interoperability, and perhaps the beginning of the breakdown of Windows’ facade of imperviousness and inapproachability. Whether Microsoft as a company wishes to acknowledge it or not, a huge change in Windows begins today.
