At its Build developer conference last week, Microsoft made a pair of announcements about Windows development that were more than a little surprising: Windows will support applications developed for iOS and Android.
This immediately felt like a dangerous move. Windows will not be the first operating system to run foreign applications. Famously, IBM advertised OS/2 as a "Better Windows than Windows" in the 1990s, boasting that its platform would run all your existing Windows applications with greater stability and performance. More recently, BlackBerry 10 included support for Android applications, with BlackBerry licensing the Amazon App Store and using it as its gateway to a world of Android-compatible software.Neither OS/2 nor BlackBerry 10 has made a success of this capability. There are two major problems with supporting foreign applications on a niche platform. The first is straightforward: it removes any incentive for developers to bother with the native platform. Investing in developing for a minor platform is already something of a gamble, and by telling developers "Oh hey, you can just use your existing Win16 or Android program..." as IBM and BlackBerry (respectively) did, you're implicitly sending them a message. "Don't bother learning our platform or writing native apps for it."
It turned out as expected for both platforms. While a few true OS/2 applications were created—and similarly there are some true BlackBerry 10 apps—they're relatively unusual. After all, what's the point? If IBM is going to boast about just how well OS/2 will run Win16 apps and those Win16 apps can be sold both to OS/2 users and to Windows 3.1 users, why would a developer write anything other than a Win16 app?
This capability cedes a lot of control. By being dependent on apps developed for a third-party platform, you give the owner of that third-party platform the power to choose how to evolve its APIs and add new features. This bit OS/2 hard: while IBM was busy promoting how well OS/2 could run 16-bit Windows applications, Microsoft was busy encouraging developers to create new 32-bit Windows applications and end-users to buy the 32-bit capable Windows 95. This new world of 32-bit software wouldn't run on OS/2, and so the big OS/2 feature that IBM heavily marketed was rendered semi-useless. OS/2 found some niche success, but it was ultimately a failure.
Supporting Android apps creates similar risks. If Android software constitutes a major part of a platform's software ecosystem, any changes to Android (new APIs or capabilities, say) that Android software expects to be able to take advantage of have to be replicated. This is, however, tempered by Android's uniquely poor update situation. Most Android phones don't have access to the latest and greatest version of Android or the latest and greatest Android features, so most Android software has to refrain from demanding such capabilities. This means an Android-compatible platform could trail Google's cutting edge by a year or more and still be highly compatible with Android apps.
This is less true of iOS. A platform striving for compatibility with iOS will have to aggressively keep pace with Apple's developments, because Apple's developer community demands nothing less.
These concerns are why the idea of Android apps on Windows was met with what can at best be described as confusion when it was first rumored last year. It seemed like Microsoft was simply preparing to make the same mistakes others had made before, one last-ditch effort to prop up its phone platform.
The way Microsoft presented the Android and iOS support on stage last week wasn't particularly encouraging. The way that Projects Astoria and Islandwood—the codenames for Android and iOS app support, respectively—were promoted in the keynote presentation, one might think that the Android and iOS support were pretty solid substitutes for the Universal Windows Apps that are native to Windows 10 on all the hardware form factors it will support. It seemed like porting apps from those platforms would be an effective alternative to any plans to develop native Windows applications.
The risk that Astoria and Islandwood will further diminish native Windows development is certainly real. The repercussions of this support could be every bit equivalent to IBM making OS/2 compatible with Win16 software, or BlackBerry 10 promoting the Amazon App Store. But the situations are not completely equivalent. While it's certainly not certainty, one can see how things might turn out differently for Microsoft than they did for IBM and BlackBerry.
Inside Astoria
Astoria and Islandwood are superficially similar, but their underlying technology and implementation is very different. For developers, Astoria is probably the more straightforward. Windows has long included the ability to support multiple API families through a feature called subsystems. The Win32 API that almost all Windows software (including Universal Windows apps) use is obviously the biggest and best known of these APIs, and in modern versions of Windows is in fact the only API. But historically, there have been others. The very first versions of Windows NT included, of all things, an OS/2 subsystem that supported certain kinds of OS/2 applications. It was a relic of history, a product of Microsoft and IBM's once cooperative operating system development.
Windows also included a POSIX subsystem. POSIX is the IEEE-standardized API that essentially defines the Unix API. Operating systems such as Solaris, Linux, OS X, and AIX all implement POSIX or some close approximation thereof. Windows NT included POSIX support because US government regulations at one time required it. Unlike the OS/2 subsystem, the POSIX subsystem was maintained and even expanded for many years, first by third parties (Interix) and later by Microsoft. The Interix tools were bought by Redmond and variously rebranded as Services For UNIX (SFU) and the Subsystem for UNIX Applications (SUA).
The OS/2 subsystem was dropped in Windows 2000. The POSIX subsystem was an optional Windows component as recently as Windows 7, though it isn't supported in Windows 8. However, the underlying operating system components to support subsystems are still there and still functional, and Project Astoria takes advantage of this. It introduces a new Windows subsystem: the Android subsystem.
The Android subsystem implements a subset of Android's APIs on Windows. This subsystem offers Android-style APIs for things like filesystem access, graphics, access to sensors and the camera, process and thread creation, security, and networking, leveraging the Windows kernel to provide these core services.
The specific set of supported APIs hasn't been published or finalized yet, but it's likely to be a mix of three things, reflecting the way Android is built. Android has a Linux kernel and a handful of open source native libraries that native code apps can use, a set of open source Java APIs that Java apps use, and another set of proprietary Java APIs that tie in to Google services, collectively known as Google Mobile Services (GMS). The first two of these are included in AOSP, the Android Open Source Project. The third is not.
For the open source parts, Microsoft can, in principle, use the open source code in its implementation, presenting apps the same Java APIs that they expect, but redirecting to Windows services as appropriate. The Android sharing API, for example, can be plumbed in to Windows' sharing system. For GMS, using the source isn't an option. Instead, Redmond has produced workalikes for at least some of the GMS APIs. For example, GMS includes APIs for in-app purchases and location services, and Microsoft has developed counterparts backed by its own services.
The new subsystem will be a preinstalled, built-in part of Windows Mobile, the new (and very old) name used for the Windows version that runs on phones and small screen tablets. It's only for ARM processors. Other versions of Windows won't include it.
The developer experience for Astoria is very similar to the regular Android developer experience. Devs will continue to use Android development environments, such as Eclipse or IntelliJ, and they will continue to produce Android app packages: APK files.
Apps that use only the subset of AOSP APIs that the subsystem supports will not, in principle, need any changes. In fact, the existing APK that's already distributed to Android users should work without requiring any recompilation or modification at all. Apps that use GMS APIs will need some changes so that they reference Microsoft's workalikes instead of Google's code.
Microsoft is also offering some Windows-specific APIs to give Android apps access to features such as Live Tiles. Naturally, developers will need to make code changes to take advantage of these APIs. These are limited, though, and Android apps won't have full access to all the underlying Windows capabilities.
Microsoft won't be going the BlackBerry route of supporting the Amazon App Store on Windows. Instead, Android developers will have to submit their APKs to the Windows store. The store will verify that they don't use any unsupported APIs and then wrap the APK in a Windows AppX package.
reader comments
244