#NATIVE APP WRAPPER WINDOWS#

There are a number of very excellent and vital standalone tools that target the scenarios for administration and management very well. PowerShell spent much of its first decade in building up a large number of tools for system management, but does not have cmdlets for all aspects of administration on all platforms. It’s a way to get help from the application.

#NATIVE APP WRAPPER WINDOWS#

Microsoft Windows may provide /?, but the point is the same. Additionally, UNIX systems have man pages and the mostly ubiquitous -help for getting assistance directly from the command.

Every shell has the capability of executing utilities, you could argue that this is the main use for a shell and PowerShell is no different. Some of these are not unique to PowerShell, and many tools also provide some of these behaviors. output consisting of objects (no text parsing).a single parameter parser so errors about mis-parameter use are consistent across all commands.consistent parameter naming for similar uses.PowerShell provides a number of benefits to its users In the second post, I’ll be exploring some of the work to more easily convert the use of native tools into the cmdlet/object output model of PowerShell. In the first post, I’m going to discuss a few of the ways that PowerShell can better incorporate native executables into our object oriented world and how we can use these tools to better fit into our model of more discrete operations.

In this two part blog post I’m going to investigate how PowerShell can take better advantage of native executables.

Native app wrapper