Microsoft published a webpage listing Windows 10's "limitations of apps and experiences on Arm," earlier this month – and then mysteriously pulled it.
The document appeared at
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-limitations last on Thursday, February 15. It now redirects to
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-troubleshooting-x86, which is missing some of the previously revealed restrictions.
The page's disappearing act gave us a glimpse of the limitations in Microsoft's Windows 10 port to Arm-compatible processors, and it comes as a bunch of Windows 10 laptops powered by Qualcomm's Arm-based Snapdragon chipset are due to hit the shelves.
The previous Windows-on-Arm effort, Windows RT, was a swiftly axed clusterfsck with a lot of restrictions. That operating system was based on Windows 8 and could only run programs built for the Arm architecture. And there were, essentially, sod all.
Perhaps Redmond is happy to now say those restrictions are disappearing with its Windows 10 port, which runs 32-bit x86 applications under emulation on Arm CPU cores.
However, there still are various limitations in place, it appears.
The now-edited document warned that 64-bit x86 – aka x64 – apps won't work on Windows-on-Arm, that x86 drivers will need to be rewritten for Arm, and that games and other applications reliant on either OpenGL version later than 1.1 or hardware-accelerated OpenGL will struggle.
Microsoft also stated that "apps that customize the Windows experience may not work correctly." This includes some cloud storage apps that tie into the file system explorer, according to Redmond:
Native OS components cannot load non-native components. Examples of apps that commonly do this include some input method editors (IMEs), assistive technologies, and cloud storage apps. IMEs and assistive technologies often to hook into the input stack for much of their app functionality. Cloud storage apps commonly use shell extensions (for example, icons in Explorer and additions to right-click menus); their shell extensions may fail, and if the failure is not handled gracefully, the app itself may not work at all.
Also revealed, then deleted, is the warning that "apps that assume that all Arm-based devices are running a mobile version of Windows may not work correctly." Such apps "may appear in the wrong orientation, present unexpected UI layout or rendering, or failing to start altogether when they attempt to invoke mobile-only APIs without first testing the contract availability."
Also, we were briefly told, "the Windows Hypervisor Platform [Hyper-V] is not supported on Arm."
We've asked Microsoft to explain the changes. The company's email-for-media service responded with the automated message "Due to the holiday, we will resume normal office hours on Tuesday, January 2 at 7:30 am." We hope to have a response rather sooner than early 2024, the next time January 2nd is a Tuesday. We're also guessing that the "holiday" in question is President's Day, rather than the Christmas/New Year period. Either that or Microsoft's PR strategy just changed, big-time. ®