LibreOffice should detect the build number 22000 and, if equal or higher, report a Windows version of “11”.
Why? We report what Windows tells us. If it's decorated as "Windows 11", but reported as "Windows 10 build 22000", why should we do anything fancy? The LibreOffice version info is not to tell *the user* which *Windows* they use, it's to provide information to bug reports, and using what Windows tells is just fine.
FTR: we report Windows 7, Windows 8, Windows 8.1 as 6.1, 6.2, 6.3, corresponding to their correct NT version.
Yeah, that’s fair
(In reply to Mike Kaganski from comment #1) > Why? We report what Windows tells us. If it's decorated as "Windows 11", but > reported as "Windows 10 build 22000", why should we do anything fancy? The > LibreOffice version info is not to tell *the user* which *Windows* they use, > it's to provide information to bug reports, and using what Windows tells is > just fine. I don't see this as an argument against having an easy-to-interpret version number in the About dialog. Yes, it is accurate information, at the same time it's not obvious, while Windows 11 is, most people who look at the bug reports won't know that Windows 10 build 22000 stands for Windows 11 just by looking at it.
For the record, I also think that nobody (either users or QA members) should be forced to make mental gymnastics every time they need to tell a Windows version 😛
(In reply to Adolfo Jayme from comment #5) No objection if somebody wants to implement that burden (so that the map would need to be further maintained). Mind comment 2. Also mind that, even though a gymnastics might look overly tiresome, there are other considerations to take into account: 1. The OS version must *not* be shortened to become uninformative: so in addition to the fancy name, the real NT version is still needed, because sometimes the build is crucial to detect a compatibility problem (there were precedents with MS-introduced bugs that were then fixed by MS). 2. You can't "merge" the fancy version and NT version, because it would introduce *wrong* NT version, with potential to confuse and also to become ambiguous if MS decides to create an NT version that coincides with such home-made merged version (I mean, a string like "Windows 11 build 22000" is invalid for what is currently reported like "Windows 10.0 build 22000"). 3. The full version should be reported in About dialog, not only in text copied by "Copy to clipboard" button there, because no one must be forced to play "copy me then paste somewhere to check if my system info matches reporter's" gymnastics. 4. There are considerations about too long strings in About dialog. E.g., Heiko even shortened the commit hash.
The function exists to show one string in the UI and to export another. But Windows versioning system never was made for humans, see https://www.gaijin.at/en/infos/windows-version-numbers.
(In reply to Heiko Tietze from comment #7) > The function exists to show one string in the UI and to export another. Please note #3 in comment 6.
(In reply to Mike Kaganski from comment #6) > 2. You can't "merge" the fancy version and NT version, because it would > introduce *wrong* NT version, with potential to confuse and also to become > ambiguous if MS decides to create an NT version that coincides with such > home-made merged version (I mean, a string like "Windows 11 build 22000" is > invalid for what is currently reported like "Windows 10.0 build 22000"). As I understand, the version is something like 10.0.22000 (or even 10.0.22000.348, considering patch levels), and the About dialog already doesn't report version like that, taking it from a random bug report: "Windows 10.0 Build 22000". Perhaps some Win function returns the string like that, I haven't checked, however I'd see no problem with a simple substitution of "10.0" -> "11" in case when the build number is 22000 or higher. There's no need to do sub-version substitutions (eg. 21H2), and there's no need to prepare for an unforeseen future situation that'd have to violate a lot of previous practices to happen.
(In reply to Aron Budea from comment #9) > As I understand, the version is something like 10.0.22000 (or even > 10.0.22000.348, considering patch levels), and the About dialog already > doesn't report version like that, taking it from a random bug report: > "Windows 10.0 Build 22000". Both 10.0 and 22000 are parts of a single NT version. The parts of the version are documented here: https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-osversioninfoexa . The parts are: major version; minor version; build number (, ...). And "10.0.22000" is just one of available ways to display that information. Mixing *another* number - e.g., 11 - with build number from NT version is wrong. If later MS releases NT 11.0.0001, and starts counting builds, names it "Windows 123", and we get a conflict, when Windows 11 means unclear thing - a person who knows true NT versions (always available wherever you search for build numbers) would not know if "Windows 11 build 22000" referred to Windows 11 aka NT 10.0, or to Windows 123 aka NT 11.0?
(In reply to Mike Kaganski from comment #10) > (In reply to Aron Budea from comment #9) > > As I understand, the version is something like 10.0.22000 (or even > > 10.0.22000.348, considering patch levels), and the About dialog already > > doesn't report version like that, taking it from a random bug report: > > "Windows 10.0 Build 22000". > > Both 10.0 and 22000 are parts of a single NT version. The parts of the > version are documented here: > https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt- > osversioninfoexa . The parts are: major version; minor version; build number > (, ...). And "10.0.22000" is just one of available ways to display that > information. Mixing *another* number - e.g., 11 - with build number from NT > version is wrong. If later MS releases NT 11.0.0001, and starts counting > builds, names it "Windows 123", and we get a conflict, when Windows 11 means > unclear thing - a person who knows true NT versions (always available > wherever you search for build numbers) would not know if "Windows 11 build > 22000" referred to Windows 11 aka NT 10.0, or to Windows 123 aka NT 11.0? So I don't see a problem reporting it as "Windows 11 version 10.0.22000". Just make sure that NT version is displayed in unambiguous, unmodified way.
Code pointer: cui/source/dialogs/about.cxx
No activity, I reset Assignee.
I'm going to give this a shot!
(In reply to Joel Dowdy from comment #14) > I'm going to give this a shot! In addition to changing the bug status to ASSIGNED, please also assign the bug to yourself. Now, I've done this for you.
Thank you for the heads up! I'm still working on this. I wrote the code some time ago but have to build it on Windows to test it out which I can't do until this weekend. As far as things go, what level of testing is expected? Just running the tests themselves, confirming that it isn't broken or something else?
(In reply to Joel Dowdy from comment #16) > Thank you for the heads up! I'm still working on this. I wrote the code some > time ago but have to build it on Windows to test it out which I can't do > until this weekend. As far as things go, what level of testing is expected? > Just running the tests themselves, confirming that it isn't broken or > something else? Test that it works as expected and also run make check
*** Bug 159077 has been marked as a duplicate of this bug. ***
starting to work on this bug
Where should I send the patch, to Gerrit and paste the link here?
To Gerrit please
(In reply to Jakub Kościelak from comment #20) > Where should I send the patch, to Gerrit and paste the link here? Note that Achintya already has a patch for this (yes, this report should have been assigned properly): https://gerrit.libreoffice.org/c/core/+/160997 Maybe you can review the patch?
I got acquainted. I was thinking about such a proxy between AboutBox and calls to Application::GetHWOSConfInfo(bSelection, bLocalize); and string filtering. I made a PoC in about.cxx because I didn't know if WinSalInstance::getOSVersion() is not used for anything else yet or it will be and by fixing one thing it will break the other ;-) But we only care about AboutBox. Certainly, looking at the Achintya code, the first thing that catches our eye is that we do not need to check the buildnumber for 6.1, 6.2 and 6.3, because it is clear that these are Windows 7, 8 and 8.1, respectively. We should use the knowledge provided by Heiko Tietze in comment no. 7. Only 10.0 is a problem, because up to build 2200 it is Win 10 and then Win 11.
Achintya is not responding to pings from gerrit. I posted my patch based on his and Joel Dowdy's earlier work. https://gerrit.libreoffice.org/c/core/+/166779
kubak committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2db558b5a1c01b3a08f60962c0115a34aa09bf90 tdf#145305 Improve Windows version string. It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thank you Mike Kaganski for your mentorship.