As touched on in Chapter 2, Pipelines , PowerShell makes life immensely easier by keeping information in its native form: objects. Users expend most of their effort in traditional shells just trying to resuscitate information that the shell converted from its native form to plain text. Tools have evolved that ease the burden of working with plain text, but that job is still significantly more difficult than it needs to be.
Since PowerShell builds on Microsoft’s .NET Framework, native information comes in the form of .NET objects—packages of information, and functionality closely related to that information.
Let’s say that you want to get a list of running processes on your system. In other shells, your command (such as tlist.exe or /bin/ps) generates a plaintext report of the running processes on your system. To work with that output, you send it through a bevy of text processing tools—if you are lucky enough to have them available.
PowerShell’s GetProcess cmdlet generates a list of the running processes on your system. In contrast to other shells, though, these are fullfidelity System.Diagnostics. Process objects straight out of the .NET Framework. The .NET Framework documentation describes them as objects that “... [provide] access to local and remote processes, and [enable] you to start and stop local system processes.” With those objects in hand, PowerShell makes it trivial for you to access properties of objects (such as their process name or memory usage) and to access functionality on these objects (such as stopping them, starting them, or waiting for them to exit).
