Reinstall as arm64?

[thomthom]

I have an Surface 11 tablet, arm64 and I was noticing that a TUI app I wrote was quite a bit slower on the machine.

I'm not 100% sure, but it looks like I have ended up with x64 version of Windows Terminal instead of the arm64 version;

That "Windows on Arm" option is only enabled for x64 binaries on arm64 OS, right?

I thought Windows Terminal was pre-installed on the machine, if I wasn't I got it via Windows Store - so it's not like I picked the x64 build myself.

I was wondering if there are some compatibility issues with running Windows Terminal as native arm64? Or am I good to uninstall the version I have and reinstall? If so, do I have to grab the arm64 build from github instead of using Windows Store?

[DHowett]

You know, I'm not sure about that option. It may be based on the executable you've selected, yes. But there's one big caveat here: if you're looking in WindowsApps, wt.exe there is not a real executable and the shell can't tell what architecture it is at all.

The best way to figure out how Terminal is running is to start it, then go to Task Manager > Details and enable the Platform column and look at WindowsTerminal.exe.

The second best way is to ask the app package catalog which exact terminal package is installed:

PowerShell:

Get-AppxPackage Microsoft.WindowsTerminal* | ft PackageFullName

[thomthom]

Yea, that WindowsApps folder had me puzzled. I thought first it was a symlink, but turns out it's some different "proxy" file item?

In any case, I used that powershell command and found the real location and ran dumpbin;

C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.22.12111.0_arm64__8wekyb3d8bbwe>dumpbin /headers wt.exe
Microsoft (R) COFF/PE Dumper Version 14.44.35211.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file wt.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
            AA64 machine (ARM64)
               6 number of sections
        688A5576 time date stamp Wed Jul 30 19:25:10 2025
               0 file pointer to symbol table
               0 number of symbols
              F0 size of optional header
              22 characteristics
                   Executable
                   Application can handle large (>2GB) addresses

Looks like it's ARM64 after all. Which now makes me wonder why I'm seeing the performance difference in the UI app when it's not going via any compatibility layers. 🤔

[DHowett]

This is perhaps a silly question, but is the TUI app arm64-native? 😉

[thomthom]

Yes, it's arm64 native. Which is why I found it so surprising.

I've dug around a little, and the spikes appear to relate to using sleep_for or sleep_until in my app loop (TUI game). On my x86 machines it's pretty reliable in sleeping for 1ms to reduce the CPU time from 100% of the core to ~1%. But on the Surface machine I end up with frequent spikes that makes the frame lag, ~20-30ms. If I remove the sleep calls and just spin the loop at 100% CPU it's all smooth and no spikes. Unfortunate and the Surface is the one that would benefit the most from less CPU usage in terms of battery usage.

In any case, this doesn't appear to be related to Windows Terminal, but rather an arm64 or Surface 11 thing.
Thank you for you attention though.

[DHowett]

Thanks for following up! I wonder if the scheduler is somewhat more relaxed there in the name of better power consumption...

[thomthom]

Yea, maybe. It's far out of my wheelhouse and I couldn't find any reading material on the topic (not that I know exactly what to search for(. But it seems strange since it has 10 logical cores and little else running. I was thinking of doing some timings of the sleep itself and compare, and maybe see if I can instrument some other tooling to get insight what is happening with the system itself.
I also thought it might be something happening while running on battery, but plugging in the power cord didn't change anything either.
Might try StackOverflow - see if the hive mind have any ideas.