[Win32] Explicitly set minimum supported OS version to 14393

[HeikoKlare]

Currently, there is no explicit minimum version required for executing SWT applications. However, some versions are implicitly not supported anymore as library methods are linked that are not present in older OS versions. In addition, we still have some methods dynamically linked and their execution guarded by a version constraint for version that are out of support. In particular, this holds for every Windows version older than build 14393, which is the 1607 update for Windows 10 and the release of Windows Server 2016, the latter being the latest still supported server version of Windows.

This change cleans up Windows version support:

• It adds an explicit version check at initialization to avoid that applications fail to start with incomprehensible linkage errors but a proper error message
• It removes version guards for methods that are present since Windows build 14393 (update 1607) or older
• It removes unnecessary dynamic linking for methods that are present in Windows build 14393 (update 1607) or older

Fixes eclipse-platform/eclipse.platform.ui#2852

Probably fixes #2011

[github-actions]

Test Results

   545 files  ±0     545 suites  ±0   32m 46s ⏱️ + 4m 54s
 4 373 tests ±0   4 361 ✅ ±0   12 💤 ±0  0 ❌ ±0 
16 634 runs  ±0  16 530 ✅ ±0  104 💤 ±0  0 ❌ ±0 

Results for commit 78abbed. ± Comparison against base commit f468eca.

♻️ This comment has been updated with latest results.

[sratz]

I think it makes sense to have an explicit check in SWT for the minimum version.

However, I am not sure about the C code cleanups.

For example in #1568 some functions were marked as dynamic, because contrary to the documentation those functions are not available in every Windows version sind 1607.

Are we sure that we are not breaking things again here?

[HeikoKlare]

some functions were marked as dynamic, because contrary to the documentation those functions are not available in every Windows version sind 1607.

I am not sure whether that's really the case, but we should definitely check that. My impression is that the issue was with OpenThemeDataForDpi, as that one is documented not be provided since 1607 (which has the same build version as Windows Server 2016) but since 1703, which I would expect to be the reason why it produced problems also with Windows Server 2016. That method I did not touch in this PR. All the other methods should be available with Windows Server 2016 / Windows 10 1607 and newer. Note that this PR will break compatibility with older Windows versions (like Windows 8.1), so "issues" like dbeaver/dbeaver#34034 will of course occur again. But instead this will fix compatibility with up-to-date JREs, as the dynamic loading produces a problem with the Semeru (eclipse-platform/eclipse.platform.ui#2852).

Note that this is currently only a proposal that we should agree on, but I am generally in favor of dropping support for OS versions that are out-of-support instead of searching for other solutions for issues regarding up-to-date JREs.

Only issue I see is that there is some extended support for Windows Server 2012 (also see #1252 (comment)) which will not be supported by SWT anymore. But just because the OS receives security updates does not mean that it needs to receive latest Eclipse/SWT updates. We would just need to be aware that some people will some complaning again.

[HeikoKlare]

I just found a comment stating that the actual issue back then really was with OpenThemeDataForDpi: #1500 (comment)

[HeikoKlare]

I just found that the proposed version check will not work: the primary SWT DLL is loaded even before the version check is executed (the DLL is required to extract the OS version) but that load operation will already fail when the Windows version is too old. Thus, even with this check the same kind of incomprehensive linkage error we have seen previously when breaking compatibility with older OS versions will occur.

I see two possibilities to extract the Windows build version without loading the primary SWT DLL:

• Generate a separate DLL for only the Windows API method to retrieve the Windows build version that can safely be loaded first for doing the version check
• Execute some version-retrieving command like ver via cmd.exe and extract the according information out of the result

The first option seems cleaner to me. I would be willing to invest some effort to have a proper minimum version check for Windows in SWT, as we will eventually break compatibility with older Windows versions (like with the changes proposed here) and to avoid issues and discussions being started because of unclear linkage errors. Thus having a proper error message stating that the Windows build is too old for the Eclipse/SWT version seem valuable to me.

@akurtakov what do you think about ...?

• having an explicit version check in SWT for Windows and actively aborting application startup if the Windows build is too old?
• excluding every Windows version older than the 1607 build (which is the first Windows 10 version and the Windows Server 2016 release)? Note that this will make SWT not work with Windows Server 2012 anymore, for which there is an extended version support until end of 2026. If we still wanted to support that version, it's unclear how we may fix UI spacing incorrect when using IBM's Semeru JDK eclipse.platform.ui#2852 and I consider proper support of up-to-date JRE is more important than supporting a pretty old Windows version that goes out of support next year anyway.

[akurtakov]

If you want to abort as early as possible

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/os_custom.c

Line 25 in 111b874

(void)lpvReserved;

should be the place to do this check.
As per https://eclipse.dev/eclipse/development/plans/eclipse_project_plan_4_36.xml#target_environments only Win10/11 are supported target environments. It's better to not start in clear way rather than hard crash with no clear info IMO.

[akurtakov]

As per the same document there is no promise about J9 so there is no promise that this will work nor that it would be looked at by anyone aka "help welcome" type of issue. Again, I believe it's better to explicitly not start than to crash.

[HeikoKlare]

Thank you for the feedback and the pointer! I'll see where I can add such a check. The DllMain seems to be a good place, at least in case that line of code is even reached (as I am not sure when the resolution of static links is done).

[HeikoKlare]

If you want to abort as early as possible

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/os_custom.c

Line 25 in 111b874

(void)lpvReserved;

should be the place to do this check.

Unfortunately, this is not possible. I have built SWT binaries against Windows SDK 10.0.26100.3624 by adding a method to the binaries that was introduced with that exact SDK version. In addition, I added an exit(1) to the DllMain of the SWT DLL: HeikoKlare@91b65d7

On a Windows system based on build 26100 (24H2), the DllMain is executed, i.e., exit(1) is called and aborts the application. On an older Windows system based on build 22631 (23H2), a linkage error is thrown on startup, i.e., the DllMain is not executed at all.

So I think there is no way around having a separate way (like a separate Dll or a CLI call) to check the Windows build version.