Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add osversion from hcsshim #279

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Conversation

helsaawy
Copy link
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
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

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.

None yet

3 participants