Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

Analysis The Windows Phone 8 SDK emerged at the Microsoft’s BUILD conference in Seattle last month. After so much hope, hype and promise, what’s new for developers?

A lot, as you would expect given that this version of Windows Phone is built on the same core as Windows 8, whereas the 7.x line is built on Windows CE. At the same time, Microsoft has yet to do the obvious thing: unify the Windows 8 “don’t-call-it-Metro” runtime with what is provided for Windows Phone 8, though it is closer than it was before.

The reason seems to be compatibility. There are about 120,000 Windows Phone 7.x apps in Windows Phone Store, according to Microsoft. It would be a disaster if Windows Phone 8 was incapable of running those existing apps. Microsoft also had to keep the Silverlight-based XAML - Microsoft’s XML-based language for defining a user interface – rather than replacing it with the native code XAML used by Windows 8, although the Silverlight name is no longer spoken.

Windows Phone 8 also still supports XNA, a means of developing games with .NET code, although this is no longer the recommended path for games development, and Visual Studio will not let you create an XNA project targeting Windows Phone 8. Developers like XNA, so why not? The reasons may be to do with Microsoft’s internal politics rather than technology. The Windows team is focussed on native code and DirectX more than .NET.

There is a fudge though. The new SDK fully supports creating an XNA project targeting Windows Phone 7.1, which will run fine on Windows Phone 8. There are even ways, through .NET Reflection, to get to Phone 8 specific APIs in such a project.

If Windows Phone is tied to Silverlight-style XAML, and Windows 8 to native XAML, how will convergence ever come to the two platforms? Microsoft will not say, but here is a clue. It would be good, I observed to Microsoft’s Larry Lieberman, who was running the Windows Phone track at BUILD, if you could run Windows Phone apps on Windows RT and devices like Surface RT. “We could not do everything at once. You are not the first person to make that suggestion,” Lieberman said.

It seems plausible, therefore, that at some future date the Phone 8 XAML stack might come to Windows 8 to run Phone apps. Perhaps the reverse may come as well, so that Windows Phone can support both stacks.

Native code project options include Windows Runtime extensions

Despite these issues, there is already some degree of convergence. The Phone 8 platform includes the Windows Phone Runtime that is accessed using .NET metadata as in the Windows Runtime. You can also create new Windows Phone Runtime components using Visual C++. This is significant, since this lets you extend .NET code with native code. COM interop and Platform Invoke, which you may use in desktop Windows, do not work on Windows Phone.

In Windows Phone 7.x, of course, you could not use native code at all unless you were Microsoft, or an operator or manufacturer. Now there is a range of native code application types, including Direct3D, Direct3D with XAML, and static or dynamically linked libraries.

There is no support in Windows Phone 8 for WinJS, the projection of the Windows Runtime to JavaScript used for HTML apps in Windows 8. However there is a new HTML5 app type, which uses embedded Internet Explorer 10 in a XAML page. There is some access to Phone APIs through the InvokeScript JavaScript method.

Windows Phone 7 included a version of the Compact Framework for its .NET runtime. In Windows Phone 8, this is replaced by a new version of the CoreCLR, which was first developed for Silverlight on the desktop. This version includes the asynchronous programming model introduced in C# 5.0. Microsoft also claims that startup times are up to twice as fast for .NET apps.

Agentless Backup is Not a Myth

Next page: Confused? You will be: let's talk on-demand compilation in the cloud