Make ProcessInfo.operatingSystemVersionString useful on Linux and Windows #2824
Conversation
…ingful values on Linux and Windows.
I have an unfortunate amount of experience with this and can confirm this is the right API to call. :D |
|
@swift-ci please test |
|
@compnerd can you please test this on windows when you get the chance, thanks. |
Sources/Foundation/ProcessInfo.swift
Outdated
| case (6, 3) where osVersionInfo.wProductType == VER_NT_WORKSTATION: versionString += "Windows 8.1" | ||
| case (6, 3): versionString += "Windows Server 2012 R2" // We assume the "10,0" numbers in the table for this are a typo | ||
| case (10, 0) where osVersionInfo.wProductType == VER_NT_WORKSTATION: versionString += "Windows 10" | ||
| case (10, 0): versionString += "Windows Server 2019" // The table gives identical values for 2016 and 2019, so we just assume 2019 here |
There was a problem hiding this comment.
2016 is 10.0.14393 and 10.0.16299, 2019 is 10.0.17763. Versions are also identified by year and month, for example, "Windows Server 2016, version 1709") and IIRC you can get the latter part from the registry key HKLM\Software\Microsoft\Windows\Windows NT\CurrentVersion\ReleaseID for Windows 10 and up.
There was a problem hiding this comment.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion.
> reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion" /v ReleaseID
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
ReleaseID REG_SZ 2004
That is 10.0.19465 though, so, the mapping seems slightly confusing.
|
@gmittert this is pending a change still, correct? |
|
My bad — that was intended to be @gwynne. |
|
If you do and this stalls, please @ me. |
…ays includes at minimum the OS name (if known), and looks for a distro name on Linux. Slightly improve the test case.
|
@spevans @millenomi (Finally) updated this with the changes that were discussed. Please let me know if I missed anything! @compnerd Please test on Windows when you have an opportunity! |
|
@swift-ci please test |
|
Once you're done, make sure that you un-draft this PR so that I can merge it. |
…ation for Android. Return a specific platform name when on any platform `#if os()` knows about that doesn't have a more specialized implementation.
|
@millenomi @spevans Assuming I haven't missed anything, and that CI passes, I think this is ready. |
|
@swift-ci test |
|
@swift-ci please test |
|
@swift-ci test linux |
On Linux,
operatingSystemVersionStringwas previously consulting/proc/version_signature, and giving up immediately if that failed for any reason. This file is a duplicate of the value ofuname -rand has not been present for several major releases of Ubuntu or Debian. The Linux case was rewritten to return the raw value ofutsname.release, which corresponds touname -rand is the value consulted already by the Linux implementation ofoperatingSystemVersion.On Windows,
operatingSystemVersionStringwas effectively completely unimplemented - falling back toCFCopySystemVersionString()on any non-Darwin platform is the same as having no fallback. The only non-deprecated way to retrieve a system version on Windows that I am aware of (at least without getting into the intensely dubious proposition of trying to invoke .NET classes from Swift) is the routine already being used byoperatingSystemVersion:RtlGetVersion(). The boilerplate necessary for correctly loadingntdll.dlland retrieving the symbol from it was refactored out into a private accessor invoked by bothoperatingSystemVersionandoperatingSystemVersionString. The former's behavior remains unchanged. The latter now constructs as reasonable a string as it can, based almost entirely on the contradictory and poorly-proofread reference table provided by Microsoft (the appropriate link is provided in the code).