Windows 10 on ARM has the following necessary limitations:
- Only ARM64 drivers are supported. As with all architectures, kernel-mode drivers, User-Mode Driver Framework (UMDF) drivers, and print drivers must be compiled to match the architecture of the OS. While ARM OS has the capabilities to emulate x86 user-mode apps, drivers implemented for other architectures (such as x64 or x86) are not currently emulated and thus not supported on this platform. Any app that works with its own custom driver would need to be ported to ARM64. In limited scenarios, the app may run as x86 under emulation but the driver portion of the app must be ported to ARM64. For more info about compiling your driver for ARM64, see Building ARM64 Drivers with the WDK.
- x64 apps are not supported. Windows 10 on ARM does not support emulation of x64 apps.
- Certain games don’t work. Games and apps that use a version of OpenGL later than 1.1 or that require hardware-accelerated OpenGL don’t work. In addition, games that rely on "anti-cheat" drivers are not supported on this platform.
- Apps that customize the Windows experience may not work correctly. Native OS components cannot load non-native components. Examples of apps that commonly do this include some input method editors (IMEs), assistive technologies, and cloud storage apps. IMEs and assistive technologies often to hook into the input stack for much of their app functionality. Cloud storage apps commonly use shell extensions (for example, icons in Explorer and additions to right-click menus); their shell extensions may fail, and if the failure is not handled gracefully, the app itself may not work at all.
- Apps that assume that all ARM-based devices are running a mobile version of Windows may not work correctly. Apps that make this assumption may appear in the wrong orientation, present unexpected UI layout or rendering, or failing to start altogether when they attempt to invoke mobile-only APIs without first testing the contract availability.
- The Windows Hypervisor Platform is not supported on ARM. Running any virtual machines using Hyper-V on an ARM device will not work.
The following table lists some common issues and offers suggestions on how to resolve them.
Issue Solution Your app relies on a driver that isn't designed for ARM. Recompile your x86 driver to ARM64. See Building ARM64 Drivers with the WDK. Your app is available only for x64. If you develop for Microsoft Store, submit an ARM version of your app. For more info, see App package architectures. If you're a Win32 developer, distribute an x86 version of your app. Your app uses an OpenGL version later than 1.1 or requires hardware-accelerated OpenGL. x86 apps that use DirectX 9, DirectX 10, DirectX 11, and DirectX 12 will work on ARM. For more info, see DirectX Graphics and Gaming. Your x86 app does not work as expected. Try using the Compatibility Troubleshooter by following guidance from Program Compatibility Troubleshooter on ARM. For some other troubleshooting steps, see the Troubleshooting x86 apps on ARM article. Your x86 app does not detect that it's running on ARM. Use IsWow64Process2 to determine if your app is running on ARM. Your UWP ARM32 app does not work as expected. See Troubleshooting ARM32 apps on ARM to learn how to get your app to work properly on ARM.
Source: Limitations of apps and experiences on ARM - UWP app developer | Microsoft Docs
Wow, those are tough. But for me the lack of x64 apps and Hyper-V support could be big potential stumbling blocks. These limitations certainly relegate ARM processors to something less than a full "x86/x64 alternative". Perhaps this ties into @Kari's notions of "Secure Windows on a Secure Device." Could this be the ultimate future platform for "S Mode" computing?
--Ed--
Hi,
Is there an English translation to this or would a simple term be MS's war against using hyper v in win-10 just began :/
Yes, I agree with Brink: I see this as a stumbling block more than an absolute deterrent or a change in direction. There's been lots of discussion about putting ARM processors in standard chassis enclosures like those specified in the Open Compute Project for Server Design. My concern comes from the question: "What good is a server than can't run Hyper-V?" in the general Windows context. At any rate, this should be interesting to watch unfold. I'm not 100% sure MS is talking about servers in this case anyway: this restriction may apply only to end-user devices. We'll see.
--Ed--
Well it really depends doesn't it. If the point of your server was to run Hyper-V you may have a point.
Lots of people running servers don't care if they run Hyper-V though. All servers I work on abstract hardware and have since the 1960s.
If you wanted to build a big server you would go for POWER if you wanted to run a big retail server or ARM if you wanted too do some mathematics. Or some other chips perhaps.
I think it would depend what you wanted to do - it isn't my specialty really - but I don't think x64 is required for anything.
I kind of get the feeling they are just trying to find a new home for 10 Mobile? I might be enthused but it won't currently run on the ARM processors in the SBC's I tinker with.
Quote