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.