By Scott M. Fulton, III, Betanews
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:
$table = @{Expression={$_.VM};Label="Memory";width=10},@{Expression={$_.CPU};label="Uptime";width=10}, @{Expression={get-date};Label="Time";width=24}
get-process | where {$_.ProcessName -match "wmplayer"} | format-table $table | out-file "mediaplayer.log" -append
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?
The extent of PowerShell's language capabilities are actually almost overwhelming, due to the fact that it can connect with essentially everything in Windows. For example, since PowerShell is effectively a .NET language, the entire .NET intermediate type libraries are available to PowerShell -- so any running .NET program may be addressable as an object. Also, any program using the type libraries of the older Component Object Model may be addressable and manipulable through PowerShell -- and that includes all of Office 2007. The same document objects for Word and Excel, for instance, that were made to be addressable in VBA for macros, is also by definition addressable in PowerShell.
But easily the most eerily cool feature -- the one that always makes newcomers fall backwards in their chairs the moment I show it off -- is the ability to make different types of navigable database structures "crawlable" like directories in DOS. Meaning, you can "mount" the Windows System Registry as though it were a disk drive (try this for yourself: cd HKLM:, for HKEY_LOCAL_MACHINE). Then you can copy, move, and delete keys and settings as though they were files, and tiers as though they were subdirectories.
Beginning with Windows 7 and WS2K8 R2, there will be two modes of operation for PowerShell. First there's the command line in use since the days of the Monad beta, and it can fully substitute for CMD.EXE. Win7 users will find it in their Accessories folder under Windows PowerShell.
But there's also an attractive integrated scripting environment (ISE) that gives a script writer for the first time the kind of workbench that developers have had at their fingertips since Visual Basic 1.0. There's a tabbed scripting window for multiple scripts, with automated syntax highlighting and error checking; an "immediate window" for dropping little quizzes (or little bombs) into a running version of PowerShell; and a scrolling output window like paper tape.
Now, the question that's always on skeptics' minds at this point -- with very good reason -- concerns security. The most influential viruses of the turn of the decade were simple VBScript files that masqueraded as different types of attachments in Outlook e-mail messages, and sending them to victims was, for the perpetrators, like shooting ducks in a gallery. Microsoft's greatest fear for the last several years is a repeat occurrence of the "ILOVEYOU" fiasco. In 2005, someone working with an early Monad beta generated a proof-of-concept of an early TRS-80 BASIC "virus" that a security software company immediately branded as the "first Vista virus," even though a) it infected no one, and b) it delivered no malicious payload even in the proof-of-concept.
But that was before PowerShell implemented its key security feature, which to date has been at least as effective as the DHS has been in thwarting successive terrorist threats: By default, PowerShell cannot run scripts at all. You have to change the operating mode of the interpreter so that it can; and when you do, you can choose to only open the doors a little bit. For instance, you can have it only run scripts that have been digitally signed and authenticated by you and no one else. Or you can have it run scripts whose digital signatures you trust.
Last October, PowerShell creator and Microsoft architect Jeffrey Snover told a story for his blog...and yes, he looks and sounds in person pretty much like he writes for his followers, especially when he spread the news of PowerShell 2.0 in Win7:
"One of my moments of clarity came during one the security crises a few years ago. [Former Microsoft President] Jim Allchin set out an e-mail with instructions for how to configure your machine to avoid the problem and told us to get all of our friends and family to do the instructions. The instructions started with 'go the Start Menu then go to All Programs then.. then.. then… then… click…then…click…then…click…' OMG! I can't follow instructions so I keep screwing it up over and over again. I eventually got it done but then thought to myself, 'Wait -- I'm supposed to call up my folks and have them do this?' That is a phone call that never got made. I remember thinking, 'This is freaking crazy! If Jim gave me a command line, I'd just cut and paste it and be done. I could get my folks to cut-n-paste a command line!' There were only two problems with that story: 1) PowerShell wasn't installed on my folks machine and 2) PowerShell wasn't written at that time. We are now on a path were this is going to be simple and easy to do."
FOLLOW THE WINDOWS 7 TOP 10 COUNTDOWN:
Copyright Betanews, Inc. 2009