Microsoft Windows - Client Operating Systems - API unity

Why Microsoft needs three or more operating systems

Windows Phone 8.1 Rumors Emerge

   A common operating system core, with common APIs and capabilities, is inevitable, and it is logical. Microsoft might even start to use common branding, most likely with Windows Phone becoming just "Windows." But that doesn't mean that it won't actually have three operating systems. Windows on a phone will be different from Windows on a tablet—in much the same was as iOS on the iPhone is different from iOS on the iPad. The user interface will be tailored to the form factor, making the two close siblings but not identical.

This will result in Windows for ARM phones, Windows for ARM tablets, and Windows for x86/x64 PCs. One might even make a case for a fourth to be added into the mix: Windows for x86 phones.

More exotic is the Xbox One operating system. This has no branding of its own, as it's never decoupled from the Xbox One hardware

A completely different API? That’s a different OS !


The operating system that is meaningfully different is Windows Phone. Windows Phone 7 used Windows CE (Microsoft's lightweight, customizable, embedded operating system) as its kernel. At the time, Windows CE was Microsoft's only ARM-compatible operating system, and the company had considerable experience using it on smartphones (as it was also used in Windows Mobile). This seemed like a sensible decision. Third-party applications were built using a modified version of Silverlight with a .NET environment .


For Windows Phone 8, Microsoft wanted to use the NT kernel. The NT kernel is more capable and is where most of Microsoft's development effort is spent, so this made sense for the company (if not for end users). Since the development of Windows RT meant that the Windows software stack ran on ARM, there was no longer any reason to stick with Windows CE. Accordingly, Windows Phone 8 shares major parts with Windows 8, with low-level components such as the network stack and security infrastructure in common between the operating systems.

To support existing Windows Phone 7 apps, Windows Phone 8 included essentially the same Silverlight environment. New applications for Windows Phone 8, however, didn't use the Silverlight environment. They have a couple of options: a new .NET environment similar to the old Silverlight one (though this time built on the full .NET runtime and notably missing the XNA 3D graphics API that the Silverlight system supported) and native code C++ with Direct3D.

Significantly, Windows Phone apps can't use Windows' Win32 API. Nor can they use most of the new WinRT API.

Developers wanting to share code between their phone and tablet software aren't completely out of luck: it's possible to write .NET code that conforms to a common subset of functionality that's available on both Phone and regular Windows (producing what are called "Portable Class Libraries"). Windows Phone 8 also gives C++ developers access to a limited subset of the WinRT API (sometimes called WinPRT), and large parts of Direct3D. Sources speaking to Paul Thurrott claim that overall, there's about a 33 percent commonality between the phone and non-phone operating systems.

This makes Windows Phone 8 a strange orphan operating system. Windows Phone 8 has few APIs in common with either Windows or Windows RT, so while iOS and Android phone apps can also be used on iOS and Android tablets, Windows Phone apps are strictly for the phone alone !

Universal binaries : Microsoft is currently pushing the notion of universal binaries that would let developers create a single app that can run both on Windows RT and Windows Phone. Where Windows Phone 8 has 33 percent "API unity" with Windows RT, Windows Phone 8.1 will hit 77 percent.