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
