ARM 64 support

[old-dog-pear]

Can an arm64 version be produced? X64 freezes when opening in Windows On Arm, thanks to the developer

[old-dog-pear]

I have found the developer's answer under other questions, although the problem of slow opening of the ARM version cannot be solved at present, I look forward to the future

[BumpyClock]

It compiles just fine on ARM64 and runs. @Spiritreader can you compile the releases for ARM64 and release them? I see significant perf improvements when running my ARM64 compiled version of the app vs the x86_64 version

[Spiritreader]

As ARM support improves we will of course look at building for that arch.
However, our build and update system also needs to be adapted, otherwise the app will just sidegrade to x86.

Once we know for certain that the entirety of the System.Management tools are compatible, including WMI and #660, we can move ahead in looking at this.

So, the deal is this: I don't have an ARM system, so I can't test for it.

The most useful thing people can do to move this along would be to have testers on ARM actively compile that app and debug it to check whether the ManagementEventWatcher calls are working:

Windows-Auto-Night-Mode/AutoDarkModeSvc/Handlers/WMIHandler.cs

Line 37 in cf7a0fe

ManagementEventWatcher autostartWatcher = new(query);

They are used here:

Windows-Auto-Night-Mode/AutoDarkModeSvc/Monitors/WindowsThemeMonitor.cs

Line 80 in cf7a0fe

globalThemeEventWatcher = WMIHandler.CreateHKCURegistryValueMonitor(HandleThemeMonitorEvent, "SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Themes", "CurrentTheme");

and here:

Windows-Auto-Night-Mode/AutoDarkModeSvc/Governors/NightLightGovernor.cs

Line 197 in cf7a0fe

nightLightKeyWatcher = WMIHandler.CreateHKCURegistryValueMonitor(UpdateNightLightState, "Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\CloudStore\\\\Store\\\\DefaultAccount\\\\Current\\\\default$windows.data.bluelightreduction.bluelightreductionstate\\\\windows.data.bluelightreduction.bluelightreductionstate", "Data");

As well as in the UI here:

Windows-Auto-Night-Mode/AutoDarkModeApp/MainWindowMwpf.xaml.cs

Line 82 in cf7a0fe

DWMPrevalenceWatcher = new ManagementEventWatcher(query);

and here:

Windows-Auto-Night-Mode/AutoDarkModeApp/Pages/PageSettings.xaml.cs

Line 51 in cf7a0fe

private readonly ManagementEventWatcher autostartWatcher;

If that doesn't throw an exception, and works then we can move ahead.
What these handlers do:

• update which Windows theme is currently active (critical)
• check if night light is active (critical)
• check which DWM settings are active for the UI (breaks the UI if not working properly)
• check if autostart is enabled (not super critical)

Unfortunately, I don't have a lot of time at the moment and new features / arch changes will remain on the backburner for the forseeable future. However: The more preparation steps are done, the faster things move along in the future.

[xgdgsc]

I did a search and found dotnet/runtime#81400 . Updating the dependency System.Management to 8.0.0 of AutoDarkModeApp and AutoDarkModeSvc seems to have fixed the UI error as #812 .

[Spiritreader]

As ARM support improves we will of course look at building for that arch. However, our build and update system also needs to be adapted, otherwise the app will just sidegrade to x86.

Once we know for certain that the entirety of the System.Management tools are compatible, including WMI and #660, we can move ahead in looking at this.

So, the deal is this: I don't have an ARM system, so I can't test for it.

The most useful thing people can do to move this along would be to have testers on ARM actively compile that app and debug it to check whether the ManagementEventWatcher calls are working:

Windows-Auto-Night-Mode/AutoDarkModeSvc/Handlers/WMIHandler.cs

Line 37 in cf7a0fe

ManagementEventWatcher autostartWatcher = new(query);

They are used here:

Windows-Auto-Night-Mode/AutoDarkModeSvc/Monitors/WindowsThemeMonitor.cs

Line 80 in cf7a0fe

globalThemeEventWatcher = WMIHandler.CreateHKCURegistryValueMonitor(HandleThemeMonitorEvent, "SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Themes", "CurrentTheme");

and here:

Windows-Auto-Night-Mode/AutoDarkModeSvc/Governors/NightLightGovernor.cs

Line 197 in cf7a0fe

nightLightKeyWatcher = WMIHandler.CreateHKCURegistryValueMonitor(UpdateNightLightState, "Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\CloudStore\\\\Store\\\\DefaultAccount\\\\Current\\\\default$windows.data.bluelightreduction.bluelightreductionstate\\\\windows.data.bluelightreduction.bluelightreductionstate", "Data");

As well as in the UI here:

Windows-Auto-Night-Mode/AutoDarkModeApp/MainWindowMwpf.xaml.cs

Line 82 in cf7a0fe

DWMPrevalenceWatcher = new ManagementEventWatcher(query);

and here:

Windows-Auto-Night-Mode/AutoDarkModeApp/Pages/PageSettings.xaml.cs

Line 51 in cf7a0fe

private readonly ManagementEventWatcher autostartWatcher;

If that doesn't throw an exception, and works then we can move ahead. What these handlers do:

* update which Windows theme is currently active (critical)

* check if night light is active (critical)

* check which DWM settings are active for the UI (breaks the UI if not working properly)

* check if autostart is enabled (not super critical)

Unfortunately, I don't have a lot of time at the moment and new features / arch changes will remain on the backburner for the forseeable future. However: The more preparation steps are done, the faster things move along in the future.

@xgdgsc if you can verify that everything works here we can move along with this. The next challenge at that point would be modifying the update system to detect which arch windows runs on and modify it accordingly.
We also need to internally change our build pipeline to incorporate arm.

We could then also look into this again #658

[xgdgsc]

Yes. It works. I have a group chat of people with arm devices testing this and no issue have been reported so far.

[BumpyClock]

I also have an arm device Surface Pro 9 if you need another tester.

[xgdgsc]

Uploaded to https://github.com/xgdgsc/Windows-Auto-Night-Mode/releases/download/arm/adm-app.zip @BumpyClock can test.

[Spiritreader]

Please check if this works
https://github.com/AutoDarkMode/AutoDarkModeVersion/releases/download/10.4.2.8/ADM_ARM64.zip

And verify that it says "Arch: ARM64" or similar on the "About page"

Example: This should say ARM64 instead of X64

Once I know that this build works I can start integrating arm builds into the update system (where the idea is that ADM will automatically upgrade to an ARM version if one is available, no user input required)

[xgdgsc]

I tested your package. It works as expected.

[Armin2208]

Do you guys feel any improvements with the native ARM64 version compared to the previous x86 version?

[BumpyClock]

yep, feels way more responsive.

[Spiritreader]

Alright, then the only thing we have to resolve is that the updater (which is still x86 due to technical reasons again) cannot seem to write to disk in x86 emulated mode.

Once we figured that out I'll update again.
In the meantime, arm builds will now be auto-published under
https://github.com/AutoDarkMode/AutoDarkModeVersion/releases

Atm they're stil unsigned, as soon as they are integrated into the update system I will include them into our signing system.

[Armin2208]

Again needing a ARM user to verify that:

it seems like the updater doesn't have write access. Please download the newest STABLE Auto Dark Mode release version. Then open Auto Dark Mode App and navigate to settings. Enter the Beta channel and search for an update. Please try to install the update. Does it work or do you see an update error?

We would much appreciate if you would try this. This is a major issue.

[Spiritreader]

Again needing a ARM user to verify that:

it seems like the updater doesn't have write access. Please download the newest Auto Dark Mode release version. Then open Auto Dark Mode App and navigate to settings. Enter the Beta channel and search for an update. Please try to install the update. Does it work or do you see an update error?

We would much appreciate if you would try this. This is a major issue.

You would need an older version than current to trigger the updater. So make sure to download stable release.

[HuaDeity]

I installed the latest stable X64 version and checked for updates within the application. Although I successfully updated to the Beta version, it remains an X64 application instead of being ARM64 as expected.

[old-dog-pear]

The arm64 version has been used on Surface Pro X. Compared with the X64 version, the page opening speed is 4 seconds faster (x64 takes more than 8 seconds). The page cannot slide normally when the screen is touched. When selecting the BETA channel to update, it will prompt that there is no update content.
( Commit: d5fa712

• Service/App: 10.4.2.8
• Updater: 3.1.4
• Shell: 1.3.3.0
• .Net: 8.0.0
• Windows: 22635.3140
• Arch: Arm64

[Armin2208]

I installed the latest stable X64 version and checked for updates within the application. Although I successfully updated to the Beta version, it remains an X64 application instead of being ARM64 as expected.

Yes, this is intended behavior, because we didn't implement the distribution of ARM based builds in the Updater yet. We just wanted to know if the Updater works in general, because on some ARM devices it doesn't seem to work.

When selecting the BETA channel to update, it will prompt that there is no update content.

Because you already use the newest Beta version of Auto Dark Mode. To test the Updater, you need to delete/uninstall the ARM64 version. Then you need to download the current stable version of Auto Dark Mode, like for example from the Microsoft Store. After that, join Beta channel and you will receive an update. Please try to update to the newest beta version and see if it succeeds or any error message appears.
Yes after that you will still be on X86, but we really need to know if the Update process works in general on ARM.

[HuaDeity]

I am running Windows on a Parallels virtual machine on my M1 Pro MacBook, and the update program is functioning normally.

[Spiritreader]

Updating with the built-in updater should now upgrade all ARM users to the ARM64 version of Auto Dark Mode
!!ON THE BETA CHANNEL!!
If you're not on beta, you will have to update to beta first. Only then the ARM upgrade will be offered.

Once you're on beta, you will first be offered a non ARM upgrade.
After updating to the latest version, the ARM version will be offered.
If not, then you've probably configured the updater to not look for updates at ADM startup.
In that case, go to settings and click on "Check for updates" manually.
You should see a toast notification with the same version you currently have installed and (ARM64).

Keep in mind that this upgrade path is completely untested, please report issues with the upgrade process immediately.

[HuaDeity]

The upgrade failed, still in 10.4.1.1 version ,attach with the log:

service.log

updater.log

[xgdgsc]

Downloading from https://github.com/AutoDarkMode/Windows-Auto-Night-Mode/releases/download/10.4.1.1/AutoDarkModeX_10.4.1.1.exe and update to beta version of 10.4.2.10 (x64) works for me on arm.

[Spiritreader]

The upgrade failed, still in 10.4.1.1 version ,attach with the log:

service.log

updater.log

@HuaDeity Yep, you've run into a known issue where for some reason administrative privileges are required to run the updater. We're not yet sure what causes this.

@xgdgsc Can you now update to 10.4.2.10 ARM? Or do you run into the same issue?

[xgdgsc]

No new update prompt on 10.4.2.10 (x64) version. While using https://github.com/AutoDarkMode/AutoDarkModeVersion/releases/download/10.4.2.10/ADM_ARM64.zip everytime I start I can see an update with same version number available and a download can be started and progress finished then nothing changes.

[Spiritreader]

No new update prompt on 10.4.2.10 (x64) version. While using https://github.com/AutoDarkMode/AutoDarkModeVersion/releases/download/10.4.2.10/ADM_ARM64.zip everytime I start I can see an update with same version number available and a download can be started and progress finished then nothing changes.

Please check if it works now.
You should get an upgrade to 10.4.2.11 now on the ARM version

[HuaDeity]

@Spiritreader

I successfully upgraded to the Arm64 version 10.4.2.11 while running as an administrator. The upgrade process first installed the x64 version of 10.4.2.11 before proceeding with the Arm64 version.

However, even after upgrading to the Arm64 version, I continued to receive prompts for further upgrades which resulted in an infinite loop of launching and upgrading attempts.

[Spiritreader]

@HuaDeity

However, even after upgrading to the Arm64 version, I continued to receive prompts for further upgrades which resulted in an infinite loop of launching and upgrading attempts.

Should be fixed with 10.4.2.12. The new update should be offered now and once you're on that version the loop should stop.

However I have no idea why administrator privileges are requires still? Is it not possible to launch x86-64 apps from an ARM context?

EDIT: I've pushed 10.4.2.13 which includes an ARM64 build for the updater. Please try updating and check if you still need administrator privileges to perform the update.

[xgdgsc]

Updating from 10.4.2.10 to 10.4.2.13 works for me.

[HuaDeity]

@Spiritreader

The update was successful without requiring administrator privileges.

[Spiritreader]

How's everyone's experience with the ARM build compared to the previous x86 version?

Did you encounter any issues so far?

[xgdgsc]

No issue here.