[win32][arm64] Support Dark Theme on newer Windows builds

[hmartinez82]

Continues #1048 #1045

Here's the disassembly:

00007FFA2A1D3E10 D503237F             pacibsp  
00007FFA2A1D3E14 F81F0FF3             str         x19,[sp,#-0x10]!  
00007FFA2A1D3E18 A9BF7BFD             stp         fp,lr,[sp,#-0x10]!  
00007FFA2A1D3E1C 910003FD             mov         fp,sp  
00007FFA2A1D3E20 B00007E8             adrp        x8,wil::details::g_enabledStateManager+40h (07FFA2A2D0000h)  
00007FFA2A1D3E24 B94BB913             ldr         w19,[x8,#0xBB8]  
00007FFA2A1D3E28 2A0003E1             mov         w1,w0  
00007FFA2A1D3E2C 912EE100             add         x0,x8,#0xBB8  
00007FFA2A1D3E30 97FF7910             bl          _InterlockedExchange (07FFA2A1B2270h)  
00007FFA2A1D3E34 2A1303E0             mov         w0,w19  
00007FFA2A1D3E38 A8C17BFD             ldp         fp,lr,[sp],#0x10  
00007FFA2A1D3E3C F84107F3             ldr         x19,[sp],#0x10  
00007FFA2A1D3E40 D50323FF             autibsp  
00007FFA2A1D3E44 D65F03C0             ret

The add x0,x8, instruction changed its parameter. So now the adrp x8,... instruction looks more stable because it uses a global variable (Using a global variable is also what is done when validating for the Intel x64 uxtheme.dll)

See https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/ADRP--Form-PC-relative-address-to-4KB-page-

• functionPtr[0x10] & 0x1F) == 0x08 checks that the destination register is x8
• (functionPtr[0x13] & 0x90) == 0x90 checks that the opcode is ADRP

[github-actions]

Test Results

   418 files  ±0     418 suites  ±0   10m 39s ⏱️ + 3m 2s
 4 121 tests ±0   4 113 ✅ ±0   8 💤 ±0  0 ❌ ±0 
16 313 runs  ±0  16 221 ✅ ±0  92 💤 ±0  0 ❌ ±0 

Results for commit 1a35d6e. ± Comparison against base commit 49c04a7.

♻️ This comment has been updated with latest results.

[chirontt]

Thanks for your quick work! I now have the dark scrollbars again in my Arm64 box. Here are how I test it:

• merge this PR to my fork, and then locally rebuild the SWT native binaries by:

cd binaries\org.eclipse.swt.win32.win32.aarch64
del swt*.dll
mvn clean process-resources -Dnative=win32.win32.aarch64

The above mvn command would produce the updated SWT native (swt*.dll) files in the current directory.

• create the module jar file which would embed the above SWT natives:

mvn clean verify

and the org.eclipse.swt.win32.win32.aarch64-3.126.0-SNAPSHOT.jar file is generated in the target directory.

• manually run the Java test file Bug562043_DarkTableNoHover.java, using the above jar file in the classpath:

java -cp target\org.eclipse.swt.win32.win32.aarch64-3.126.0-SNAPSHOT.jar ^
..\..\tests\org.eclipse.swt.tests.win32\ManualTests\org\eclipse\swt\tests\win32\snippets\Bug562043_DarkTableNoHover.java

and the test program shows correct dark scrollbars in its window:

For comparison, here's the same window (with lighted scrollbars) before this fix:

[chirontt]

Further more, I've built the complete Eclipse SDK with this fix, from my aggregator fork, and here's its main window showing nicely dark scrollbars on my Arm64 box:

In previous builds before this fix, it was showing lighted scrollbars, which alerted me to the changed uxtheme.dll file due to recent Windows Arm64 update.

[HannesWell]

@niraj-modi or @SyntevoAlex could you please review this? I have no clue about the native code and no way to test it.

[SyntevoAlex]

The new test looks quite weak to me, because adrp x8, ??? is a rather common instruction which doesn't really identify the function we need for the dark theme.

I suggest that instead both offsets 0xBB8 and 0xBD8 are recognized (to recognize both windows versions)

[hmartinez82]

@SyntevoAlex ah good idea. I'll work on that tomorrow :)

[hmartinez82]

@chirontt can you try with the latest changes? I changed the title of the PR too

[SyntevoAlex]

It would be nice to also have code comments with Windows versions, like here:

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

Lines 124 to 138 in 1a35d6e

	/* Win10 builds from 21301 */
	if ((functionPtr[0x31] == 0xBA) && // mov edx,
	(*(const DWORD*)(functionPtr + 0x32) == 0xA91E)) // 0A91Eh
	{
	return TRUE;
	}
	/* Win11 builds from 22621 */
	if ((functionPtr[0x15] == 0xBA) && // mov edx,
	(*(const DWORD*)(functionPtr + 0x16) == 0xA91E)) // 0A91Eh
	{
	return TRUE;
	}
	return FALSE;

[SyntevoAlex]

^ this is just a suggestion, I will still approve without it.

[hmartinez82]

I don't have the old versions. @chirontt Can you find me the Windows builds before and after the original PR stopped working?

[chirontt]

Can you find me the Windows builds before and after the original PR stopped working?

I'm not quite sure I follow you here. It's not the Eclipse build that stops working; it's the recent (last month's) Windows Arm64 update that causes the problem due to changes in the uxtheme.dll in the Windows update. With your latest Windows version running in your Arm64 box, the lighted scrollbar problem appears, for any Eclipse WoA versions.

You can grab the latest build of the Eclipse SDK here especially the WoA zip package. Just unzip it and run the Eclipse IDE, put it in dark mode and you'll see the lighted scrollbars in the IDE. This latest build contains your original commit for the os_custom.c file.

To see if/how it works before, you need to restore your WoA box to before the current (last month's) Windows update, and test it with the same Eclipse SDK mentioned above. You'd see the dark scrollbars as intended.

[chirontt]

can you try with the latest changes? I changed the title of the PR too

I've tried the same steps as in my previous comment, and the scrollbars are still properly in dark mode, with your latest fix. Here's the screenshot of the Bug562043_DarkTableNoHover.java test:

[SyntevoAlex]

@chirontt Just to clarify:

• Before this PR, on your newest Windows, scrollbars are light
• With this PR, on your newest Windows, scrollbars are dark once again
  is that correct?

If yes, please run ver in your commandline and give us Windows version number (where it was broken and now once again fixed).

[chirontt]

* Before this PR, on your newest Windows, scrollbars are light

Yes.

* With this PR, on your newest Windows, scrollbars are dark once again
  is that correct?

Yes.

If yes, please run ver in your commandline and give us Windows version number (where it was broken and now once again fixed).

>ver

Microsoft Windows [Version 10.0.22631.3447]