Make `$PSVersionTable` report correct and relevant OS information, underlying .NET version, OS display version on Windows

[mklement0]

Summary of the new feature / enhancement

While $PSVersionTable.PSVersion is frequently used programmatically, the remaining properties are typically relevant to the human observer, and, notably, $PSVersionTable output is requested when submitting bug reports in this repo.

That output is currently suboptimal in several respects:

• On Unix-like platforms, it doesn't provide a friendly OS name.

  • On macOS, you'll see something like:
    • Darwin 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000,
    • which neither tells you that this is a Ventura release, nor its version (13.1)
  • On WSL, it isn't even obvious that you're running inside WSL; e.g.
  • Linux 4.4.0-22621-Microsoft #1105-Microsoft Fri Jan 01 08:00:00 PST 2016
  • I presume that other distros also do not report their name (such as Ubuntu).

• On Windows:

  • The friendly OS name is obsolete, because it comes from an API that is frozen for backward-compatibility; e.g., Microsoft Windows 10.0.22621 is still reported on Windows 11(!)
  • It is missing the so-called display version, e.g. 22H2, which is an important and easy way to identify the specific version.

• Update: As @iSazonov points out, the machine architecture (x64, ARM32, ...) is important too and, on Windows, where 32-bit editions are still supported, whether the process is 32-bit.

• Sometimes it is important to know what specific .NET version the given PowerShell version is built on - this information is missing (Windows PowerShell has a CLRVersion property, which looks to be frozen in time as well too).

Proposed technical implementation details (optional)

The exact format will have to be worked, as well as whether to add the information to existing properties or whether to introduce new ones, but here are pointers as to where the information can be obtained (at least as an initial pointer - using system APIs is obviously preferable to calling CLIs):

• Framework version:

  • [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription

• Windows

  • Get-CimInstance Win32_OperatingSystem | Select-Object Caption, @{ n='DisplayVersion'; e={ Get-ItemPropertyValue 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' DisplayVersion } }

• macOS:

  • sw_vers

• Linux:

  • Ubuntu, Debian:
  • lsb_release -a
  • Others? Potential pointers here: https://www.cyberciti.biz/faq/find-linux-distribution-name-version-number/

uname -m can provide machine architecture information on all Unix-like platforms.

Desired sample output on Windows (doesn't try to maintain backward compatibility):

# WISHFUL THINKING
PS> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      7.4.0-preview.1
PSEdition                      Core
GitCommitId                    7.4.0-preview.1
FrameworkVersion               .NET 7.0.1                                # <- NEW
OS                             Microsoft Windows 11 Pro 22H2  (x64/32)   # <- CHANGE
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

Related #17059. Conclusion there:

The WG discussed this and we're concerned that the $PSVersionTable could grow to be unwieldy (and we would like to keep PSVersionTable from trying to have everything). However, we do see the need for diagnostic tools which collect this information (and perhaps more). We would be happy to entertain proposals for additional tools to provide that.

The main fear is that there will be constant requests to add something else. Although in fact for a long time the list of desired additions is stable. Our issue template requires $PSVersionTable and this table does not contain all the information we need. For example, the .Net version is already annoying. Lately Arm64/32 has been more and more widely used. Many issues with problems both in the dotnet repository and here, but this information is not in the table. Absence of OS Architecture and Process architecture is annoying too.

---

As for OS version, we should use .Net API for being reliable and predictable. Its implementation is a tricky. On Unix due to absence of a standard. On Windows too .... (@mklement0 I guess you will be happy to read the story https://github.com/PowerShell/PowerShell/issues/18854#issuecomment-1374563253 ) You could ask .Net team add DisplayVersion (with "22H2") to System.OperatingSystem class but you should point how get the same "marketing" name for Unix-s (they have it too).

[mklement0]

Thanks, @iSazonov - I wasn't aware of the earlier issue.

I've updated the initial post to also suggest reporting the machine architecture and the bit-ness of PowerShell (the two can only differ on Windows, right)?

As for DisplayVersion: see also: #19120

Frankly, I'm not sure the .NET team would go for such enhancements, as they are likely primarily of interest in a shell context.

[iSazonov]

(the two can only differ on Windows, right)?

It seems Arm64 can emulate x32/64 and it is great tricky to detect :-) Although it's rather useless. Also I see Arm64 can run Arm32 binaries https://stackoverflow.com/questions/22460589/armv8-running-legacy-32-bit-applications-on-64-bit-os

Frankly, I'm not sure the .NET team would go for such enhancements, as they are likely primarily of interest in a shell context.

I guess this depends primarily on complicity. If there are simple ways to get Windows/iOS/Linux-s distributive names they can approve. They already have this in test code https://github.com/dotnet/runtime/blob/d2dfabf45d98782a9dc847fba32442e7aaa5b67b/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs#L191

Stack Overflow

ARMv8 - Running legacy 32 bit Applications on 64 bit OS

Going thru the ARMv8 manual, I have the following questions to help understand the big picture. Can legacy 32 bit app. (ARMv7 or earlier) run as is on the ARMv8 OS? If the legacy applications need...

GitHub

runtime/PlatformDetection.Unix.cs at d2dfabf45d98782a9dc847fba32442e7aaa5b67b · dotnet/runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps. - runtime/PlatformDetection.Unix.cs at d2dfabf45d98782a9dc847fba32442e7aaa5b67b · dotnet/runtime

[Andrew74L]

Rather than adding to $PSVersionTable, might it be better to added new hashes, such as $dNFVersionTable and $OSVersionTable, and/or new cmdlets/functions such as Get-dotNetFramework and Get-OperatingSystem?

Regarding the OS version of Windows, winver on Win11 currently displays:

Microsoft Windows Version 22H2 (OS Build 22621.1105)

Presumably 1105 is the revision number, which comes from: Get-ItemPropertyValue 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name UBR However...

PS > [System.Environment]::OSVersion.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      22621  0

A dedicated $OSVersionTable could clear this up and provide other useful info.

[iSazonov]

Rather than adding to $PSVersionTable, might it be better to added new hashes

It would be hard to find these new variables while the PSVersionTable is widely known. As usual we can say that any user can add them to their profile if needed.

[Andrew74L]

It would be hard to find these new variables while the PSVersionTable is widely known.

As soon as OS and dotnet version info goes into PSVersionTable, people are going to start asking for additions. For Windows: What is the SKU? Is this 10, 11, or later? What is the display version? What is the name? What is the installation type (client/server)?

The problem with the following... Microsoft Windows 11 Pro 22H2 (x64/32) ... is that it concatenates Manufacturer, OSName, DisplayVersion, and OSArchitecture.

$OSVersionTable table would be roughly similar to: Get-WindowsImage -ImagePath $iso\sources\install.wim -Index 6 A separate variable would prevent $PSVersionTable trying to be too many things to too many people.

[iSazonov]

It would be hard to find these new variables while the PSVersionTable is widely known.

As soon as OS and dotnet version info goes into PSVersionTable, people are going to start asking for additions.

There can be an infinite number of such requests. This is exactly the reason why WG rejected the PSVersionTable extension and requested a proposal for some kind of diagnostic tool. This is a completely different story.

What we are saying here is that the PSVersionTable should contain general useful information, which is exactly what we need to start troubleshooting.

[Andrew74L]

What we are saying here is that the PSVersionTable should contain general useful information, which is exactly what we need to start troubleshooting.

I anticipate this will also be rejected, in favor of a new variable or command.

[iSazonov]

What we are saying here is that the PSVersionTable should contain general useful information, which is exactly what we need to start troubleshooting.

I anticipate this will also be rejected, in favor of a new variable or command.

It is another story. You say about scenario being under WG team request for "diagnostic tool". If it's created, that's great. But right now it is something ephemeral. As long as there are no concrete specifications it is useless to talk about creating any tools, new variables or commands. WG just says create specifications and they will see if it's useful. Most likely the answer will be that it should be a community project 😺

In contrast, here we are talking about specific scenarios for which the PSVersionTable extension is long overdue. For example, @mklement0 talks about programmatically using it. I wouldn't be surprised at the usefulness of this in Pester tests. What I'm saying is that the user has to get the PSVersionTable to create an Issue in this repository. It used to be if it was Windows or MacOS it was exhaustive. Now it's not anymore, for example, Windows can run on Arm. Also, there are pwsh distributions that use shared .Net, i.e. pwsh 7 could potentially run on a system with only .Net 8 installed. This information is not currently in the PSVersionTable and it is not obvious how to get it, much less WHAT we need to get it for.

[Andrew74L]

What I'm saying is that the user has to get the PSVersionTable to create an Issue in this repository.

If that is it's major purpose then sure, it should probably be extended. Otherwise I would hope to see something more general purpose created.

[microsoft-github-policy-service[bot]]

This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.

Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.

[BobBuildingCode]

This is very much still a relevant feature request.