Build day 2: WinRT and managed languages

I must preface this post. There are more than 10 concurrent sessions in each slot, and obviously I’ve only seen one in each session. I also picked my sessions based on my perspective as a .NET / C# developer.

I’m actually very pleased with what I saw today about the WinRT APIs and the C# language.

Windows RT: A Modern Windows API

Let’s start at the WinRT layer. Currently, the base Windows API is Win32. That API dates back to 1995. In fact, the Win32 API was based on and consistent with the Win 16 API, which means its design is even older. Its design dates back to a day when C++ (and other object oriented languages) were not very popular. It also dates back to a time when the concept of having a computer attached to the internet whenever it was on was unthinkable. It’s also an API that has grown considerably over the last decade and a half. New features and capabilities have been added with each successive release of Windows.

The Windows Runtime (WinRT) represents a redesign of the entire API surface for windows. Throughout the day, I heard three phrases repeated from presenters discussing this new API:

  • decreased surface area
  • consistent view of the system across languages
  • Consistent guidelines for API across all Windows functions
  • A modern object oriented API

I believe the WinRT team redesigned the Windows API from first principles, and created a modern API for the Windows system. It should be easier to use, and simpler for developers to understand.

Accessible from many languages

The next layer up has some very interesting engineering capabilities. Most importantly, the new WinRT layer provides a projection of its API to managed languages. That’s critically important because it addresses a long-standing frustration for managed language developers: New OS features would be released, and those new new features were not accessible from the managed languages without developers creating their own managed wrappers on top of the new native APIs. With Windows 8 and WinRT, managed developers will see new features in projections for their language as soon as those features are available in the OS release. That lag between OS feature and its presence in the managed APIs should go away in this next release. Note these new features will also be immediately surfaced in javascript as well.

That means languages such as C# and VB.NET will immediately have access in their own natural syntax to any new features available in the OS.

In addition, the next version of the C# compiler (and the VB.NET compiler) can produce WinRT components. The projection infrastructure is already there, and if you desire, you can expose your current class libraries (almost certainly after some work to make them conform to WinRT standards). C# is a first class language for WinRT development, just like C++.

The costs

Of course, nothing is free. If you want to participate in this new world, you must conform to the new WinRT standards, and possible leverage newer capabilities, and replace some code.

Some of the .NET APIs are changing for WinRT. I don’t have an exhaustive list, and I’m not sure there is one yet. Other APIs are not exposed via WinRT. (They are still available as .net APIs, just not as Metro / WinRT APIs.)

In the build we got, .NET apps will run in the classic Win7 desktop. It appears that all class libraries (that don’t rely on the Win32 APIs) will run in either environment. I’m not sure about that.

In Metro, the CLR runs on top of the WinRT layer. Just like today, where the CLR runs on top of the Win32 layer. There’s really not a lot of painful change here.  Think about how thrilled you would be if you could write C# code that ran on other devices (like the iOS or droid platforms). if you think of WinRT that way, this makes sense: C# runs on both the win32 stack, and the new WInRT stack.

Some Q & A

caveats: I’m still trying to figure this out myself, and I’m sure I’ve got some of this wrong. It represents my current understanding:

Are .NET applications legacy applications?

Well, sort of. The Metro UI is a different UI paradigm. If your using the current Win32 controls (which includes WPF controls), your application will look really dated in Metro. The only way to fix that is to re-implement the UI (your View classes in an MVVM design) using Metro controls. However, C# and majority of the .NET APIs are first class citizens in this new environment. The rest of your application should be fine.

caveat: WinRT has new network APIs and File System APIs. You may also have to change some logic at your persistence layer.

Is .NET Dead?

As a marketing brand, probably. However, C#, VB, F# and other managed languages are continuing just as strong as before.

Why is HTML5/Javascript and C++ getting so much more attention?

I think that’s just because there’s a bigger story there. C++ has a new standard (C++, The Spinal Tap Edition: It goes to 11). And the tools for building modern windows applications with either C++ or Javascript have gotten much better.

It’s a good story for the platform. C# apps are as well supported as before. It’s just not as interesting of a story.

What about the future of the current Windows Desktop?

I don’t know. I’ve only had the build tablet for a day, and it’s a different experience. It’s pleasant for many tasks, but for others, I prefer a keyboard and the classic desktop. That may change as time goes on. And that will have a great bearing on how this evolves in the future.

My guess:  “desktop” apps will run fullscreen in a private ‘virtual desktop’ in the future.

Recommendations

You should recognize that the Metro UI represents a rather large sea change in what makes a great application in Windows. If you ignore it, your applications will start looking dated.

However, this doesn’t mean you should rewrite your applications in WinRT. At least not yet. However, I would think carefully about what your application would look like in Metro. Is there a great Metro experience for your app? If so, start that migration.

Of course, some standard recommendations still apply: If you separate the layers of your application, it will be much easier to preserve large parts of your application as it moves to Metro. Regardless of your plans moving forward, that would be a good practice.

We do live in interesting times.

Created: 9/15/2011 4:38:44 PM

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.