RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version
Roger.Riggs at Oracle.com
Wed Jun 17 13:49:05 UTC 2015
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.
>> The same change is desirable for 8u60.
> Is it time to use the new version helper APIs and move away from
The new helper APIs
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
> 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
In his view, it is more robust than the alternatives.
The example given in MSDN to get the full version number
"To obtain the full version number for the operating system, call
function on one of the system DLLs, such as Kernel32.dll, then call
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.
Similarly, can the case for Windows 3.1 be removed? (its not in theJDK
8 supported matrix
More information about the build-dev