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

Impossible!

[Anonymous Coward]

The ARM port can't run x86 drivers?

Say it isn't so!

That Slashdot has completely hit rock bottom...

Re:Impossible!

[K. S. Kyosuke]

Isn't one of the limitations the forced secure boot crap? (And I'm pretty sure there's more screwy stuff in there. With MS, there always is...)

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.

Re:Yawn

[Anonymous Coward]

crippled version of Windows

Seems redundant.

64 Bit Support is Unlikely

[nateman1352]

I would be surprised if X64 support ever sees the light of day. I'm sure both Intel and AMD have many patents that make implementation of X64 emulators impossible without running afowl and infringing. AMD might be willing to license to MSFT but given Intel's post, Intel is definitely not and is ready to sue. They are lucky that the 386 and older are not patented, that the only reason 32 bit support is possible. The patents start at MMX.

Re:64 Bit Support is Unlikely

[Hal_Porter]

If you were Acer and you had a prototype Windows on ARM device and you knew the performance was going to suck would you risk being party to a lawsuit where Intel sued Qualcomm and Microsoft for violating one of their 400 patents that was analogous to the one MIPS sued Lexra over?

Or would you think "Yeah, I think we'll pass on Windows on ARM".

I think that's what Intel is going for.

Or maybe they want to make sure that Microsoft agree not to emulate any instructions recent enough to be patented. I.e. the 486 instruction set and probably MMX is OK, x64 and SSE or later is not. That would mean you could only run x86 binaries and not x64 ones. And things like Photoshop are going to really suck.

Intel don't need to win a lawsuit for it to have an effect. All they need is to hint a blog that one might be coming and they can scare off hardware vendors from launching devices and Microsoft from adding SSE support to their emulator.

Amusingly the MIPS vs Lexra lawsuit means that even if you don't implement instructions that would violate a patent and do an illegal instruction trap, you can still be sued because hypothetically someone could write a trap handler which emulated them. That's some real 'through the looking glass' lawyering right there.

I don't think any of this is a surprise

[holophrastic]

So, with different hardware, anything that relies on non-ARM hardware drivers can't. Seems logical.

Also, since it's windows10, and not windows7, older graphics requires aren't there.

Again, seems logical. I'm guessing that the windows user interface has been re-built, and probably lacks a whole lot of backwards compatibility. Given that ARM devices are likely performance restricted by comparison, it's no surprise to me that there's little or no access to any ARM-specialized user interfaces (i.e. all of them). Not really disappointing, but a limitation for sure.

64-bit apps is obviously a momentary restriction -- it won't last long. That's simply proof that the project began before wide-spread 64-bit ARM adoption. It'll follow suit in short order.

HyperV, I'm sure, is similarly a few generations ahead of the windows ARM project. I'd bet that adoption of windows on ARM will dictate whether or not HyperV gets brought in at all. And reasonably so.

Windows on ARM wasn't meant to be parallel to x86

[Solandri]

You have to bear in mind what was going on when Windows on ARM came out. The PC market was shrinking, while the mobile market was exploding (both phones and tablets). Intel processors still concentrated mostly on performance, not low power consumption. So everything on mobile used ARM processors. As a result, nobody knew if mobile was just a fad, or if Intel was doomed as ARM ate into its share of the processor market.

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:

• the Intel processor (frequently $50-$100 of the price, vs about $5-$20 for ARM processors with the same silicon surface area)
• the OS (about $50 of the price)

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.

Re:To do list

[Daltorak]

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.

No

[theweatherelectric]

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?

Not surprising really

[Hal_Porter]

Back in the days NT run on Risc it was able to run x86 code, but only 16 bit x86 code. That's because the emulator was in the Windows On Windows (WOW) layer. Back then WOW was a way to run 16 bit code on a 32 bit OS. On an x86 chip it run the node natively. On Risc it used an emulator, which Microsoft had licensed from Insignia Solutions.

So on a MIPS R4000 machine you ended up with this

1) You could run Win16 and Dos x86 applications because those run in the WOW layer or in NTVDM, the NT virtual Dos machine
2) You couldn't run Win32 x86 binaries, you needed native MIPS ones
3) You couldn't run x86 drivers, you needed native MIPS ones

The R4000 was 64 bit capable but NT never run in 64 bit mode on it. Though it did on Alpha for while until that was discontinued. 64 bit mode lives on now for x64, ARM64 and maybe Itanium if you ask MS very nicely.

Now move forward to 64 bit Windows 10. The kernel is 64 bit code. WOW is used to run 32 bit binaries. On x64 it runs 32 bit code x86 code natively. On ARM it uses an emulator. So an ARM64 machine you end up with this

1) You can run Win32 applications because those run in the WOW layer. There's no NTVDM or support for 16 bit code in 64 bit Windows because that would need WOWOW - Windows on Windows on Windows.
2) You can't run Win64 x64 binaries, you need native ARM64 ones
3) You can't run 32 bit drivers, you need native ARM64 ones

Ironically given how wonderfully quirky ARM32's instruction set was and how Steve Furber reckoned that 'MIPS was clean but the cleanness lead to poor code density which hurt them they competed with us in the embedded world', (I'm paraphrasing a bit, the interview is here).ARM64 is much more similar to MIPS than it is to ARM32. I.e. no conditional execution, load/store multiple, no free shift with every instruction and no Thumb mode with two byte instructions. RIP Sophie Wilson's wonderfully devious instruction set. Still I can see why they did it - something stripped down like MIPS or ARM64 must be a lot easier to implement as out of order superscalar design than ARM32.

So the situation with WIndows on ARM is better than Windows RT on 32 bit ARM of course - that had no x86 emulator and actually blocked Win32 ARM binaries from running unless they were signed by Microsoft. This was part of Microsoft's evil plan to move people from Win32 to Windows Store applications.

What I think will be more of an issue for Windows 10 ARM is performance. A Snapdragon 835 is comparable to an Atom natively but emulation will add some overhead - some benchmarks imply a lot.

E.g. a Snapdragon 835 running x86 code gets a mere 818 single core score on Geekbench

https://www.windowslatest.com/...

That's about half the native performance which around comparable with an Atom. I.e. great for phone but terrible compared to an i5.

https://www.slashgear.com/asus...

Intel have threatened Microsoft and Qualcomm with a lawsuit if they convert SIMD instructions from SSE or AVX to NEON. So you could run 32 bit Photoshop but the emulator can't support any SIMD instruction set. And you're running on a chip which is more like an Atom than an i5/i7. That's going to suck. You can't run x64 binaries, even though most software is x64 now.

It'll run something like 7zip or Firefox OK, and those will probably have a native ARM64 binaries too, but if you try to run the x86 version of Photoshop on it the experience will be dreadful.

Outside of Microsoft everyone ignored the non x86 platforms for NT. There's a fair chance that apart from open source stuff people will ignore Windows on ARM too. It's hard to see Adobe spending much engineering time getting Photoshop to run well on Windows on ARM.

Re: Not surprising really

[Hal_Porter]

NT on Alpha could run 32 bit x86 code because Dec wrote a very clever emulator called FX!32.

That hooked into NT's process spawning when you tried to run a non native binary and run the code via Dec's FX!32. However it also did profiling. Once it knew which parts of the x86 binary were executed most frequently it would JIT them to native Alpha code.

At one point the platform which could execute x86 code was an Alpha running it via FX!32's JIT.

Re:To do list

[_merlin]

Mixed Mode Manager was beautiful in a perverse way. The killer was that classic MacOS was tied to the 68k interrupt model - right up to MacOS 9 they were still dispatching interrupts through the 68k emulator. In early versions of System 7 for PowerPC you couldn't run native PowerPC code at interrupt time at all - anything that could be called from an interrupt handler had to run in the 68k emulator (this limitation was solved relatively quickly).

You had this structure called a Universal Procedure Pointer (UPP). On the PowerPC side it contained the address of the code and a description of the argument and return types. This allowed you to call 68k or PowerPC code from PowerPC code. For 68k code to call PowerPC code, there would be a prologue consisting of an _MixedMode A-line trap followed by the argument description. Mixed Mode Manager would detect the trap, break out of the emulator, and translate the stack frame.

You could probably translate COM between x86 and ARM. Microsoft already did this once when they supported 16-bit COM components in 32-bit applications and vice versa. The stack frames had to be translated for the differing calling conventions and pointer types. They probably don't want to though - the roll-out of x86_64 has encouraged people to write more portable code.

Re:That shit-fest is hard to port

[gravewax]

The windows Kernel is actually their strongest feature, it is a well designed kernel. What sucks is the shit stacked on top of the Kernel.

Re:To do list

[gravewax]

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.

Limited Kudos.

[jimtheowl]

There is next to no chance that I will ever use this, but for those who would, it looks like useful information. You may want to skip to the actual information as the quoted article is as thin as it gets.

https://docs.microsoft.com/en-...

Re:To do list

[TheRaven64]

Last time I did ARM they could be driven in either little-endian or big-endian mode based on flags in the AIRCR register.

That's there for a specific customer who wants to keep networking code originally written for big-endian MIPS and never ported to a little-endian machine in existence and other people are strongly discouraged from using it. As I recall, you can disable SETEND in EL0 (so you trap and can detect that the user has done it and switch back on interrupt if they have). This isn't an issue for emulated x86 code, because it will be running in little-endian mode on a machine that is intended to run in little-endian mode. I thought that AArch64 had removed SETEND, but I could be mistaken.

So Microsoft isn't going to stop you from changing endianess on the fly. No doubt in coming months we'll be seeing WebASM and Javascript attacks crashing Windows 10 ARM devices because of this.

You'd have to persuade the JIT to generate a SETEND instruction, which sounds difficult.