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,
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.
Given the previous explanation, shouldn’t this be closed as NOTABUG?
It wouldn't be a bug if the dialog reported 6.2, but 6.19 is not a valid version number.
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.
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.
*** Bug 104938 has been marked as a duplicate of this bug. ***
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
(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.
(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.
(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.
(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?
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?
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
Fixed in LO 6 alpha 0.
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
Can we find out which patch fixed this as it would be good to fix it for other Windows versions.
(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.
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.
(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?
(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? ;-)
(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.
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
that is expected, master/6.0 require Windows 7 or later