Skip to content

Add osversion from hcsshim#279

Closed
helsaawy wants to merge 1 commit intomicrosoft:mainfrom
helsaawy:os-version
Closed

Add osversion from hcsshim#279
helsaawy wants to merge 1 commit intomicrosoft:mainfrom
helsaawy:os-version

Conversation

@helsaawy
Copy link
Copy Markdown
Contributor

@helsaawy helsaawy commented Mar 8, 2023

Move osversion package to winio from hcsshim, so it can be imported separately.
Additionally, dedicated types can be created for version components, and packaged version number can be removed from Version struct without breaking APIs that currently rely on "hcssim/osversion".

RtlGetVersion returns the windows OS version regardless of manifest, so that is preferred over GetVersion.

[RtlGetVersion](https://learn.microsoft.com/en-us/windows/win32/devnotes/rtlgetversion)
returns the windows OS version regardless of manifest, so that is
preferred over
[GetVersion](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversion).

Signed-off-by: Hamza El-Saawy <hamzaelsaawy@microsoft.com>
@thaJeztah
Copy link
Copy Markdown
Contributor

Hm.. moving this seems a bit scary, as there's quite some code consuming the old location. Moving it to go-winio reduces "some" of the issues, but effectively is just moving the goalposts a bit (with go-winio having less dependencies / somewhat more isolated).

Having this as a more isolated package could make sense, but if this were to move, would it make sense to either make this its own repository, or otherwise its own module, versioned separate from hcsshim and go-winio (which could mean it to stay in the old location, but as a separate module, and tagged separately.

If the code is to be moved, at least it would be good to preserve history (taking an approach similar as the steps done in moby/sys#54)

also /cc @tianon (ISTR you were using it in various other places as well)

@tianon
Copy link
Copy Markdown

tianon commented May 22, 2023

I use it a lot as the best reference I can find for build numbers and how they correspond to the "public" numbers like 1809 / "LTSC 2019" (I think https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/base-image-lifecycle is a more canonical location for that, but this Go file is way easier to read for this slice of information).

I've considered using it programmatically several times, but for all my use cases, the fact that it's just a fixed list of constants has been a blocker since it requires manually updating my code any time the list of constants changes (the use case I reconsider frequently is something like converting a particular os.version value into a more human-friendly string like "Windows Server 2019" or something).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants