On a Windows machine, `powershell.exe` reports version 5.1 while `pwsh` reports 7.x. Are these the same PowerShell after an upgrade, and what does `$PSVersionTable.PSEdition` tell you about each?

## Two products, not one upgrade Microsoft ships two things whose names both contain "PowerShell". **Windows PowerShell** is a component *of Windows*. Its last version is 5.1, it is installed with the OS at `%SystemRoot%\System32\WindowsPowerShell\v1.0`, and its executable is `powershell.exe`. It is built on .NET Framework 4.x — the Windows-only, in-box runtime. It is serviced for security and reliability, but it does not receive new features. **PowerShell** (6.0, then 7.x — the "Core" edition) is a separate, downloadable product built on modern cross-platform .NET. Its executable is `pwsh` (`pwsh.exe` on Windows), and on Windows it installs under `C:\Program Files\PowerShell\7`. It also runs on Linux and macOS, which is the whole reason the split exists: .NET Framework never left Windows, so a portable PowerShell required a different runtime and therefore a different product. Installing PowerShell 7 does **not** replace or remove Windows PowerShell 5.1. Both remain on the machine, both stay on PATH, and each has its own Start-menu entry. That is deliberate: countless scheduled tasks, installers, CI steps and third-party tools hardcode `powershell.exe`, and silently changing what that name runs would break them. ## What `$PSVersionTable` actually reports `$PSVersionTable` is an automatic variable — a read-only hashtable describing the running engine. Two keys matter here: ```powershell $PSVersionTable.PSVersion # 5.1.x under powershell.exe; 7.x under pwsh $PSVersionTable.PSEdition # 'Desktop' under Windows PowerShell; 'Core' under PowerShell 6/7 ``` `PSEdition` names the runtime family, not the version number. `Desktop` means the engine is on .NET Framework; `Core` means it is on the modern .NET. PowerShell 6 and PowerShell 7 both report `Core`, so `PSEdition` alone does not tell you 6 from 7 — read `PSVersion.Major` for that. The table's contents differ by edition too. Windows PowerShell 5.1 carries `CLRVersion` and `BuildVersion`; PowerShell 6+ drops those and adds `Platform` (`Win32NT` or `Unix`), `OS` (a descriptive OS string) and `GitCommitId`. Testing for a key that only one edition has is itself a workable, if crude, probe. ## The version test that people get wrong The safe branch uses something both editions define: ```powershell if ($PSVersionTable.PSEdition -eq 'Desktop') { ... } # or: $PSVersionTable.PSVersion.Major -lt 6 ``` The unsafe branch uses `$IsWindows`. That automatic variable was introduced in PowerShell 6, so under 5.1 it is simply undefined — it evaluates to `$null`, which is falsy, and your "Windows" branch silently never runs on the most Windows machine you own. Any compatibility check has to be written in a dialect *both* engines speak. ## What else is separate * **Profiles.** PowerShell 7 on Windows uses `$HOME\Documents\PowerShell\` (on Linux/macOS, `~/.config/powershell/`); Windows PowerShell uses `$HOME\Documents\WindowsPowerShell\`. `$PROFILE` resolves per engine, so a prompt customisation added in one shell does not appear in the other. * **Modules.** Each edition has its own user module directory. On Windows, PowerShell 7 does append the Windows PowerShell system module path to `PSModulePath` so many in-box modules can still be imported, but a module you installed for 5.1 into the user scope is not automatically on 7's path. * **Removed features.** PowerShell 6 dropped workflows, PowerShell snap-ins, the WMI cmdlets (`Get-WmiObject` and friends) and the `-ComputerName` parameter on many cmdlets. `Get-Service`, `Get-WinEvent` and the registry provider still exist on Windows but have no meaning on Linux or macOS. * **Remoting endpoints.** Enabling remoting for PowerShell 7 registers its own WinRM session configuration; connecting to the default endpoint still lands you in 5.1. ## Why this shows up in interviews Because the failure mode is invisible. A script tested interactively in `pwsh` is later launched by a scheduled task, a Jenkins step or an MSI custom action that says `powershell.exe -File script.ps1`, and it fails on syntax or cmdlets that exist only in 7 (ternary `?:`, pipeline chain operators `&&`/`||`, `ForEach-Object -Parallel`). The correct instinct is to state the target engine explicitly — invoke `pwsh` by name, put `#requires -Version 7.0` at the top of the script, and treat "which edition runs this" as part of the deployment contract rather than an accident of PATH.