Top 10 Windows 7 Features #9: Native PowerShell 2.0

Ever since the command-line tool code-named Monad escaped by the skin of its fingernails from Microsoft's laboratories in 2006, there has been debate and dispute over whether the company has finally, once and for all, replaced DOS. Since that time, we've seen the arrival of an entirely new generation of Windows users who believe "DOS" is an acronym for "denial of service," and who are baffled as to the reasons why anyone would want to command or control an operating system using text.

It isn't so much that text or command-line syntax is the "old" way of working and that Microsoft Management Console is the "new" way. As Microsoft discovered, to the delight of some in its employ and the dismay of others, using the command line as the fundamental basis for Exchange Server improved its usability and efficiency immensely. The graphical environment simply does not translate well -- or to be fairer, not effectively -- to the task of administration.

As of last October and up through today, at least, Microsoft's often variable plan on PowerShell has been to include it with every SKU of Windows 7 and Windows Server 2008 R2. We will not be surprised if we suddenly discover it isn't included with the Home Basic edition, but its inclusion even there would be an indication that Microsoft is confident about being able to hand over the real-world equivalent of Doctor Who's "sonic screwdriver" to every Windows 7 user in existence.

PowerShell can be used exactly like DOS, as it maintains a vocabulary of "aliases" that recognize DOS commands as alternates, but it is not DOS. Rather, it is a very sophisticated administrative language designed not for programmers or for veteran developers, but instead for admins and system managers who need the ability to communicate a lot of information in as little space as possible.

Looking at just the front end, PowerShell takes the user right back to the TRSDOS era, with a blinking cursor beside a carat. But from there on, the resemblance to the 1970s becomes fleeting and momentary. You do not have to learn the MS-DOS batch file language to create a simple script that enables you to make a common fix. That doesn't mean learning PowerShell isn't a skill in itself -- it is, believe me. But its principles of consistency and economy of verbiage (something I myself may yet aspire to) enable anyone to theoretically craft and deploy a safe and powerful set of free tools that easily substitute for a myriad of commercial anti-malware and system tune-up programs.

Here's an example I created for a tutorial on PowerShell for InformIT last November: Imagine in your mind an MS-DOS batch file whose purpose is to scan the running processes in Windows, find Windows Media Player, and make a log of the amount of available system memory whenever it does find that app. Assuming there were some kind of API for running Windows processes in DOS (and there never was), the amount of conditional statements and print formatting instructions would make such a script enormous.

With PowerShell, I managed the entire concoction in just two instructions:

Now, there's a lot going on with these two instructions, thanks to PowerShell's ability to compress a lot of instruction in a little space. The first line, for example, actually creates a little database table in memory, and formats it for the columns needed for this little log file. Each of those columns is given a name, just as though we were building this table for MySQL or SQL Server. The format becomes a kind of template string in memory, which is given the name $table (TRS-80 veterans will remember the old BASIC language where the $ character fell at the end of the string variable name rather than the beginning).

The second instruction is actually in four segments, and each segment passes on its results to the next by means of the pipe | character. Commands that are native to PowerShell are called cmdlets (pronounced "command-lets"), and they all have a verb-noun syntax. There are dozens of cmdlets that start with get, and because the syntax is consistent, it's easier to remember which command does what function. The get-process cmdlet is fairly self-explanatory, in that it generates a list of running processes. If the instruction stopped there, it would generate that list on-screen, but instead the pipeline takes the output to a where function that filters it. During this process, the output of get-process behaves like an object, as in "object-oriented language," so you can refer to the members of the object like properties. This script aligns those properties with the template created for the $table variable.

Next: How far does PowerShell 2.0 go?