SystemInfo: Add support for Windows Server 2025 (UI like Windows 11, Windows 11 core)

[VISTALL]

For now Windows Server 2025 works like Windows 10 (no round corners, etc)

OpenJDK bug

https://bugs.openjdk.org/browse/JDK-8340387 https://github.com/openjdk/jdk/commit/34cddfbedd20d5804cab8044fbc402564e98eb9c

  os.arch = amd64
  os.name = Windows Server 2022
  os.version = 10.0

[VISTALL]

It's problem of GetVersionEx which return version in compability mode

https://github.com/JFormDesigner/FlatLaf/blob/main/flatlaf-natives/flatlaf-natives-windows/src/main/cpp/WinWrapper.cpp#L39

Guys from OpenJDK get build number from file kernel32.dll

https://github.com/openjdk/jdk/blob/34cddfbedd20d5804cab8044fbc402564e98eb9c/src/hotspot/os/windows/os_windows.cpp#L4106

[DevCharly]

Thanks for the info.

I wonder why is your app in compatibility mode?

[VISTALL]

For example if jdk don't known about new OS - and getVersionEx will return last combability version. Without manifest will be windows 8. Based on manifest (without changing settings)

[VISTALL]

https://stackoverflow.com/questions/58294262/getversionex-windows-10-detected-as-windows-8

You can search it like GetVersionEx return wrong version - it's a pain function :(

[DevCharly]

Well, the actual problem is that your app consulo64.exe does not specify compatibility for Windows 10+ in its Windows manifest.

Manifest of consulo64.exe 3659 is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

On the other hand , the manifest of javaw.exe contains <compatibility> tag (and also dpiAwareness): https://github.com/openjdk/jdk/blob/master/src/java.base/windows/native/launcher/java.manifest

If I patch consulo's manifest into a copy of javaw.exe, then GetVersionEx indeed returns 6.2.9200 (instead of 10.0.26100):

mt.exe "-inputresource:consulo64.exe;#1" -out:consulo64-manifest.txt
mt.exe "-outputresource:javawCopy.exe;#1" -manifest consulo64-manifest.txt

I would recommend to specify compatibility (and dpi awareness!) in your app. There may be other Win32 API that behaves differently if Windows 10+ compatibility is not specified.

Anyway, here is a test version of the FlatLaf DLLs that use RtlGetVersion, which returns correct Windows version even if manifest misses compatibility information: flatlaf-windows-RtlGetVersion.zip

This DLLs output version to console. E.g.:

GetVersionEx:      6.2.9200
RtlGetVersion:     10.0.26100
KUSER_SHARED_DATA: 10.0.26100

or

GetVersionEx:      10.0.26100
RtlGetVersion:     10.0.26100
KUSER_SHARED_DATA: 10.0.26100

If these DLLs work for you, I'll integrate it into official DLLs.

BTW interesting article regarding Windows version detection: https://www.codeproject.com/Articles/5336372/Windows-Version-Detection

[VISTALL]

Hello. Thanks. I will test it. You are right about manifest - but not all apps contains it (support for last OSes). Need correct way for getting real version - because even JVM use real version of OS, not combability version

[DevCharly]

8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a in manifest makes it compatible with Windows 10, Windows 11, Windows Server 2016, Windows Server 2019 and Windows Server 2022 (source).

[VISTALL]

Works as expected. No need override os.name :)

[DevCharly]

Fixed in latest 3.5.3-SNAPSHOT: https://github.com/JFormDesigner/FlatLaf#snapshots