Microsoft Finally Documents the Limitations of Windows 10 on ARM (thurrott.com)

For over a year we've been treated to the fantasy that Windows 10 on ARM was the same as Windows 10 on x86. But it's a bit more nuanced than that. Paul Thurrott: 64-bit apps will not work. Yes, Windows 10 on ARM can run Windows desktop applications. But it can only run 32-bit (x86) desktop applications, not 64-bit (x64) applications. (The documentation doesn't note this, but support for x64 apps is planned for a future release.)
Certain classes of apps will not run. Utilities that modify the Windows user interface -- like shell extensions, input method editors (IMEs), assistive technologies, and cloud storage apps -- will not work in Windows 10 on ARM.
It cannot use x86 drivers. While Windows 10 on ARM can run x86 Windows applications, it cannot utilize x86 drivers. Instead, it will require native ARM64 drivers instead. This means that hardware support will be much more limited than is the case with mainstream Windows 10 versions. In other words, it will likely work much like Windows 10 S does today.
No Hyper-V.
Older games and graphics apps may not work. Windows 10 on ARM supports DirectX 9, DirectX 10, DirectX 11, and DirectX 12, but apps/games that target older versions will not work. Apps that require hardware-accelerated OpenGL will also not work.

Comments

Re:Impossible!

[Hal_Porter]

There is no technical reason, why thou could not just emulate the drivers too.

Suppose you've got some x86 code in running on an ARM in kernel mode. It will expect everything it sees to have the x86 structure alignment. E.g. if it does an mov eax, [ebx+n] and that is translated into LD R0, [R1,#n] then you'd best hope that the structure R1 points to has the exact same thing at offset n in ARM windows that it does on x86 windows.

There are going to be some weird corner cases where that won't be the case, and then you've got kernel mode corruption. Actually if the ARM is running a 64 bit kernel and the driver is x86, that's guaranteed to be the case and you need to thunk all the structures. However I think even if you have x64 code being emulated on ARM64 there are going to weird corner cases where the layout of a kernel mode structure is going to be different.

Another issue is alignment. x86 and x64 code handles misaligned pointers transparently, though occasionally at a enormous performance hit if they span a page boundary. ARM code does not. In user mode that's no problem - you get an alignment fault, the kernel fixes it up and you go on you way, with a performance hit.

However NT kernels are architected so that you can't have page faults when you're running a raised IRQL, because if you're doing that you hold a spinlock. The page fault handler needs to acquire a whole bunch of spinlocks when it fetches a page and allowing to run at a raised IRQL risks a deadlock and a frozen system. So an NT based OS will BSOD with IRQL_NOT_THAN_LESS_OR_EQUAL in this case - what that means is that IRQL is not <= PASSIVE_MODE.

But suppose you have some x86 kernel mode code at a raised IRQL doing an unaligned pointer access. The emulator runs it and it faults. And in NT that fault is instant death. Sure you could hack the kernel so that it first tries to do an alignment fixup. However you've introduced a load of complexity to a design that was pitiless and pure initially - if kernel mode code causes a page fault at raised IRQL then it dies instantly and the solution is for users to track down the company, for the company to track down the developer and for the developer to fix his shitty code.

Actually another option would be for the emulator to check for misalignment and handle it in by avoiding the fault. This would probably work, but there's an overhead you'd need to pay on every pointer access, even the aligned ones, where you'd need to check the low order bits to make sure enough of them were zero to make it aligned before you dereferenced it.

In practice this limitation prevents one from running any game with copy protection.

Copy protection drivers are a bit like anti virus software anyway. What they're doing is grovelling around in undocumented structures and doing rootkit type shenanigans. And the idea that you're going to try to run a copy protection meant for x86 or x64 on a completely different processor architecture is a fool's errand first place. The whole point of them is to try to work out if there's something a bit hinky going on. Nothing is more hinky than running kernel mode code on the wrong CPU architecture with a bunch of hacks that tries to hide the differences and doesn't completely manage it.