RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version

[Roger Riggs]

Hi Alan,

Would there be any concerns about backporting to JDK 8?

On 6/17/2015 7:32 AM, Alan Bateman wrote:
> On 15/06/2015 22:58, Roger Riggs wrote:
>> Please review code for Windows 10 that sets the System properties for 
>> os.name and os.version
>> from the version of kernel32.dll.  The update uses the same technique 
>> used by Hotspot
>> in src/os/windows/vm/os_windows.cpp.
>>
>> The Windows link of CoreLibraries.gmk includes version.lib/dll.
>>
>> The behavior of GetVersionEx has changed so it reports whatever 
>> version the application
>> asserts it is compatible with instead of the current version of Windows.
>> See: 
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx
>>
>> The same change is desirable for 8u60.
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~rriggs/webrev-win-ver-8066504/
>
> Is it time to use the new version helper APIs and move away from 
> GetVersionEx?
The new helper APIs 
<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx> 
only verify that the OS is at least the version requested.
It does not reveal what version the OS is actually running on.
Adding a manifest attribute just declares the minimum version required
and is reported by GetVersionEx.
In the current case, the code uses GetVersionEx as a fallback in
case the version on kernel32.dll is not available.
That fallback could be removed since kernel32.dll must exist on all 
supported versions.

>
> I don't object to looking at the file version of kernel32.dll but I 
> would think we should be looking to replace it soon (in hotspot too).
The Hotspot version was updated by Christian to deal with the changes to 
GetVersionEx.
In his view, it is more robust than the alternatives.

The example given in MSDN to get the full version number 
<https://msdn.microsoft.com/en-us/library/windows/desktop/ms724429%28v=vs.85%29.aspx>  
:

    "To obtain the full version number for the operating system, call
    the *GetFileVersionInfo*
    <https://msdn.microsoft.com/en-us/library/windows/desktop/ms647003%28v=vs.85%29.aspx>
    function on one of the system DLLs, such as Kernel32.dll, then call
    *VerQueryValue*
    <https://msdn.microsoft.com/en-us/library/windows/desktop/ms647464%28v=vs.85%29.aspx>
    to obtain the \\StringFileInfo\\<lang><codepage>\\ProductVersion
    subblock of the file version information."

An alternative is to use a cascade of IsWindows<xxx>OrGreater() calls to 
narrow in on it.
But if there were a future version of Windows, os.name would report it 
as Windows 10.

>
> Also, is there any update needed in src/windows/resource/java.manifest?
If using the version of kernel32.dll then the manifest version does not 
affect the value of os.name.
But yes, I added the Windows 10 supportedOS uid.
>
> In passing, GetNativeSystemInfo has been in Windows since Windows XP 
> so I don't think we need to use GetModuleHandle to get the address now.
ok.

Similarly, can the case for Windows 3.1 be removed?   (its not in theJDK 
8 supported matrix 
<http://www.oracle.com/technetwork/java/javase/certconfig-2095354.html>)

caseVER_PLATFORM_WIN32s:

Thanks, Roger
>
> -Alan