Slashdot Mirror
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.
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.
Windows on ARM was Microsoft's hedge against the latter scenario. If Intel imploded, it wouldn't take their Windows franchise with it. The possibility of losing their biggest software platform to ARM also put enormous pressure on Intel to reduce the power consumption of the CPUs. Which they did, and as a result current Intel quad core laptops have just a 15W TDP and can run circles around ARM devices.
Microsoft never intended to sell Windows for x86 and Windows for ARM beside each other. It was an either/or hedge based on performance per Watt, and x86 won out. The only reason it's resurfacing again is because laptop prices have been dropping. You can get a decent baseline model for less than $500 now, which used to be a good sale price for an about-to-be-discontinued model a few years ago. As the price drops, something has to give. Most of the hardware has already been pared down to razor-thin margins. The only two remaining pieces of fat left in modern laptop prices are:
Microsoft isn't gonna give up the OS slice of that pie, so they're gonna wave around Windows on ARM in a threatening manner to see if they can pressure Intel into giving up some of their slice of the pie.
I imagine the inability of third party cloud storage apps is a "flaw" that won't be fixed any time soon. Sorry Dropbox and google Drive, you're out.
No, no, no. It's a technical limitation of emulation, not some kind of insidious plan to block out competition.
Windows 10 on ARM supports shell extensions just fine -- the vendors have to recompile their applications is all. Nothing Mac OS developers didn't go through during the PPC -> Intel transition twelve years ago.
Literally anyone who's written shell extensions for Windows Explorer before will already understand the problem: shell extensions are loaded into the same process as Windows Explorer itself. Loading x86 code into a process that's running native ARM code just isn't going to work.... lots of issues that are pretty much impossible to work around, like calling conventions, endianness, memory layout, ASLR implementation.... all sorts of fun things. How would you even get an x86 emulator to pick and choose when to kick in? Based on memory ranges of loaded DLLs? No way -- you don't want that kind of voodoo horseshit going on in your apps, especially Windows Explorer, whose extensibility model is already pretty rickety as it is.
For over a year we've been treated to the fantasy that Windows 10 on ARM was the same as Windows 10 on x86.
No one thought that. Microsoft has been very clear from the outset what Windows 10 on ARM offers.
64-bit apps will not work.
Incorrect. 64-bit ARM applications will work, of course. And Microsoft has always said the initial target for x86 emulation was 32-bit applications. That was announced in 2016.
It cannot use x86 drivers.
Of course it can't. Why would anyone think it would?
Are you sure? They've explicitly mentioned that classes of apps won't work at all, not that they'd need a recompile.
That is just the usual Slashdot shithole editors. selectively quoting, even the article clearly states they just need a recompile.
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;