Repository navigation
Make $PSVersionTable report correct and relevant OS information, underlying .NET version, CPU architecture, OS display version on Windows #19121
Description
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 macOS, you'll see something like:
-
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.22621is 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.
- The friendly OS name is obsolete, because it comes from an API that is frozen for backward-compatibility; e.g.,
-
Update: As Ilya (@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
CLRVersionproperty, which looks to be frozen in time as well).
Proposed technical implementation details (optional)
The exact format will have to be worked out, 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/
- Ubuntu, Debian:
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
Activity
[-]Make `$PSVersionTable` report correct OS information, underlying .NET version, OS display version on Windows[/-][+]Make `$PSVersionTable` report correct and relevant OS information, underlying .NET version, OS display version on Windows[/+]iSazonov commentedon Feb 9, 2023
Related #17059. Conclusion there:
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 .... (Michael Klement (@mklement0) I guess you will be happy to read the story #18854 (comment) )
You could ask .Net team add
DisplayVersion(with "22H2") toSystem.OperatingSystemclass but you should point how get the same "marketing" name for Unix-s (they have it too).mklement0 commentedon Feb 9, 2023
Thanks, Ilya (@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: #19120Frankly, I'm not sure the .NET team would go for such enhancements, as they are likely primarily of interest in a shell context.
iSazonov commentedon Feb 9, 2023
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
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
Andrew74L commentedon Feb 9, 2023
Rather than adding to
$PSVersionTable, might it be better to added new hashes, such as$dNFVersionTableand$OSVersionTable, and/or new cmdlets/functions such asGet-dotNetFrameworkandGet-OperatingSystem?Regarding the OS version of Windows,
winveron 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 UBRHowever...
A dedicated
$OSVersionTablecould clear this up and provide other useful info.iSazonov commentedon Feb 10, 2023
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 commentedon Feb 10, 2023
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.
$OSVersionTabletable would be roughly similar to:Get-WindowsImage -ImagePath $iso\sources\install.wim -Index 6A separate variable would prevent
$PSVersionTabletrying to be too many things to too many people.iSazonov commentedon Feb 10, 2023
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 commentedon Feb 10, 2023
I anticipate this will also be rejected, in favor of a new variable or command.
iSazonov commentedon Feb 10, 2023
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, Michael Klement (@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 commentedon Feb 10, 2023
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 commentedon Feb 17, 2024
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 commentedon Feb 23, 2024
This is very much still a relevant feature request.
microsoft-github-policy-service commentedon Aug 21, 2024
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.
[-]Make `$PSVersionTable` report correct and relevant OS information, underlying .NET version, OS display version on Windows[/-][+]Make `$PSVersionTable` report correct and relevant OS information, underlying .NET version, CPU architecture, OS display version on Windows[/+]