Developing for WinRT and Windows8 – Basic Concepts

By Anoop Madhusudanan

Vote on HN

image I gave a bullet point overview about Build conference here in my last past. If you havn’t yet got Windows 8 Dev Preview up and running, go grab it here. There are several ways to get up and running with Windows 8.

In my case, I downloaded the ISO image of Developer preview with tools (the 4+ GB One), Extracted it to a USB drive and made the USB drive bootable, Booted from that and then installed Windows 8 on a Local HD Partition in my home machine. Now, it is dual bootable, Windows 8 and Windows 7, and all is well.

Let us get in to the business. Windows 8 comes with WinRT, a new object oriented native/unmanaged API for developing ‘Metro’ applications for Windows. WinRT APIs are expected to replace the Win32 APIs. WinRT projects types using meta data, and is fully object oriented, so you can access WinRT directly from managed languages like C#. Here are a couple of interesting reads about WinRT.

WinRT is going to the ‘the runtime’ for Windows, across multiple devices like PCs, Tablets etc. You can develop Windows Metro style applications on top of WinRT in


1 - C#/VB.NET and Xaml

    • Xaml libraries with WinRT are now re-written in C++, and don’t have any .NET dependencies
    • WinRT XAML is a subset of the earlier XAML libraries that was available with .NET, and doesn’t support some features like DataTriggers etc as of now
    • Presently, you can access only a subset of the .NET BCL/Runtime from your C#/VB.NET + XAML WinRT application.
      • This doesn’t even support .NET Client Profile, it is just .NET core profile with access to a minimum set of .NET namespaces, combined with XAML namespaces now in Windows.UI.
      • The entire CLR will be loaded at the time of execution, but you’ll be able to access only a subset of that. As simple as that. This is to ensure that you are running in a sandboxed environment, and CLR comes into play as a thin layer only for binding your calls to WinRT at run time. As WinRT is object oriented and has managed data, you are any way developing directly against WinRT

2 - C++ and XAML

    • If you are developing in C++ and XAML, your code will be compiled directly to an unmanaged library.
    • I assume this provides the maximum performance advantage, as your code is directly compiled to native code.

3 - Javascript + HTML5

    • From Javascript, you can call WinRT methods directly and in that sense it is native. The UI is rendered in HTML5. If your application is a Javascript + HTML5 application, it will be run in a ‘shell’ which uses the same rendering engine in IE10.

You may continue to develop .NET/C#/Silverlight applications for classic desktop scenarios, but if you need to develop Metro applications, then you have to develop against WinRT.

Other than the XAML UI services, Win RT also Provides APIs for

  • Communication – Sockets, Streams and all
  • Devices – Geolocation, Sensors, Near Field Communication etc
  • Media – Playback, Capture, Effects
  • Other OS Services – Application services, Threading, Memory Management, Authentication etc.
© 2012. All Rights Reserved.