Windows Phone 8: Introduction to the Platform

After a sneek peak at Windows Phone 8 back in June, followed by a private developer preview program in September, this year's BUILD conference was accompanied by the long awaited public access to the SDK for Windows Phone 8, just a few weeks ago. Since that time, first devices from Nokia and HTC also have started to show up in the wild and are available in stock on several markets now.

The New Old Platform

When we talk about Windows Phone 8 and people ask what has changed, the true albeit confusing answer should be something like: "everything and nothing". Why is that? Well obviously we can read everywhere about all the shiny features those new devices have to offer that we didn't have in Windows Phone 7. But the sheer endless list doesn't stop at hardware gimmicks. Also, the newly offered possibilities for us developers are countless, and if you dig deeper to inspect the technical foundation and details – which we absolutely will – you can see that there have been additional, tremendous changes under the hood too. So why would anybody say nothing has changed? Because despite all of those really fundamental changes of the platform itself that were introduced, Microsoft has taken an enormous amount of effort to ensure that for the almost 120,000 applications in the Marketplace, everything continues to work as expected without compatibility issues, and without the need for developers to change their applications for the new system – until they want to make use of the new features of course. To understand how amazing this accomplishment actually is, we first have to dive into the platform details of Windows Phone a bit.

Windows Phone 7 is based on the Windows CE kernel, a technology that has been around for 15 years now, and that has been the basis for predecessor platforms like Windows Mobile too. If that makes it sound bad, please stand corrected. A great variety of devices and corresponding software is build on top of this platform, many of which you wouldn't even recognize from the outside, like various cable/IPTV receivers. Over the years I've done quite some work with the platform in other areas like robotics and device controlling too. Officially Windows Phone 7 was based on the then up to date version 6 of Windows CE, albeit with significant features and new functionality added to the system to support the requirements of the new phone platform, and which allegedly have been adopted back into the next iteration of Windows CE [1]. This technical foundation most likely is one of the reasons Windows Phone 7 hardware was limited to a certain degree and couldn't adopt modern or even expected features of devices running on top of other platforms. For example, multi-core support was only officially added to Windows CE in 2011.

What has changed in Windows Phone 8 regarding this operating system platform? With the release of Windows 8 Microsoft has already created one single operating system that is supposed to serve a great variety of hardware scenarios and platforms: from stationary desktop computers to very lean tablets that run on limited resources. It's only a logical desire to integrate even more platforms and in particular try to unify Windows Phone and tablet/desktop development also. This not only helps to limit the number of seperate systems to support on Microsoft's end; it supposedly also makes it easier for you as a developer to exchange code between those platforms as well. Therefore, Windows Phone 8 will be powered by the same underlying operating system kernel as all the other platforms: the NT kernel, which is the technology that powers all current operating systems by Microsoft, like Windows 7/8 and their server operating systems counterparts. Take a look at the revised (and simplified) chart for Windows Phone 8 below:

Let's focus on the lower part first: as you can see, the whole foundation of the system has been swapped and is now based on the Windows 8 kernel. We can also see in the upper parts that the number of exposed APIs and available programming models have been increased. In addition to native code a version of the Windows Runtime (WinRT) also has found its way onto the phone.

Does this mean we are running Windows 8 (for example Windows RT) on the phone now? No [2]. It means that the core technology like the low level operating system functions, driver models and so on are now shared between the Windows Phone and Windows systems, and that we have a shared amount of APIs that are similar on both systems. But it's not an interchangeable setup or even the completely same operating system. For example, Windows Phone 8 offers only a subset of APIs taken from the full Windows Runtime, and it also extends these APIs by additional features unique to the phone. A schematic diagram looks like this [also see 3]:

Of the original 11,000 members of the Windows Runtime on Windows 8, a shared subset of approximately 2,800 members has been defined that is also available on the phone. In addition, about 600 members have been added to the phone version of the Windows Runtime that are not available on Windows 8, for example to support speech recognition.

A quick start poster is available in PDF format [4] that gives you an overview of the available APIs on the phone, be it managed, native or Windows Runtime. It denotes all the overlaps with Windows 8 to give you an idea what features are shared between both platforms.

Backward Compatibility

One of the strengths of Microsoft always has been that introductions of new systems mostly were evolutionary. That means, instead of creating a completely new system that is incapable of running old applications, there's always a huge amount of consideration that goes into maintaining backward compatibility. For example, Stuart Miles proudly emphasized in the above quoted interview [2] that Visicalc 1.0 (an application from 1981) still runs on Windows 8 (Pro) tablets. For a platform like Windows Phone which – despite the fact that it has been publically around since 2010 – still is considered a newcomer on the market, backward compatibility is more important than ever. You don't want to alienate all of your early adopters and loyal customer by presenting an update to your "just" released new mobile platform that breaks all existing applications (that people also potentially spent a lot of money on), do you?

So a lot of thinking and testing went into ensuring that all of the 120,000 apps in the Marketplace today continue to work on the new system and devices just like before. To this end, a "quirks mode" has been introduced that handles existing 7.x apps on the new devices. If you're familiar with web development you know that the term "quirks mode" there refers to a browser's capability of running web sites that are not standards compliant in a backward compatibility code path that ensures they still work as expected even if they are considered broken by modern measures. On Windows Phone 8, a similar concept is used to emulate a version 7 environment for applications which expect it. This means that either the original code of Windows Phone 7 is executed (so it's still present in the current code base in addition to newer code paths), or that the new code behaves in a way to mimic the old behavior of Windows Phone 7 even when the implementation of a particular detail has changed in Windows Phone 8.

If you want to get some more first-hand information on that topic and the testing that was done to make this work, one source is the talk Stefan Wick gave at this year's Build conference where he also covers Windows Phone 8's quirks mode [5]. As a result of this mechanism, the vast majority of apps available today should run and behave the same on new Windows Phone 8 devices, even with those dramatic changes under the hood, and without the requirement that developers recompile and resubmit their apps for the new platform. So for a Windows Phone 7.x app, the new version of the system seemingly really hasn't changed at all ;).

Of course no matter how hard you try, when you swap such a huge part of the runtime environment and code base for something completely different, there are going to be glitches and incompatibilities that you cannot handle even by the thoroughest considerations, or they simply would take an amount of effort to implement that's not justified, for example because there's only a theoretical chance existing apps are actually affected by a change. Therefore it's of course a great idea to test your existing 7.x app on Windows Phone 8 devices for compatibility, and to take a look at the documentation "App platform compatibility for Windows Phone" [6] that has been released a few days ago. It contains a rather long list of breaking changes, but if you read through that list you'll find that a lot of them are only of theoretical nature, for example when limits have been eased or existing behavior has been made more robust – those should never affect existing apps in practice as it would mean that the code in question would fail on 7.x devices too. However, some of the details described there are indeed things to consider and to check against your own apps. For example, multi-threaded apps inherently still only ran on one single physical core on Windows Phone 7, which made typical threading errors much less likely to surface in practice. On Windows Phone 8, not only do we have real multi-core CPUs but the compiler also does more optimization and may produce different results in this area, for example when accessing instance fields. Therefore, having correct and robust multi-threading code becomes more important for 7.x apps when they execute on Windows Phone 8.

Retarget to Windows Phone 8

The above mentioned quirks mode is nothing you are able to configure for your app. It's a decision that the runtime makes for you automatically. As soon as you take your existing 7.x code base and retarget for Windows Phone 8, quirks mode no longer is applied. The technical process of doing this retargeting is simple and even offered as a separate option when you right-click on a Windows Phone 7 project in Visual Studio 2012 (it can also be accessed on the project properties page where you naturally would expect it):

The implications of this however are that your application now executes on the normal runtime, which potentially introduces changed behavior of existing APIs that also may affect your application. You may even experience bugs with your newly compiled app even if it did run correctly on 8.0 devices when it still was built as 7.x app (again: no quirks mode anymore after recompile). Therefore, you should plan additional time for thorough testing of your app after you retarget it for Windows Phone 8. One thing to note is the behavior of referenced assemblies in your application, something that is also mentioned when you execute the above shown upgrade menu item:

So, referenced projects are not upgraded automatically. This hints at the fact that you can indeed create an app that targets Windows Phone 8 and still references and consumes assembies that target the old version of 7.x. More information can be found on the site linked to in the dialog [7].

Summary

As you can see, the fact that Windows Phone is updated to a new major version with this release isn't merely a marketing gag or solely driven by the great amount of new features that are visible to the consumer. The underlying changes of the platform itself are most extensive and also very much affect how we developers are able to work with and use the platform features – something that we of course will see in the upcoming parts of the series in more detail. I hope you enjoyed this first part, and as always I encourage you to provide feedback either in the comments below or by contacting me directly.