Windows PowerShell, PowerShell Core and PowerShell: Huh?
Welcome to the first part of our 12-part series, Getting Started with PowerShell! Unlike future posts in this series, most of this article will take a step back from the how-to nature of this series. We're going to start out with a short history lesson on Microsoft PowerShell development.
Why a history lesson and not just dive into coding? Because this blog series will not be the only resource you use to learn PowerShell scripting techniques - at least I hope not! As such, when you go Googling for answers, you'll find a wide range of answers out there from years ago up to today. You need to understand the three different names PowerShell has held along its development cycle and how the behavior of PowerShell has changed over that time.
You'll see people throwing out code left and right that might work in one version of PowerShell but not another. It's important to know the differences at a high level to help you hone in to find answers that are applicable to you and your situation.
Windows PowerShell Was Just the Beginning
Windows PowerShell was introduced back in 2006. At the time, it was an optional feature bundled with a product called the Windows Management Framework (WMF). This was a software package that contained many different components to manage Windows. If an admin wanted Windows PowerShell, the entire WMF package had to be installed.
Note that Windows PowerShell still technically is a part of WMF but is more or less considered a separate component.
Throughout the years, Windows PowerShell continued along a trajectory adding features like PowerShell Remoting, Desired State Configuration (DSC), scheduled jobs and a whole lot more.
Although Windows PowerShell itself evolved over time, one constant remained. Windows. Windows PowerShell was informally called PowerShell by scripters but the "official" Microsoft term was always prepended with the word 'Windows'. Why? Because it only worked on Windows.
Sure you could reach out to Linux via various remote options but it was impossible to install Windows PowerShell on any other platform. Being dependent on the Microsoft .NET Framework, Windows PowerShell was stuck on Windows whether the internal Microsoft PowerShell team wanted to be there or not.
As you might expect, Windows PowerShell was built without any kind of cross platform agenda (Linux, MacOS, etc) in mind. It was built from the ground up around Windows until the "new" Microsoft caught up with the PowerShell team at Microsoft and open source was embraced.
Windows PowerShell (then 5.1) was the last version released and is no longer under active development.
'PowerShell' was Windows PowerShell until 2016 came around.
The Move to PowerShell Core
It was in 2016 when Microsoft announced that a new version of PowerShell was being released called PowerShell Core. PowerShell Core was to be open-source developed entirely on GitHub and also available not only on Windows but Linux, macOS, and other *nix operating systems.
The Microsoft PowerShell team had rebuilt 'PowerShell' under the more slimmed down and cross-platform .NET Core. Under .NET Core, PowerShell Core was now able to run on all the platforms!
But making a change that big had some downsides. PowerShell cmdlets that just worked in Windows PowerShell failed to work correctly or not work at all. There were many bumps along the road to Core but as of PowerShell 6.1 at least, the mission was to bring Windows PowerShell and PowerShell Core in feature parity.
It wasn't until PowerShell Core v6.2.4 that Windows PowerShell and PowerShell Core were close enough for Microsoft to make it easy on us and change the name.
Let's Just Call it PowerShell
As of this writing, PowerShell 7 is the most recent version of PowerShell. Not to be confused with calling 'Windows PowerShell' or 'PowerShell Core' informally as PowerShell. As of 2019, "PowerShell" is PowerShell and that PowerShell is PowerShell running on .NET Core.
Make sense? If not, remove the phrases 'Windows PowerShell' and 'PowerShell Core' from your vocabulary and just stick with 'PowerShell'. You'll be just fine.
Takeaways and What You Need to Know
If you got anything from this first post, know this. The most important takeaway for you, PowerShell newcomer, is that the PowerShell language has had an interesting history. Although history doesn't directly impact your day-to-day activities, it will save you some unnecessary headaches down the road.
A few other important points to know are:
As of PowerShell 7, most functionality is on par with Windows PowerShell. There are many nuances so if you have a Windows PowerShell script, you will need to test it.
If you're creating a new PowerShell script today, start with PowerShell 7. Do not write a script and test with Windows PowerShell.
As you learn more about PowerShell by watching YouTube videos, online courses and take advice from others always ensure the instructors are using the same flavor of PowerShell you are.
