'Android on Windows': Microsoft tightens noose around neck, climbs on chair

Surely they can't be that desperate ...

Build 2015 Microsoft’s annual developer conference Build kicks off later today, and rumours are swirling that Redmond has a bold plan to rescue Windows Phone from irrelevance. Aside from a modest 10 to 15 per cent share in some markets, the platform has gone nowhere, despite billions of dollars of support from Nokia and Microsoft.

The plan, allegedly, would allow WinPho to run Android binaries, much as BlackBerry allows in-place with a high degree of compatibility. This would be emergency treatment, akin to injecting adrenalin into the heart. It would also kill the patient.

Platforms live or die by developer support, and with its focus on emerging markets Windows Phone has struggled to stay upright. Some high profile apps have disappeared recently, although a prudent developer with limited resources would surely be waiting for Windows 10, rather than writing functionality twice.

Even where apps have Windows equivalents by name, the functionality of the Android or iOS version is far more sophisticated, such as with Evernote or Instagram.

The argument for providing Android compatibility is that it would immediately solve the Windows “app gap” – the single largest reason for new buyers returning a device to the store. Users could enjoy the slick, consistent Windows Phone UI but not lose out on an obscure app

Technically, getting it to work well and integrate it with the native platform well is still a considerable challenge. You can’t just fling an Android runtime in there – as BlackBerry once did – and hope for the best. Android extensions are Linux binaries. BlackBerry only cracked Android compatibility with a cunning hack, which we described here. As our mole explained:

We had to let the SWIs trigger live and discern whether it came from a Linux binary or a QNX binary at runtime, without sacrificing performance of QNX code… Our work used a wide, labour-intensive component: dynamic cross linking, validating and shimming of the Linux APIs on QNX, and a really deep and tricky hack: catching syscalls in apps that bypassed libs, or had libs statically linked… Linux and QNX used the same ARM SWI instruction, but passed the syscall number in different registers.

The result works incredibly well. Android alerts are channelled into the Hub, the phone’s unified persistent (and interactive) notifications list. BlackBerry today has tamed Android. But for how long? The runtime only supports KitKat today and future changes could make keeping up hard work. BlackBerry found that the most difficult apps to get compatible were deeply integrated into Google’s binary blob, like Instagram. Unless there’s a rapid and specific antitrust remedy, which is unlikely, Google is likely to continue to pull more and more functionality into Play Services, and other Google-only middleware.

Microsoft knows how hard it is to be behind and code against a moving target because it used the same tactics 20 years ago when it was trying to shrug off IBM. In 1992 Microsoft was the incumbent, with all the apps, and all the developer mindshare. In an attempt to popularise OS/2 IBM created a version that was a wrap-around for Windows. Rather like a snake trying to eat an alligator, the alligator opened its jaws wider and swallowed the snake. When the wrap-around OS/2 booted and found DOS and Windows were installed, it virtualised and hosted them. Sometimes the Windows apps ran even better inside their new host – but you could never be sure.

It was clever but it had catastrophic consequences for OS/2’s long-term application base. If Windows applications could run well enough inside OS/2, why bother developing an OS/2 version at all? Independent developers’ resources were better spent improving the Windows version. After a couple of years, Microsoft moved the goalposts again. IBM couldn’t keep up and threw in the towel.

Paul Thurrott calls Android compatibility a “suicide note”. It’s hard to disagree. ®