Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Windows ARM64 (Read 2304 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Windows ARM64

Hello,

Is there any chance of a Windows ARM64 (AArch64) port?

Asking re compatibility with Microsoft's Surface X Pro (Windows 10 ARM based, not x86).
https://www.microsoft.com/en-us/p/surface-pro-x/8vdnrp2m6hhc

Alternatively...has anyone tested, or heard feedback, regarding functionality via the 32 bit x86 emulation process in the Pro X?

Thanks.

FYI, in case they are useful:
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-x86-emulation
https://docs.microsoft.com/en-us/windows/arm/

Re: Windows ARM64

Reply #1 –
And ask all the developers to port every plugin to AArch64 as well, since you'll be wanting those too.

Re: Windows ARM64

Reply #2 –
Emulation should work. I was once able to test emulated foobar2000 on a Raspberry Pi 3 running Windows for ARM. It was extremely slow (as was the whole operating system), but worked.
I have not been able to buy a consumer grade ARM64 Windows device for testing, almost as if they were banned from being sold in my part of Europe.
Microsoft Windows: We can't script here, this is bat country.

Re: Windows ARM64

Reply #3 –
Okay, good. Thanks for your input. I was guessing it would likely work fine under emulation - although with some slowness (hopefully less impact on the most recent devices, like the Pro X). There seem to be relatively few reported programs that really fail to function.
For most developers I expect the porting idea will be dependent on if the ARM on Windows push becomes successful, and emerges with a significant chunk of the market. Which seems somewhat 50/50 now, at best, from what limited info I can see.
Thanks again.

Re: Windows ARM64

Reply #4 –
I'm going to bump this topic for 2021, now that we know AArch64 has a future in consumer-grade computers thanks to Apple, Microsoft, and Qualcomm. It would be nice to see an AArch64 port of Foobar2000, and as one poster mentioned, also the standard included plugins. In my testing, Microsoft's x86-64 emulation is working better with each dev build, but a native executable would require less battery power -- and long battery life is the key selling point of all AArch64 devices.

Re: Windows ARM64

Reply #5 –
Quote from: kode54 on
And ask all the developers to port every plugin to AArch64 as well, since you'll be wanting those too.

And people can pay me money for an ARM based laptop/desktop, to do the component port. I cannot keep forking out money for zero benefit.

Re: Windows ARM64

Reply #7 –
Interesting!

Re: Windows ARM64

Reply #8 –
Just FYI, for the currently available hardware, Windows for ARM runs better inside Parallels on macOS than it does on consumer bare metal hardware. But this Qualcomm hardware could also prove to be very nice as well.

At least on the Parallels setup, it runs well enough to run x86 and x86_64 games, as long as they're limited to DirectX 9-11 or OpenGL 3.2 or lower. This Qualcomm thing could probably beat that for compatibility, if it supports DirectX 12 and Vulkan, and higher versions of OpenGL.

Re: Windows ARM64

Reply #9 –
Very interested to hear that @kode54.
I'm trying to decide whether to wait for the M2 16" MacBook Pros or get one of the last Intel models now.

It sounds like if I did get an M2 MBP, I could run foobar2000 in Windows for ARM, including the classic Waveform Seekbar (which requires DirectX 9.0c) and performance would be perfectly fine?
That's very helpful to know if so... Emulation eh!

Re: Windows ARM64

Reply #10 –
Not so much emulation as ahead-of-time translation. It runs a translator on all static code on launch, and keeps a cached copy around for future runs. Same as Rosetta 2. It will use just-in-time translation if there is any code which is generated at runtime rather than part of the modules loaded.