PowerShell Essentials (Part 8)

If you would like to read the other parts in this article series please go to:

So far in this article series, I have shown you how to do all sorts of cool things using Windows PowerShell. As I sat down to write this article however, it occurred to me that I had never taken the time to talk about PowerShell’s capabilities and limitations.

In recent years, Microsoft has had a big problem with lack of consistency. Let’s take Windows 8 for example. There are actually four completely separate Windows 8 platforms – PC, Windows Phone, Windows RT, and Xbox One. The really crazy thing is that these various Windows platforms are not compatible with one another. Each has its own app store and the apps that you download from one app store are not compatible with other device types. You can’t for instance run a PC app on Xbox One.

You might have heard a lot recently about Windows 10 and universal apps. Universal apps are Microsoft’s attempt at cleaning up the mess that has been brought about by platform inconsistency. Supposedly universal apps will be able to run on any Windows 10 device regardless of whether it is a PC, tablet, phone, or whatever.

So what could all of this possibly have to do with PowerShell? Well, Microsoft has had similar struggles when it comes to the command line. Earlier versions of PowerShell were extremely limited. There were relatively few cmdlets available, plus there were multiple command line interfaces to choose from. More recent versions of PowerShell are much more powerful. The current version of PowerShell supports thousands of native cmdlets, add-on cmdlets (that can be imported through modules), and legacy commands from other environments.

So what are these legacy commands? Well, they come in two different forms. The first legacy command type could best be described as DOS commands. I grew up during the 80s and back then if you had a PC you were using something called Disk Operating System, or DOS. The DOS environment included numerous native commands and even had its own scripting language that was often referred to as batch programming.

Most of the earlier versions of Windows were graphical platforms that ran on top of DOS. Modern Windows operating systems are true operating systems that are based on the NT Kernel instead of on DOS. Even so, even the newest Windows versions include a Command Prompt window that fully supports DOS commands that were first brought about over 30 years ago.

Early versions of PowerShell adopted a few DOS commands, such as CLS, which clears the screen. To say that these versions of PowerShell fully supported DOS commands however, would have been completely inaccurate. Most DOS commands were not supported.

Newer versions of PowerShell include support for the vast majority of the DOS commands that I have tried using. Although some sources indicate that PowerShell fully supports all of the same commands as the Windows Command Prompt however, it doesn’t actually support all of them. PowerShell supports most of the DOS commands that you are likely to use on a regular basis. It’s mostly the more obscure commands that are missing.

So what commands are missing? I honestly don’t know. I have never seen a comprehensive list outlining supported and unsupported commands. Even so, I can give you an example of a missing command.

There was a time when DOS did not include a text editor. Back then if you wanted to create a text file, batch file, or whatever you had to enter the following command:

COPY CON <your filename>

After entering this command you could type the file’s contents and then press Ctrl+C. This would create a file using the name that you specified. As you can see in Figure A, this method still works using the Windows Command Prompt environment.

Figure A: The COPY CON command works in the Windows Command Prompt window.

Now check out Figure B and you will see what happens if you try the same thing in PowerShell.

Figure B: The COPY CON command does not work in PowerShell.

So is this a big problem? Probably not. Almost nobody uses COPY CON anymore. As I said before, PowerShell supports most of the old DOS commands that you are likely to need, but it doesn’t support every DOS command.

Earlier I mentioned that there was another type of legacy command that is supported within PowerShell. I don’t really know what to call these commands, so I will call them legacy Windows commands. As previously mentioned, DOS had its own command set. Later, versions of Windows such as Windows 95 and Windows XP introduced some new commands that weren’t a part of the original DOS command set. These new commands were used within the Command Prompt window.

The current version of PowerShell seems to fully support these newer commands. One example of such a command is Net. The Net command can be used for a lot of different things. Suppose that you wanted to view your computer’s drive mappings. To do so, you could use the NET USE command, which you can see in Figure C. You can even use NET USE to create new drive letter mappings.

Figure C: PowerShell supports the Net command.

Of course Net is only one example of command line environment commands that are supported through PowerShell. All of the “extended command set” commands that I have tried to use have worked through PowerShell.

As you can see, PowerShell is far more capable than it has ever been in the past. Even so, PowerShell does have its limits. PowerShell cmdlets do not exist for every conceivable purpose. Luckily, PowerShell is extensible. In fact, there are three different ways to extend PowerShell’s capabilities.

The first method involves writing your own cmdlets. This topic is beyond the scope of this article series (maybe I will cover it in a future series if there is enough interest), but Microsoft gives you all of the tools that you need to create PowerShell cmdlets to do whatever you want.

The second way that PowerShell is extensible is through the use of modules. Modules are essentially collections of non-native cmdlets. You can import a module into PowerShell by using the Import-Module command. There are dozens of modules available for download both from Microsoft and from third party sources. For example, you might use a module to extend PowerShell so that you can use it to manage Microsoft Azure.

The third way in which PowerShell is extensible is the most powerful of all. As I briefly mentioned in my previous article, PowerShell can take advantage of .NET. The .NET environment makes it possible to do things that PowerShell isn’t capable of doing on its own. For instance, if you want to do advanced math through PowerShell then you can do so by leveraging the power of .NET.

Conclusion

I had originally planned on discussing .NET in this article, but will cover it in Part 9 instead. For those of you who are not developers, let me assure you that leveraging the .NET environment through PowerShell is surprisingly easy to do. I will show you how in my next article.

If you would like to read the other parts in this article series please go to: