PowerShell 7.x, Windows PowerShell 5.1, Editions, and Compatibility

1. Why Windows PowerShell 5.1 and PowerShell 7.x both exist

If you work on Windows, you may find two executables with similar names: powershell.exe and pwsh.exe. They are related, but they are not the same engine. This distinction matters because a script can succeed in one and fail in the other even on the same computer.

Windows PowerShell 5.1 is the final version of the original Windows-only PowerShell line. It ships as a Windows component on supported Windows systems and is closely tied to the Windows/.NET Framework ecosystem. PowerShell 7.x is the modern, open-source, cross-platform line. It runs on a modern .NET runtime and is available on Windows, Linux, and macOS.

Microsoft intentionally allows the two products to exist side by side on Windows. Installing PowerShell 7 does not replace Windows PowerShell 5.1. That is useful because an organization can adopt modern PowerShell for new automation while retaining Windows PowerShell for a legacy module or administrative surface that has not moved cleanly to PowerShell 7.

2. “Desktop” and “Core” are edition identifiers, not operating systems

PowerShell exposes an edition name in $PSVersionTable.PSEdition. Windows PowerShell 5.1 reports Desktop. PowerShell 6 and later report Core. The word Core survives as an edition identifier even though the modern product is normally called simply PowerShell, not “PowerShell Core.”

Do not interpret Core as “Linux.” PowerShell 7 on Windows also reports Core. Edition describes the PowerShell family and runtime architecture, not the operating system.

$PSVersionTable.PSVersion
$PSVersionTable.PSEdition
[System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription
[System.Runtime.InteropServices.RuntimeInformation]::OSDescription

On a current PowerShell 7.6 environment, the runtime description will identify a modern .NET 10 runtime. On Windows PowerShell 5.1, the runtime is the Windows-only .NET Framework generation. That runtime difference is one reason binary modules and APIs can behave differently between the two engines.

3. pwsh and powershell.exe select different engines

The executable name is a practical compatibility signal. Modern PowerShell uses pwsh on Linux and macOS and pwsh.exe on Windows. Windows PowerShell uses powershell.exe. On Windows, both can be installed and launched independently.

(Get-Process -Id $PID).Path
$PSHOME

Get-Command pwsh -ErrorAction SilentlyContinue |
    Select-Object Name, CommandType, Source, Version

Get-Command powershell.exe -ErrorAction SilentlyContinue |
    Select-Object Name, CommandType, Source, Version

-ErrorAction SilentlyContinue tells PowerShell not to display a non-terminating error if a command is absent. You will study error behavior formally in Chapter 10. Here it lets the same inspection snippet run safely across platforms where powershell.exe does not exist.

On Windows, a common side-by-side arrangement is Windows PowerShell under the Windows system directories and PowerShell 7 under a separate PowerShell installation directory. Do not hard-code either path in production merely because it matches one machine. Resolve the executable and verify what actually runs.

4. Read $PSVersionTable as evidence, not decoration

Beginners often print $PSVersionTable and move on without interpreting it. In production, these fields help explain why a script behaves differently between hosts.

$PSVersionTable

The most useful fields at this stage are:

• PSVersion — the engine version. A script may depend on language features or cmdlet behavior introduced in a particular release.
• PSEdition — Desktop for Windows PowerShell 5.1 and Core for modern PowerShell.
• GitCommitId — build identity for modern PowerShell releases; useful in diagnostics.
• OS and Platform — environment information that helps distinguish Windows and Unix-like hosts.
• PSCompatibleVersions — historical compatibility information. Do not treat it as proof that every module or script written for an older version will work.

A better diagnostic report extracts the fields you need explicitly:

[pscustomobject]@{
    PSVersion    = $PSVersionTable.PSVersion.ToString()
    PSEdition    = $PSVersionTable.PSEdition
    GitCommitId  = $PSVersionTable.GitCommitId
    Platform     = $PSVersionTable.Platform
    OS           = $PSVersionTable.OS
    Runtime      = [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription
    ProcessPath  = (Get-Process -Id $PID).Path
}

This report distinguishes three layers: the PowerShell engine, the runtime that hosts it, and the operating system beneath it. When troubleshooting compatibility, those are separate facts.

5. “The script is PowerShell” does not guarantee module compatibility

A module is a package that can provide PowerShell commands, functions, providers, variables, and other resources. Modules are how many administrative and cloud capabilities are delivered. Some modules are written entirely in PowerShell and are highly portable. Others wrap Windows-only APIs, depend on .NET Framework assemblies, require a particular product installation, or assume a Windows service that does not exist on Linux or macOS.

This is why compatibility must be checked at the level of actual dependencies. A script that contains only cross-platform language syntax may still import a Windows-only module. Conversely, a script that manages a Windows service is legitimately Windows-specific even though the language itself is cross-platform.

Get-Module -ListAvailable |
    Sort-Object Name, Version |
    Select-Object Name, Version, Path

The command above inventories installed modules; it does not prove they all work in the current engine. The next step for an important dependency is to import it in the target environment, inspect its documentation, and test the exact commands you need.

6. Use a compatibility-first decision process for production automation

Production scripts should not begin with “I use PowerShell 7 everywhere” or “this old script has always used 5.1.” Begin with the environment and dependencies. A repeatable decision process is:

1. List target operating systems. Is the workflow Windows-only, Linux-only, macOS-only, or genuinely cross-platform?
2. List required modules, native tools, and APIs. Record exact dependencies rather than assuming they exist.
3. Identify engine constraints. Does a required module need Windows PowerShell 5.1? Does a language feature require a minimum PowerShell 7 version?
4. Choose a supported baseline. Prefer a currently supported PowerShell 7 release for new cross-platform automation; use Windows PowerShell 5.1 only where the dependency justifies it.
5. Test the matrix you claim to support. “Works on my Windows laptop” is not evidence for Linux CI runners or Server Core.
6. State the contract. Document the minimum PowerShell version, supported platforms, required modules, and exceptions.

For this course, examples target PowerShell 7.6.x LTS unless a lesson explicitly labels a Windows PowerShell or platform-specific case. That gives the examples a supported, modern baseline without pretending every organization upgrades at the same pace.

7. Side-by-side experiment on Windows

If both engines are installed on Windows, you can ask each executable to identify itself. This is read-only. If powershell.exe is unavailable on your platform, skip that half of the experiment.

# Current process
"Current process:"
$PSVersionTable.PSVersion
$PSVersionTable.PSEdition
(Get-Process -Id $PID).Path

# Start a clean PowerShell 7 child process, if pwsh is discoverable.
if (Get-Command pwsh -ErrorAction SilentlyContinue) {
    pwsh -NoProfile -Command '$PSVersionTable | Select-Object PSVersion,PSEdition,OS'
}

# Windows only: inspect Windows PowerShell 5.1 when it exists.
if (Get-Command powershell.exe -ErrorAction SilentlyContinue) {
    powershell.exe -NoProfile -Command '$PSVersionTable | Select-Object PSVersion,PSEdition'
}

-NoProfile starts the child process without loading user or system profile scripts, which reduces environmental surprises. You will study profiles in Chapter 08. For now, use -NoProfile in diagnostic comparisons when you want the engine rather than personal startup customization to be the main variable.

A Windows machine with both products should reveal different edition/version combinations: modern pwsh.exe reports a 7.x version and Core, while powershell.exe reports 5.1 and Desktop.

8. Common compatibility mistakes

Assuming every Windows PowerShell command exists in PowerShell 7. Many commands do, but the correct unit of analysis is the module or API that supplies them. Verify before migrating a production script.

Assuming a command that works in PowerShell 7 on Windows will work on Linux. The engine may be the same while the module, operating-system API, or native dependency is different.

Using PSEdition = Core as an operating-system test. PowerShell 7 on Windows, Linux, and macOS all use the Core edition. Use platform facts such as $IsWindows, $IsLinux, $IsMacOS, or runtime information when platform branching is genuinely necessary.

Hard-coding powershell.exe in new cross-platform automation. That executable selects Windows PowerShell. Use pwsh for the modern engine when launching PowerShell 7 explicitly.

Calling a compatibility layer “native support.” A proxied Windows PowerShell module can be useful, but its execution and serialization boundary is part of the system design and must be tested.

9. Hands-on lab: produce a compatibility fingerprint

This lab creates no files and changes no configuration. It gathers the facts you would attach to a bug report when a script behaves differently between machines.

$compatibilityFingerprint = [pscustomobject]@{
    PowerShellVersion = $PSVersionTable.PSVersion.ToString()
    PSEdition         = $PSVersionTable.PSEdition
    ProcessPath       = (Get-Process -Id $PID).Path
    PSHome            = $PSHOME
    Runtime           = [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription
    OS                = [System.Runtime.InteropServices.RuntimeInformation]::OSDescription
    OSArchitecture    = [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
    ProcessArch       = [System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture
    IsWindows         = $IsWindows
    IsLinux           = $IsLinux
    IsMacOS           = $IsMacOS
}

$compatibilityFingerprint | Format-List

Format-List changes how the object is shown to a human; it does not change the fields used to construct the fingerprint. Later you will learn why formatting commands should normally be kept at the end of a data pipeline.

10. Knowledge check

11. Summary

Windows PowerShell 5.1 and PowerShell 7.x are related but distinct environments. Windows PowerShell uses the Desktop edition and .NET Framework; modern PowerShell uses the Core edition and a current .NET runtime. On Windows they can run side by side. Production compatibility depends on the complete dependency chain—not merely on whether the text of a script “looks like PowerShell.”

12. Further reading

• Microsoft Learn — PowerShell support lifecycle
• Microsoft Learn — about_PowerShell_Editions
• Microsoft Learn — about_Windows_PowerShell_Compatibility
• Microsoft Learn — Installing PowerShell on Windows