Windows on ARM has been tried before with Windows RT, but the systems were crippled, and it was not exactly a success. Microsoft and Qualcomm are now giving it another try with ARM mobile computers running the full version Windows 10 on Qualcomm Snapdragon 835 processor, and Asus, HP, and Lenovo building devices based on the solution.
There are plenty of inexpensive Intel PCs running Windows 10, so what would be the benefits of using Snapdragon 835 SoC? Qualcomm explains that it’s the first to coming integrate Gigabit LTE, it offers up to 50% longer battery life in specific use cases like watching videos and gaming, and thanks to big.LITTLE technology provides up to 4 to 5 times improvement in battery life compared to Intel’s solutions.
Windows 10 does not have the same limitations as Windows RT had, and you can do pretty everything that you would on an Intel PC, including installing and running 32-bit x86 application thanks to an emulation layer that convert x86 instructions to ARM ones.
Mobile Geeks filmed a demo in Qualcomm booth, showing Office (Word, Excel, Powerpoint), Outlook, installing a 32-bit x86 application, multi-tab web browsing over an LTE connection, and playing some YouTube video, including a 4K video. As a side note, the demo guy told the “legal department told him to only show Qualcomm content”, probably because of inane copyrights laws. That’s really ridiculous that those laws apply to showing a 10s clip for an hardware demo. But I digress, and it was stressed again that it was the first time big.LITTLE was supported in Windows 10, and allowed for much better efficiency.
Via Liliputing
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Key question will be how fast the x86 emulation will run and how long updates will be supplied…
Nice! Now, about those OEM machines (where we’ll be running linux ; )
At 0:50 the presenter says Excel is run through the emulator … What?! If Microsoft wants Windows-on-ARM to be a success, it should provide Microsoft software natively on ARM, so Windows + Office + Edge + IE + VisualStudio.
If even Microsoft finds that too much trouble, how can they expect others to compile for Windows-on-ARM to achieve full speed?
@Sander
Good point. Maybe they started with the development of the Emulator. Make the Emulator as fast as possible and now they start with the native converting.
@All Is someone at the Computex and can ask this question?
@Sander
He’s talking about an ’emulation layer’ but I would assume in reality that’s no emulation but something comparable to Transitive’s QuickTransit (maybe Microsoft simply licensed the technology und integrated it into Win10 for ARM).
@tkaiser
It’s definitely some form of binary translation – anything else would be too slow.
@blu
Of course, and an emulation would not only be too slow but somewhat stupid.
To me this looks like an intelligent approach: Provide the ABIs to natively deal with all the stuff that has to happen on specific SoC engines (that’s 2D, 3D and video acceleration as well as dealing with LTE networking) to get full speed and energy efficiency while dealing with the stuff that has to run on CPU cores both natively as well as using a binary translation so x86 compatibility is never a concern (as long as we’re talking about 32-bit binaries). x86 compatibility is mandatory for Win10 on ARM becoming a success anyway so why not show demos with x86 Office suite (or Adobe’s Creative Suite)?
This stuff works pretty well, we went through this already 11 years ago with Apple’s transition from PowerPC to x86 (they licensed Transitive’s software and called it Rosetta for whatever reasons back then). IIRC there was only one major problem with combining native and ‘foreign’ apps/libs back then: So called PDE (printer dialog extensions) had to match the architecture of the application displaying the printer dialog (so you ran both in troubles with old PDEs only available as PowerPC code with x86 apps and the other way around).
BTW: It took years until huge application suites (Microsoft Office or Adobe’s Creative Suite for example) were available in a native version on x86 but that was not due to the CPU architecture switch but just since frameworks changed in the meantime too. Old PowerPC applications used ‘Carbon’ while programming for x86 OS X applications required adopting Cocoa frameworks. We were in touch with some Adobe engineers back then and they reported their company evaluating to drop Apple support entirely due to the amount of work necessary to create a native version (but then they rewrote application after application more or less from scratch for Cocoa/x86 within the next years)
Fortunately I’ve not the slightest idea how Windows internals work at this level but I would assume it’s somewhat identical so Microsoft’s decision to let 32-bit x86 applications run without recompilation on ARM seems pretty smart to me.
@tkaiser
Sure, that tech does work, people will benefit from it. Me personally, I’m just glad it will have better adoption than Canonical’s product – I was getting worried I was running out of ARM 2-in-1/netbook suppliers ; )
BTW: I’ve been recently reminded how much ’emulation’ layers you can stack on top of each other while it still works a treat. One customer has a Windows box providing a virtualization environment (either VirtualBox or VMWare Player — forgot the details) for OS X 10.4. The x86 version contains both Rosetta (see Transitive above) to execute PowerPC binaries as well as the so called ‘Classic Environment’ to emulate a whole pre OS X MacOS environment. In this environment (it’s not really an emulation) there runs an old MacOS 9.2 which contains also an ’68k emulator’ for Motorola 680×0 CPUs (this emulation was necessary since Apple did never port the whole MacOS from 68k to PowerPC, some very basic stuff ran emulated all the time in the PowerPC MacOS versions).
And inside of that they run a q&d ‘AppleScript application’ I hacked together almost 20 years ago. Since AppleScript is rather slow I made use of so called ‘Scripting Additions’ back then and my favourite was something called Tanaka’s OSAX (OSAX –> Open Scripting Architecture eXtension). Which was not built in the usual way (using C and following the OSAX design principles) but was originally coded in HyperTalk and transformed into an OSAX then. Even without all the ’emulation’ layers that have been added within the last 15 years I thought this would be somewhat too hack-ish… but since it was just a quick PoC to be replaced soon by something stable… couldn’t be more wrong, it’s still in use now even with an added Windows GUI 😉
@tkaiser
10.4 x86 never had Classic. I wonder if they are using SheepShaver?
@parrotgeek1
Oops, you’re right. So they must have changed something when they virtualized the setup one or two years ago (the PowerMac G4 they kept for this purpose before all died in the meantime).
Some details about the x86 translator: https://channel9.msdn.com/Events/Build/2017/P4171
@blu
You forgot to mention that everyone interested in x86 translation should really skip the first 6 minutes 😉