What is WinRT and how does it affect .NET?

Apparently there is fuss going on about what WinRT (Windows Runtime) is and how it affects .NET. I’m going to talk about that based on my understanding of WinRT.

WinRT, or the Windows Runtime, is theoretically the successor to Win32. It’s not a true runtime in the sense of a virtual machine like the CLR either. The term is used rather loosely. I also say theoretically, because it’s just another layer over Win32 written in native code and COM-based API. It doesn’t actually replace Win32. What it does do however, is expose Win32 to virtually any programming language through what are called language projections. I’ll get to that in a moment. Right now WinRT supports native C++, JavaScript and HTML, C#, Visual Basic, and probably C++/CLI. You’re probably wondering how this is possible, and even further how it is now possible for a CLR language to call directly into WinRT API’s when it is purely a native implementation.

WinRT can be summarized by the following.

  • Win32
  • Pure native implementation
  • Patterns and practices
  • Metadata
  • Language projections

Patterns and practices. Remember how many string types there are in C++? Remember how horrid the type names are? In WinRT, they used .NET practices for naming types and API’s.

Metadata. The WinRT team could have chosen anything for storing metadata, even just xml. Instead, they chose to use .NET metadata. .NET metadata isn’t specific to managed code, and it’s really just a specification and format for storing meta information. There’s no need to re-invent the wheel and create yet-another-metadata-format. Because they chose .NET metadata, the type information is easily exposed to a CLR language and the experience is seamless.

Language Projections. A language projection in WinRT is a subsystem that handles conversions from one language into something WinRT understands. For example, if you are calling into a WinRT API from C# that takes a special type of string that C# doesn’t know about, the language projection layer will do the conversion for you. You don’t even know that the conversion is taking place from the perspective of C#, which is what makes this experience seamless. Another example is IEnumerable<T> in .NET. WinRT doesn’t have an IEnumerable<T>, but it does have IIterable<T> which is basically the same thing. But they’re different interfaces, so the language projection does the conversion for you. This also allows you to seamlessly iterate over WinRT collections from a CLR language. Language projections are the magic of supporting virtually any language.

Now up to this point, I haven’t really said anything specific about .NET. WinRT itself is purely native, but a subset of the .NET base class library is integrated into WinRT. This is why WinRT right now lacks most of what .NET has to offer, and WinRT is not currently supported in desktop applications or console applications. So how does “Metro”, or now known as Windows 8 UI play into all of this? It’s just the UI layer available in WinRT. That’s it. Just like Windows Forms or WPF is a subset in .NET, Windows 8 UI is a subset in WinRT. WinRT is separate from .NET, and it needs some way to display an interface and right now that’s Windows 8 UI. Windows 8 UI is basically for developing Windows Store applications. I personally call these glorified cell-phone apps, because there is no backwards compatibility, period. Windows Store apps will not run on any operating system except Windows 8, and I believe Windows Phone 8.

How does this affect .NET? If you want my honest answer here it is. It doesn’t. Yet. One of the WinRT team’s fears is they hope they didn’t create a parallel platform, but in my view that will be the future result. I’m going to summarize why it doesn’t affect .NET now, and why it will in the future.

Effect Now

  • Isn’t accessible to desktop, console, or web applications.
  • Integrates only a subset of the .NET base class library, so in comparison it is very limited.
  • It completely breaks backwards compatibility with everything prior to Windows 8.
  • WinRT apps can only be distributed through the Windows App Store.
  • WinRT only allows a single app to be open at a time.
  • WinRT forces apps to run in a limited, isolated/sandboxed environment.

Right now it isn’t changing anything about .NET -at all-, but that can change very quickly in the future. I think the affect WinRT can have towards .NET in the future heavily relies on a few factors. One, if it is made available to desktop, console, and web applications. And two, how much Microsoft invests in developing libraries for WinRT. Let’s assume for a moment that WinRT is eventually made available to desktop applications. It already eliminates the need for platform invoking down to the Win32 layer, so it deprecates that part of .NET. It brings all languages, even non-CLR languages to an equal playing field, and this is a huge achievement. Those two points alone are very powerful, but I think the third point would be if they ever include a desktop UI layer in WinRT, or allow Windows Store Apps to run in the desktop. That would probably be the final question, because WPF for example is huge, and managed. It would be a large undertaking to integrate that into WinRT.

I’m not sure what’s going to happen from here, but it can go in some very interesting directions. With the drastic change Microsoft made to the Windows desktop by removing the start button and implementing this new Windows 8 UI Start Screen, and with Windows Store apps, who knows what will change in the future.

Comments for this article (19)

  • Order your Bitcoin mining equipment today and we will certainly deliver it within 2 days. See % POSTDOMAIN %.

  • vicieuse says:

    Јe terminerai dе jeter un coup d’oeil à ça dans la journée

  • Johne692 says:

    Merely a smiling visitor here to share the love , btw outstanding style. Audacity, a lot more audacity and always audacity. by Georges Jacques Danton. bbeeaaadcdgd

  • Jitendra says:

    Dear All,
    I am doing some WebView once I am navigate particular page I am not able to get any JavaScript value..
    needs to make some changes or is there any way where we can find this value
    I mean in iOS they have some “NativeBridge” so that they can able to get value so same into Windows Surface how I can get this value..
    I had many tried with google and all the event but there is no clue..

    Thank you,
    -Jitendra Jadav.

  • Sheyam says:

    nice post…i would like to find something about choosing a platform for new developers.

  • Stuart says:

    I have been ‘away’ from desktop developing for a while now – distracted by web stuff – so last time I truly developed for a windows environment is was .NET 2.0 WinForms.

    I have kept up with goings on – but have rather alarmingly read a variety of blogs etc that continue to claim the end of WPF is nigh…something I feel is rubbish, but there is usual some truth in these claims.

    I now face the need to develop a new windows application – but what shoulod I use to develop it in? My feeling it use WPF – it is going to be around for a long time yet and it is still the latest way of creating application that are not limited to Windows 8.

    The consumers of this application will in the main be enterprise clients – so these people won’t have Window 8 for a while yet, but even if they did sticking to WPF will still work within the desktop on Windows 8 anyway. I cannot see (right now) how I could choose to use WinRT for this new development right now – but I also don’t want to expend a lot of effort developing something in WPF only to find it is unsupported not long from now.

    I suppose I am looking for an opinion on “you need to develop an windows application that will be a considerable undertaking” – what would you right it in?

    Personally, my feeling is WPF is still the way to go and my hope is that if I stick to a solid MVVM pattern maybe I could skin it as a WinRT app in the future – but I am still uncertain to what degree the underlying .NET model (within my MVVM) will work within WinRT…as whilst it (WinRT) supports C# but it isn’t actually .NET.

    • I recommend using WPF. Windows Store Applications development (WinRT) uses Xaml as well, so the MVVM pattern still applies. You can also develop core parts of your code into Portable Class Libraries, which means that code will be reusable for any platform (WinRT, Windows, Web, Xbox even), but even this might not be necessary for you. Remember that Windows Store Applications do not run on anything except for Windows 8, so it is an extremely limited environment (right now), and you are also limited on API’s and security. I would sit down with your team and take a good look at your requirements and see which technology fits them best, but it sounds like WPF is the way to go for you, and you won’t be limited. Windows Forms are still very relevant today, so I think WPF will be for a good long while, and even if something changes down the road, I don’t really see Xaml going anywhere any time soon.

  • Mark says:

    I am looking for explanations of the WinRT and in particular, the subset of the .NET framework that it includes and this article provided me with a good starting point. It is a pity however, that you make your bias so obvious by calling Windows Store applications “glorified cell-phone apps” – a more objective approach would be more useful for information seekers like myself.

  • Raghav says:

    Very nice!!.. thanks for sharing.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>