As spotted by Paul Thurrott, Microsoft briefly published a document that enumerated the major differences between Windows 10 for ARM processors and Windows 10 for x86 chips. Though the document has now been removed, a cached copy is still available, and the original source is still found on Microsoft's documentation GitHub repository.

Many of the differences are predictable consequences of the different architecture. Windows 10 for ARM is a 64-bit ARM operating system. It can natively run both 32-bit and 64-bit ARM applications (though the SDK for the latter is currently, and temporarily, incomplete). As such, drivers for the operating system need to be 64-bit ARM drivers; existing 32- and 64-bit x86 drivers won't work.

This isn't a surprise; 64-bit x86 Windows can't use 32-bit drivers, either, even though 64-bit Windows can generally run 32-bit applications without even requiring any kind of emulation. This will mean that ARM Windows has limited hardware support relative to x86. It will also pose a problem for some games that use drivers for their copy protection.

Similarly, applications that use shell extensions—for example, software like Dropbox, which shows little overlay icons in Explorer windows to indicate the synchronization status of cloud-hosted files—must be compiled as 64-bit ARM software. These extensions work by having the operating system load third-party libraries, and since the operating system is 64-bit ARM, those third-party libraries must match. This will also strike input method editors, assistive technology, and similar software.

The document confirms, as previously disclosed, that the x86 emulation only works for 32-bit applications. The emulator is a derivative of Connectix Virtual PC, an x86-on-PowerPC emulator that Microsoft acquired from Connectix in 2003. Virtual PC only handled 32-bit software (because at the time, 64-bit x86 was in its infancy), and, while the software has obviously been updated in the intervening years, this basic limitation has been retained.

Again, as previously disclosed, Windows on ARM will not include Hyper-V virtualization. Although ARM hardware includes hardware virtualization capabilities, and although Microsoft is starting to use virtualization to provide certain security features, apparently, the company has not ported its Hyper-V software to work with ARM processors. With continued interest in running ARM on servers (a scenario where virtualization is surely essential), we would be surprised if this gap is never filled. But to start with, at least, there's no virtualization support.

The final functional gap is OpenGL. Windows only has built-in support for OpenGL 1.1. Support for any newer version of OpenGL is provided not by Windows itself but by the graphics drivers from Intel, Nvidia, and AMD. The Qualcomm GPU supported in Windows on ARM, by contrast, does not include any OpenGL support. As such, any 3D software, including games, must use Direct3D 9, 10, 11, or 12.

It's not clear if this deficiency is a short-term reflection of the immaturity of the display drivers on the platform or a long-term deliberate decision by Microsoft. Qualcomm's hardware does support OpenGL, and Qualcomm has written OpenGL drivers for Android systems, so there shouldn't be any fundamental difficulty in supporting the 3D graphics API on Windows on ARM should Qualcomm want to do the work to port its drivers to Windows. But it's possible that Microsoft would prefer that this doesn't happen, leaving Windows on ARM as a strictly DirectX-only platform.