Review request: JDK-8020191 System.getProperty( " os.name " ) returns " Windows NT (unknown) " on Windows 8.1 (v.1)
Chris Hegarty
chris.hegarty at oracle.com
Fri Aug 2 08:36:06 UTC 2013
Looks good Alexey.
-Chris.
On 01/08/2013 17:06, Alexey Utkin wrote:
> I did the Windows 8.1 Preview installation and faced with the same
> problem as described in the article:
> http://social.msdn.microsoft.com/forums/windowsazure/zh-tw/c471de52-611f-435d-ab44-56064e5fd7d5/windows-81-preview-getversionex-reports-629200
>
>
> To fix the problem, java executable modules need to upgrade the manifest.
> That is in new fix version
> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8020191/webrev.01/
>
> The bug
> https://jbs.oracle.com/bugs/browse/JDK-8020191
> contains the attachment with screen shot proof.
>
> Regards,
> -uta
>
> On 7/31/2013 7:14 PM, Kurchi Subhra Hazra wrote:
>> Changes look good to me (once Alan's point is verified).
>>
>> Thanks,
>>
>> - Kurchi
>>
>>
>>
>> On Wed, Jul 31, 2013 at 7:15 AM, Alan Bateman <Alan.Bateman at oracle.com
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>
>> 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/
>> <http://cr.openjdk.java.net/%7Euta/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
>>
>>
>>
>
More information about the core-libs-dev
mailing list