Bug 145305 - LibreOffice’s About dialog still reports “Windows 10.0” when running on Windows 11
Summary: LibreOffice’s About dialog still reports “Windows 10.0” when running on Windo...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.2.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: lowest enhancement
Assignee: Not Assigned
URL:
Whiteboard: reviewed:2023
Keywords: difficultyBeginner, easyHack, skillCpp
: 159077 (view as bug list)
Depends on:
Blocks: About-Dialog
  Show dependency treegraph
 
Reported: 2021-10-25 06:27 UTC by Adolfo Jayme Barrientos
Modified: 2024-04-03 18:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adolfo Jayme Barrientos 2021-10-25 06:27:50 UTC
LibreOffice should detect the build number 22000 and, if equal or higher, report a Windows version of “11”.
Comment 1 Mike Kaganski 2021-10-25 08:44:33 UTC
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.
Comment 2 Mike Kaganski 2021-10-25 08:49:06 UTC
FTR: we report Windows 7, Windows 8, Windows 8.1 as 6.1, 6.2, 6.3, corresponding to their correct NT version.
Comment 3 Adolfo Jayme Barrientos 2021-12-12 07:59:21 UTC
Yeah, that’s fair
Comment 4 Aron Budea 2021-12-12 17:07:59 UTC
(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.
Comment 5 Adolfo Jayme Barrientos 2021-12-13 08:20:56 UTC
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 😛
Comment 6 Mike Kaganski 2021-12-13 08:59:08 UTC
(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.
Comment 7 Heiko Tietze 2021-12-13 09:08:35 UTC
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.
Comment 8 Mike Kaganski 2021-12-13 09:31:33 UTC
(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.
Comment 9 Aron Budea 2021-12-13 14:29:42 UTC
(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.
Comment 10 Mike Kaganski 2021-12-13 14:44:08 UTC Comment hidden (obsolete)
Comment 11 Mike Kaganski 2021-12-13 14:51:18 UTC
(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.
Comment 12 Heiko Tietze 2021-12-15 10:57:07 UTC
Code pointer: cui/source/dialogs/about.cxx
Comment 13 Timur 2022-09-06 15:03:34 UTC
No activity, I reset Assignee.
Comment 14 Joel Dowdy 2022-10-04 01:42:07 UTC
I'm going to give this a shot!
Comment 15 Hossein 2022-10-07 11:16:59 UTC
(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.
Comment 16 Joel Dowdy 2022-10-14 03:35:50 UTC
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?
Comment 17 Buovjaga 2022-10-14 06:42:32 UTC
(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
Comment 18 Mike Kaganski 2024-01-09 06:16:59 UTC
*** Bug 159077 has been marked as a duplicate of this bug. ***
Comment 19 Ashwani kumar 2024-04-03 18:08:06 UTC
starting to work on this bug