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.
Sounds more like a list of things they need to fix unless they want Windows RT part 2.
All this will do is encourage use of Win32 over Win64 and the limited UWP.
'Sounds like a crippled version of Windows (probably some S-like version) on a chip best employed in toasters.
A complicated, overly-limited mess. Another win for Redmond!
The ARM port can't run x86 drivers?
Say it isn't so!
That Slashdot has completely hit rock bottom...
Well darn. I was hoping to run VirtualBox on it so it could run Windows programs.
Weaselmancer
rediculous.
But when can I get an ARM-based desktop anyway? I already have a toaster.
Looks like they've put their work in really.
Lack of x64 is an issue, but I do wonder how you'd have any chance of running drivers for a whole different processor in any meaningful way. Even multiple quite old versions of DirectX.
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.
Now that's an interesting predicament, what kind of shenanigans is going on under the hood there MS..
I don't read AC
you trust a nasty company to support early versions of their products?
nobody trusted comtributions from SCO.
Software today is distinguished from free and pre-payed: communists outlaw ownership of software, moe become the next wave of capitalists.
It took how many jelly beans for Microsoft Corp & friends to accelerate software life expectacy to fail OpenGL? ARM is the next target to cripple.
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 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.
It support ARM64 just fine... it's x64 that it doesn't support....
FYI: Windows CE ran on ARM processors in the late 90s, back about half a decade before PC performance plateaued and sales gradually began to fall.
If these are the limitations you are willing to accept then you might as well just use Linux with WINE. It'll run more applications than this garbage.
Anons need not reply. Questions end with a question mark.
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?
Microsoft taught everyone about commoditizing their suppliers. Intel was just the biggest and last lesson.
This is about Windows 10 on ARM64
I'll pass.
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.
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;
Been there, dumped that...
Glad to see that whomever over there in MS who knew how to play the game retired.
Wasn't there a big court case recently when Oracle tried to sue Google over the Java API.
That was copyright. Patents expire after 20 years, so the 64bit issues should be coming to a head real soon. (It is from time of filing, not time of release in a product.)
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.
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-...
Now all they need to do is rename it - how about Windows RT?
Will Virtual PC 2007 run on the ARM setup?
If those are the only limitations, 99,999% of all legacy Windows software will work on ARM.
Windows NT on alpha, mips, power pc.
ARM is just another hal, right? With a bunch of lame emulation in some cases.
Will it still provide a week of reading for ordinary people and two terms of classwork for legal students?
You owe me a new keyboard. I just spat my coffee into it.
Huh? The Windows NT kernel was originally brought up on the Intel i860 (RISC processor) and then ported to x86, to make sure that it was portable and didn't include any x86isms outside of the HAL. They've been maintaining ports to other architectures internally since then to ensure that it keeps this property.
If you read Tanenbaum's Modern Operating Systems, you'll see a good comparison of the NT kernel to a couple of UNIX systems and it comes off pretty well in the comparison.
I am TheRaven on Soylent News
nice theory, but it falls flat on two counts:
microsoft isn't getting fifty bucks from major oems like hp or dell for a windows license...
and arm-based units will fall under that netbook|low end hardware category that has previously qualified for ridiculously-cheap licenses when built to certain hardware limits.
this is about market share, not profits from windows licenses. microsoft is losing the growing low-end market to android and chromebooks, losing the academic market to those and apple, and is even losing 'enterprise' sales as well as mobile workers are turning more and more to their phones (which aren't running windows anything) instead of a traditional notebook pc.
windows 10's revenue stream is from ads, app preloading and 'store' commissions, and marketshare is needed for that... marketshare at any cost.. remember, they 'gave away' windows 10 for two years.
Its going to be so restrictive that most Windows users like with 10S will simply pass only worse with a ARM you simply cannot install another full version of Windows 10. There will be no upgrade path. These devices will be pretty pathetic and limited in use, sort of like a Chromebook with Windows. I'll pass.
...when you decide to use a cell phone architecture instead of a real full powered computer design.
Pretty obvious to me that that Windows 10 on ARM is not ready.
sofa king ghey
probably a good thing that you can't use a computer if you find that shocking. Anyone with low level OS developer knowledge will tell you the same thing. NT Kernel is actually a very good design and implementation.