Windows 10 on Arm Limitations

Windows 10 on Arm was first demonstrated at Computex 2017 on a reference platform based on Qualcomm Snapdragon 835 processor, at the time, I thought the expected 2-in-1 hybrid laptops based on the solution may bring cheaper Window 10 devices that work just like their x86 competitors, and offers longer battery life.

Several models including HP Envy x2 (2017) and ASUS NovaGo TP370 were then announced at the end of 2017, and prices were quite higher than most expected with pricing for the ASUS model starting at $600 with 4GB RAM and 64GB storage. But to be fair, Snapdragon 835 are used in premium LTE smartphones like Xiaomi Mi 6 that sell for around $400 and up. At least, we are still promised good battery life of over 20 hours of continuous use (e.g. playing a Full HD video).

When the laptop were announced, I read several blogs and news outlets claiming the Arm mobile PCs work just like Intel / AMD x86 laptops, but is that true? Sort of, as Microsoft has now provided more details about Windows 10 on Arm. While you’ll be able to run any 32-bit x86 programs on Arm thanks to emulation, 64-bit x64 programs won’t run at all, and when it comes to native Arm program only 32-bit Arm UWPs (Universal Windows Program) will be available, and as I understand it, 64-bit Arm programs are not supported at all for now. However, based on a discussion last January on MSDN, ARM64 user space will eventually supported with for example Edge potentially ported to ARM64, and an ARM64 SDK will be released. Microsoft is not looking a x64 emulation on Arm at all, so any 64-bit program on Arm will have to be native.

While apps needs to be 32-bit, all drivers for Arm platforms will have to be ARM64 since the OS itself is 64-bit. The drivers will have to be recompiled for Arm specifically, and if the driver maintainer (usually hardware manufacturer) does not do it for you, you’ll be out of luck.

If a developer has written a 32-bit Arm UWP program with Windows 10 Mobile, it may not fully work depending on the API used, and may have to be modified to work on Windows 10 for Arm. Other issues include the lack of Hyper-V support, so it may not be possible to run Virtual Machine (at least with hardware acceleration), and if an app uses OpenGL 1.2 (introduced in 1998) or greater, it would have to be rewritten to support DirectX 9 to 12.

While there are workaround for most issues, developers would have to work on it, and issues may be expected at least at the beginning. It could be Windows 10 on Arm will look very similar to Android on x86 with many apps not fully optimized for the platform. We’ll have to see wait and see.

I also noticed Microsoft only mentioned Windows 10 Pro or Windows 10 S for Arm, which could mean there’s no such thing as a Windows 10 Home for Arm, so you’d only have the option to run a fairly expensive operating system, or a free one with some serious limitations.

Via Liliputing and Neowin

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

19 Replies to “Windows 10 on Arm Limitations”

  1. Interesting article!

    Now my question: Microsoft Word on a Windows10-on-ARM laptop: is that an UWP (Universal Windows Platform) application, or is it native x86-32 (thus needs emulation)?

  2. What people just need is :

    Bigger screen than a phone
    Light weigth than a notebook
    Easy internet connection
    More battery life
    A OS platform (windows) that can run all their programs they use in daily or work life
    Reasonable price


    There is already Intel-Windows based solutions (Core M) in reality. All need is to optimize and provide cheaper and better SOC-OS solutions.

    Not trying to realize fantasies over SD SOCs to work on emulators which will never satisfy all and true needs.

  3. @Sander
    Based on the transcript of the linked MSDN interview, it looks like they decided to use x86 emulation for Office.

    Relevant excerpt:

    00:35:04.450 –> 00:35:06.510
    think about Office, right?

    00:35:06.510 –> 00:35:10.080
    Office was an interesting conversation
    for us to have internally, right?

    00:35:10.080 –> 00:35:13.400
    Because while in some sense, again,
    the geeks in us would want it

    00:35:13.400 –> 00:35:18.570
    to be the most performant version
    of an application that we would ever release,

    00:35:18.570 –> 00:35:21.730
    there also is this other
    interesting angle with Office,

    00:35:21.730 –> 00:35:25.120
    in that it has a massive ecosystem of add-ins, right?

    00:35:25.120 –> 00:35:30.540
    And so, if you were going to natively
    recompile Office for ARM64,

    00:35:30.540 –> 00:35:33.060
    you would break compatibility
    with that ecosystem.

    00:35:33.060 –> 00:35:34.530
    – Right.
    – Well, it turns out, on the other hand,

    00:35:34.530 –> 00:35:37.360
    that Office is actually a
    prime candidate for emulation,

    00:35:37.360 –> 00:35:41.000
    because of, back to what Hari said,
    the nature of the type of work that it’s doing.

    00:35:41.000 –> 00:35:46.440
    It’s actually not doing a lot of CPU-intensive work,
    and so we were able to, with that an our CHPE work,

    00:35:46.440 –> 00:35:49.560
    really get great performance
    out of the Office application.

  4. A couple of remarks stemming from my understanding of the entire win10/arm initiative:
    * It’s not that arm64 apps are not supported by the OS (they are) but devs won’t be able to do official arm64 UWP builds initially, even though that functionality is available in the latest MSVS, but is in alpha state and thus takes deliberate effort by devs to be enabled. I will report on that as soon as I get my device.
    * The drivers point originally raised by Liliputing is rather interesting, as notebook devices are not exactly the epitome of modular platforms, so I am still confused what drivers exactly will keep missing from a notebook, which talks to the outside world mainly via well-established usb protocols (storage, HID, etc). Re the drivers for the internals in the current crop of Qualcomm-based devices, my understanding is those are in _very_ good shape.

  5. @cnxsoft
    A windows-noob question, as I’ve never flashed an SBC fw from Windows, but why is there a driver needed for that? In linux it normally takes root privileges.

  6. @blu
    They must be doing something non-standard.
    The drivers for Amlogic shows as:
    –> WorldCup device

    So it looks like they may be using libusb inside that driver.

  7. So why not just use one of the arm based office packages that are windows office compatible, and on a native arm OS?

  8. @Just Help

    I’m totally with you ; today’s ‘laptops’ are in fact designed as portable desktops which can be run on laps and need to be plugged almost everytime. Advertised battery life are a joke or marketing junk.

    But they are poor desktops and very poor mobile laptops at a very high price. Plus, they are noisy, overheat and are designed to fail. When in fact we need a bright screen, lightweight, long battery life for mail, web, light dev. Not for running desktop benchmarks at full speed the first minute and then throttle. We can see the same trend with smartphones, it’s only about GHz, number of cores, screen size, number of pixels etc etc

    I’ve been disappointed by the lack of options with Core Ms and fanless laptops.
    The initiative of Microsoft is courageous despite the WinRT debacle; At least it will push Intel and OEMs back in the right direction.

  9. Apropos, MS would demonstrate serious acumen if they released OpenGL ES 3.x for the platform, but I might be expecting too much of them..

  10. frogg :
    @Just Help
    The initiative of Microsoft is courageous despite the WinRT debacle; At least it will push Intel and OEMs back in the right direction.

    Or is it just another move to place restrictive anti-competitive contracts in place for non-wintel OEMs?

    I just don’t see who could want these things, $US600 is an awful lot for a movie player even if it does get 20 hours of continuous “use”. At best it seems like some way to recoup the investment in microsoft windows phone – which nobody cared about either.

    I can’t see how it would make any difference to existing oem’s goals of making overpriced junk laptops designed for high benchmark scores and annual obscelescence.

    PS I don’t want a bright screen, just one that can be read in sunlight.

  11. @tkaiser
    Apple’s transition from Sierra w/ Xcode 8.x to High Sierra w/ Xcode 9.x has been a complete and utter mess. Unless you do strictly posix development (or perhaps web — I’m not familiar with that), buying into Apple’s ecosystem for development is a recipe for long frustrating hours ATM. All IMHO, of course.

  12. @blu
    I was not talking as a developer. Just wondering why people searching for laptops with ‘bright screen, lightweight, long battery life for mail, web, light dev’ don’t use them. They exist (ok, it’s not 20 hours of battery life as Microsoft claims but a little bit more than a 1/3 of that — if I can survive a day at a customer when I forgot to carry the charger with me I’m already happy).

    Besides that I consider the whole ‘Windows on ARM approach’ very interesting from a technical point of view (especially the binary translation attempt and how intelligently they made this all work so there’s almost no performance loss when executing standard win32 stuff) but I would never use such a device, since a) way too much hassles to work with Windows and b) this ‘Always connected PC’ concept being a nightmare.

    At the same time we learn how screwed up almost all Intel CPUs made in the last decade are (Intel’s exploit ridden ME) vendors start to sell ARM laptops that are even worse having a proprietary baseband processor on the mainboard so not even a cable is needed to hack in remotely.

  13. @tkaiser
    Well, I hear your always-connect concern, but what do you suggest — open-source baseband processors? Surely, there will be some one day, but until then no baseband? : )

    At the end of the day, the user’s dilemma is: do I value connectivity more or do I value security more?

    Somehow, I don’t think the windows users fall in the second category : ) And frankly, I too often don’t draw the line too deep in the sand — as long as my devices’ kernels and drivers don’t open gaping security holes, I’ve accepted the fact that the hw underneath has its own backdoors. If I could close those, I would, but if I could not then I’d not give up using that hw, because I usually have some work to do on that hw.

    TL; DR: hygiene is important, but one can’t avoid getting dirty doing work ; )

  14. I still think this is an utter nonsense. Running windows on arm is like running symbian on a phone right now. You have laptops with very long battery which can use windows without any issue. If you want to use it with your dev board ok, but if you need such expensive board to run it, and that will never change since it’s microsoft and their OS are resources hungry, then buy a x86 board.

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC