Bug 100233 - Wrong Windows version reported in the About window in Windows 10
Summary: Wrong Windows version reported in the About window in Windows 10
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: All Windows (All)
: medium minor
Assignee: Mike Kaganski
URL:
Whiteboard:
Keywords: implementationError
: 104938 (view as bug list)
Depends on:
Blocks: About-Dialog
  Show dependency treegraph
 
Reported: 2016-06-06 10:09 UTC by Marco A.G.Pinto
Modified: 2017-10-05 18:24 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of About window (20.45 KB, image/png)
2016-06-06 10:09 UTC, Marco A.G.Pinto
Details
screenshot - Thunderbird shows Windows 10 in the debug window (51.86 KB, image/png)
2017-06-25 23:12 UTC, Marco A.G.Pinto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marco A.G.Pinto 2016-06-06 10:09:39 UTC
Created attachment 125508 [details]
Screenshot of About window

I have Windows 10.0.10586.

When I click on the About option in LO it says "Windows 6.19".

Microsoft changed the Windows revising to use 10.0, so this is a bug.

Thanks!

Kind regards,
Comment 1 Aron Budea 2016-06-06 10:26:10 UTC
So this came up in the channel a few days ago. Eike found the following link:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832.aspx

According to this the version should be 6.2, since the application is not manifested for Windows 8.1/10.
Comment 2 Adolfo Jayme 2016-06-09 20:50:23 UTC
Given the previous explanation, shouldn’t this be closed as NOTABUG?
Comment 3 Aron Budea 2016-06-09 22:47:50 UTC
It wouldn't be a bug if the dialog reported 6.2, but 6.19 is not a valid version number.
Comment 4 Marco A.G.Pinto 2016-06-10 09:29:22 UTC
To have in consideration:

Date: Wed, 8 Jun 2016 19:53:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0

This is the "View Source" for Thunderbird 45.

It says "Windows NT 10.0" in the message code.
Comment 5 Aron Budea 2016-06-10 13:13:23 UTC
Ultimately this could be relevant if we want the real version to be returned, and displayed there: https://bugzilla.mozilla.org/show_bug.cgi?id=1076926

But first, 6.19 is just invalid.
Comment 6 V Stuart Foote 2016-12-27 17:16:13 UTC
*** Bug 104938 has been marked as a duplicate of this bug. ***
Comment 7 V Stuart Foote 2016-12-27 17:18:39 UTC
From dupe 104938...

something more than https://cgit.freedesktop.org/libreoffice/core/commit/?id=4500afcc1be7774b3c35ab69a20e36165ca5445a needed for WinSalInstance [1] at this point for 8, 8.1 and 10 builds of Windows?

In https://msdn.microsoft.com/en-us/library/ms724834(VS.85).aspx there is the note:

For applications that have been manifested for Windows 8.1 or Windows 10. Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2). To manifest your applications for Windows 8.1 or Windows 10, refer to Targeting your application for Windows.

Guess since we do not manifest for Windows 8.1 or 10 we get 6.2--incorrectly being displayed as 6.19

Markus and Tomaž have been able to get good OS version resolution for the driver details [2]

=-ref-=
[1] http://opengrok.libreoffice.org/xref/core/vcl/win/app/salinst.cxx#431

[2] http://opengrok.libreoffice.org/xref/core/vcl/opengl/win/WinDeviceInfo.cxx#146
Comment 8 Yousuf Philips (jay) (retired) 2017-06-24 21:13:21 UTC
(In reply to Aron Budea from comment #3)
> It wouldn't be a bug if the dialog reported 6.2, but 6.19 is not a valid
> version number.

If you look at the numbers in the the link from comment 1, they only have single digit decimal places, so all we need to do is round the number up to a single decimal place and its solved.

Windows 8.1 is supposed to show 6.3, but i have it as 6.29. This should be quite simple to fix.
Comment 9 Aron Budea 2017-06-25 04:56:25 UTC
(In reply to Yousuf Philips (jay) from comment #8)
> If you look at the numbers in the the link from comment 1, they only have
> single digit decimal places, so all we need to do is round the number up to
> a single decimal place and its solved.

I'd be happier to have the underlying issue found and eliminated. Those numbers should be single digit decimals in the first place, without any kind of rounding.
Comment 10 Yousuf Philips (jay) (retired) 2017-06-25 22:44:15 UTC
(In reply to Aron Budea from comment #9)
> I'd be happier to have the underlying issue found and eliminated.

Yes solving the issue for Windows 10 definitely is the issue that should be focused on here.

> Those
> numbers should be single digit decimals in the first place, without any kind
> of rounding.

Without rounding, you cant change 6.3 from 6.29.
Comment 11 Aron Budea 2017-06-25 23:11:40 UTC
(In reply to Yousuf Philips (jay) from comment #10)

> Without rounding, you cant change 6.3 from 6.29.

Yes, but how does it become 6.29 in the first place?
Comment 12 Marco A.G.Pinto 2017-06-25 23:12:09 UTC
Created attachment 134282 [details]
screenshot - Thunderbird shows Windows 10 in the debug window

Again, I believe Microsoft changed the version number.

Are you sure you can't get "10.0" from the properties code?
Comment 13 V Stuart Foote 2017-06-26 03:01:22 UTC
No, we seem to have an implementation problem here with the Windows version idents [1]. Microsoft deprecated the GetVersionEx() call in current SDKs, but we've not fully adjusted.

Michael S. tests the generic Windows > Vista with [2][3], and we make the OS Version query here:
http://opengrok.libreoffice.org/xref/core/vcl/source/app/svapp.cxx#1173
http://opengrok.libreoffice.org/xref/core/vcl/win/app/salinst.cxx#1012

Unfortunately, IIUC since our builds remain targeted at Windows XP and do not manifest for later releases, I think the version returns major 6 minor 2.

Seems that to identify Windows details we probably need to pull major and minor version ID from OSVERSIONINFO [4], similar to what is being done for OpenGL support. 
http://opengrok.libreoffice.org/xref/core/vcl/opengl/win/WinDeviceInfo.cxx#185

For the Help -> About dialog if we want to provide more than major minor and want to include the build version--we could pull from the OSVERSIONINFOEX struct [5] rather than OSVERSIONINFO.

Also, there are some legacy calls that probably need to be cleaned up:
http://opengrok.libreoffice.org/xref/core/vcl/win/app/salinst.cxx?a=true#415 for example where we've hard coded only through Windows 7--with no handling of 8, 8.1 or 10.

=-refs-=
[1] https://msdn.microsoft.com/en-us/library/ms724832(v=vs.85).aspx

[2] https://msdn.microsoft.com/en-us/library/ms724451(v=vs.85).aspx
[3] https://gerrit.libreoffice.org/#/c/14020/

[4] https://msdn.microsoft.com/en-us/library/ms724834(VS.85).aspx

[5] https://msdn.microsoft.com/en-us/library/ms724833(v=vs.85).aspx
Comment 14 Marco A.G.Pinto 2017-10-04 10:39:15 UTC
Fixed in LO 6 alpha 0.
Comment 15 Marco A.G.Pinto 2017-10-04 10:49:08 UTC
Version: 6.0.0.0.alpha0+ (x64)
Build ID: b087e451527f2e497ccab83b63b4f10099bfb8b8
CPU threads: 2; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-04_00:55:56
Locale: en-GB (en_GB); Calc: group
Comment 16 Yousuf Philips (jay) (retired) 2017-10-05 02:45:06 UTC
Can we find out which patch fixed this as it would be good to fix it for other Windows versions.
Comment 17 V Stuart Foote 2017-10-05 04:10:52 UTC
(In reply to Yousuf Philips (jay) from comment #16)
> Can we find out which patch fixed this as it would be good to fix it for
> other Windows versions.

Pretty sure it was Mike K's work in https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=0dd2e602e5c1b46e82abc6051677aeaab1d265b8 and with its refactoring already should detect all our support Windows versions.
Comment 18 Mike Kaganski 2017-10-05 04:28:25 UTC
Yes, that commit guarantees that we will continue to get proper Windows versions for display, even if program will run on a future Windows version. Another commit - https://cgit.freedesktop.org/libreoffice/core/commit/?id=736a4e659cff2ef5f900301d7d288494f9b98178 - adds compatibility sections to our binaries' manifests claiming support of Win7 through Win10, so this also "fixes" GetVersion* API results, but that would fail on next Windows version, and is only meant to prevent us running in compatibility (reduced) mode.

To clarify: Windows versions are not a float that can be rounded: they are a series of integers, which are simply displayed using dot between them, so no "rounding" is possible here. The "19" came from Microsoft for unclear reasons: trying to use its recommended API (IsWindowsVersionOrGreater), we used to try to find out the highest supported version and subversion numbers by starting at a high value (30), decrementing by one, and asking that API if that version and subversion are supported; and it returned true for subversion 19 on version 6 for Win10. See WinSalInstance::getOSVersion() changes in https://cgit.freedesktop.org/libreoffice/core/commit/?id=0dd2e602e5c1b46e82abc6051677aeaab1d265b8 for old implementation details.
Comment 19 Yousuf Philips (jay) (retired) 2017-10-05 11:59:51 UTC
(In reply to V Stuart Foote from comment #17)
> Pretty sure it was Mike K's work in
> https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;
> h=0dd2e602e5c1b46e82abc6051677aeaab1d265b8 and with its refactoring already
> should detect all our support Windows versions.

Didnt see windows vista in the list, which is still supported. @Mike: will vista detect okay?
Comment 20 Mike Kaganski 2017-10-05 12:00:39 UTC
(In reply to Yousuf Philips (jay) from comment #19)
> Didnt see windows vista in the list, which is still supported. @Mike: will
> vista detect okay?

Is it? ;-)
Comment 21 V Stuart Foote 2017-10-05 14:17:38 UTC
(In reply to Mike Kaganski from comment #20)
> (In reply to Yousuf Philips (jay) from comment #19)
> > Didnt see windows vista in the list, which is still supported. @Mike: will
> > vista detect okay?
> 
> Is it? ;-)

XP and Vista dropped effective 6.0.0 (by ESC action http://nabble.documentfoundation.org/ESC-minutes-2017-05-25-td4215185.html because of ICU 59 dependencies, but they are gone).

Not sure if Mike's work does detect a Vista instance, will check when I can fire up a VM and load an instance of current master.
Comment 22 V Stuart Foote 2017-10-05 16:35:05 UTC
So I could not get current master (633f405701fc5cadfa73e950f7a8c122ad01c149) to run on Windows Vista sp2. 

Updated the MS VS2015 c++ runtime to vcruntime140.dll, but get the ICU 59.1 related entry point call of "ResolveLocaleName could not not be located in the dynamic link library  KERNEL32.dll" on launch of 20171005 TB 42 x86 build.

Not sure if that is an issue with the TB, or if the ICU 59.1 is now fully active preventing any Windows XP or Vista use for master/6.0.0, see bug 108043

The TDF x86 5.4.2.2 Windows install, from pre-release, opens in the VM without issue and reports OS: Windows 6.0
Comment 23 Michael Stahl (allotropia) 2017-10-05 18:24:45 UTC
that is expected, master/6.0 require Windows 7 or later