The changes in the webrev look okay to me but the reference to the "app
compatibility shim" in the MS article is a bit confusing and not clear
to me (with checking into it more) whether this might consider java.exe
as something that isn't targeted to Windows 8.1. So can you verify that
you have checked it on the latest 8.1 preview?
As regards the helper library then this could be useful in the future
(for now then it probably complicates things because the JDK still has
to run on older versions of Windows).
-Alan.
On 31/07/2013 05:53, Alexey Utkin wrote:
Bug description:
https://jbs.oracle.com/bugs/browse/JDK-8020191
http://bugs.sun.com/view_bug.do?bug_id=8020191
Here is the suggested fix:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.00/
Summary:
We need to be consistent with the rest of OS, so I extend the case for
6.3 internal version number by values "Windows 8.1" for workstation
OS, and "Windows Server 2012 R2" for server OS.
(http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx)
But we get a chance to have a wrong OS name due to MS compatibility
problems.
Here is the problem description:
http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200
and MS respond:
http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074.aspx
Quotations:
"In Windows 8.1 Preview, we have introduced a new API, Versionhelpers
API, that deprecates the need for using GetVersion(Ex) APIs. This
addresses difficulties in interpreting the numerical value returned by
the GetVersion(Ex) APIs."
"The internal version number for Windows 8.1 Preview and Windows
Server 2012 R2 Preview is 6.3. Only apps that are targeting Windows
8.1 will receive a return value of 6.3. Those apps that are not
targeted for Windows 8.1 will receive a return value of 6.2 unless
previously shimmed as discussed below."
Regards,
-uta
