Microsoft Windows 8, Metro, and WinRT: A New Era for Microsoft Platform Developers

Microsoft Windows 8, Metro, and WinRT: A New Era for Microsoft Platform Developers

Windows 8 expands .NET developers' world to encompass the Metro UI, WinRT, and HTML5

The Microsoft BUILD conference of September 2011 has come and gone, and a new era of software development on the Microsoft platform has begun. It is fair to say that we are at the end of the decade of .NET and ushering in the era of Windows Runtime (WinRT). The change is exciting because WinRT is cool and powerful; the change is also scary because WinRT is new. Let me just say right up front that there is absolutely a place for .NET in this new era -- more on that point later.

And let me also set expectations right up front that this is not a "how-to" article by any stretch, nor is it designed to be. This article is intended to arm you with the strategic information you need to make informed decisions about the tools, plumbing, and platforms you will be building software on and with for the next many years on the Microsoft platform.

Sure, the secrecy leading up to the BUILD event helped generate the excitement. And we now know the rumors of .NET's death were exaggerated. I believe the WinRT announcement and its functionality described at the BUILD event are as significant as when .NET was announced in 2001. Only time will tell if I am right.

But First, A Bit About Metro

Bear with me if by the time you read this you are already "Metro'd to death." It's important to describe what Metro is because Microsoft is betting the farm on it. To me, Metro is a user interface (UI) made up of large tiles. It is designed specifically for touch, but it works just fine with a mouse and keyboard.

Metro was first fully unveiled on Windows Phone 7. But you can see glimpses of Metro in bits and pieces, such as typography, as early as Microsoft Encarta 95, and later as it evolved into products -- for example, Windows Media Center and Zune. Now, the Metro UI that ornaments the Windows Phone 7 will become the standard UI and user experience (UX) across the PC and phone as well as the upcoming Xbox 360 dashboard update.

The Industrial Designers Society of America (IDSA) awarded Windows Phone 7 the People's Choice Design gold award and the Best in Show award early in 2011. Isabel Ancona, who is the User Experience Consultant for IDSA, explained why the Metro UI on Windows Phone 7, shown in Figure 1, won this award:

"The innovation here is the fluidity of experience and focus on the data, without using traditional user interface conventions of windows and frames. Data becomes the visual elements and controls. Simple gestures and transitions guide the user deeper into content…. A truly elegant and unique experience."

Figure 1: The Metro UI

We most certainly are not used to accolades of design like this awarded to Microsoft!

The Windows Runtime

So, let's try to define what WinRT is and what it is not. Here's Microsoft's definition: "WinRT consists of an execution interface as well as a collection of APIs that give access to the functionality provided by Windows 8." That Windows 8 part is important. Currently we can assume that WinRT will run only on Windows 8 and Windows Server 8.

"The WinRT application model was designed to make interfacing between languages and platforms easy and seamless." This is also important because as you'll learn in a second, this monster has many heads, and that is a good thing. But, I call Windows a platform, so I am guessing that Microsoft means HTML and native code are platforms. Because as stated previously, WinRT functions only on Windows 8.

So what are we to conclude from this definition, and why is WinRT different from the .NET Framework? Well, .NET as a framework is operating system agnostic. It runs on Windows 2000; it runs on Windows 7, and on every Microsoft OS in between. Technically, because of the open specification of the CLR, it could run almost anywhere including iOS, UNIX, and even on IBM mainframes. WinRT as a runtime is tied directly to the Windows OS it is running on. And in WinRT's case, it's tied to Windows 8.

Now, one of the decade-long critiques of .NET has been that what we gained in developer productivity with it we lost in performance because, as a framework, .NET is abstracted and wrapped to the point of hurting its performance when measured against native code (e.g., processor-specific, Win32, C++). Microsoft tells us that WinRT is much "closer to the metal" and promises to be lightning-quick when compared to .NET.

Now, Microsoft claims WinRT is a native runtime system that is implemented directly on the Windows NT kernel. However, a few sharp engineers who have looked under the hood have found that the WinRT runtime libraries are built upon the Win32 API. Since Window 8 and WinRT are not even in beta, I believe it is way too premature to do any whining about WinRT performance, but even so, the internals seem a bit odd because .NET uses exactly the same approach.

The Infamous Windows 8 Stack Diagram

Look carefully at the Windows 8 stack diagram in Figure 2. .NET lives in that tiny little corner at the bottom right.

Figure 2: The Windows 8 platform

We have this stack diagram poster up on the wall in our lab at InterKnowlogy. As a joke, one of the engineers drew a tiny arrow to the bottom right corner and in tiny print wrote: "We live here." The reality is that we can live in both the green and the blue areas and intend to.

The green part of the stack diagram represents the Metro style of application development, which is native to Windows 8. But the tremendously great news is that Windows 8 has desktop mode (the blue part), and all your existing .NET apps will run in that mode. Perfect: It's the best of both worlds; your decade-long investment in .NET is not lost. Now, I have to admit that when I was briefed on Desktop mode months ago, I feared that you'd have to do a crazy keyboard combination like Windows+Shift+D to get from native Metro mode to Desktop mode and suffer a flicker and resync of the video driver, but thankfully, that is not the case at all. You switch back and forth from Desktop mode to Metro mode seamlessly, and the links to desktop mode apps actually exist in the Metro interface.

Notice that the screenshot in Figure 3 shows a Metro interface, but with a mix of tiles of Metro apps and Desktop apps.

Figure 3: Metro interface with both Metro and Desktop apps

The black tiles with the white stars in them are the little Metro app samples I built and compiled in Visual Studio 11. In fact, when I first got my hands on a pre-release Windows 8 tablet, I was absolutely shocked when all our existing .NET-based software installed and ran perfectly on it. The Windows Presentation Foundation (WPF) interactive kiosk product I'm involved in installed and ran perfectly. The kiosk app has a local service built in Windows Communication Foundation (WCF) that talks to a cloud back end. All our full 3D-based WPF apps installed and ran perfectly -- even our physical therapy demo that uses Kinect for a gesture-based interface. It all installed and ran perfectly.

It's important to understand that applications that live on the green side of the Windows 8 stack diagram cannot run in or access anything in the blue side, and vice versa. And that makes sense. Applications you build for Windows 8 are either Metro-styled apps or Desktop-mode apps.

So now that we are confident that the old world (.NET) still lives nicely in this new Windows 8 environment, let's switch gears into explaining the new world of WinRT.

WinRT has a programming model that makes it possible to write object-oriented code that can be shared across programming languages. It also claims to enable services such as reflection. In his session at BUILD, Herb Sutter, from Microsoft, explained that the WinRT metadata is .NET metadata. Native code can't contain metadata, so consequently it is stored in separate .winmd files that can be reflected just like ordinary .NET assemblies. Sutter further explained that because it is .NET metadata, the developer can use code written in managed .NET languages from unmanaged WinRT languages, and vice versa. If this is too close to the metal for you, the translation is that with this metadata and reflection we get tremendous developer productivity when programming for WinRT.

As you can infer by examining the green section of the Windows 8 stack diagram in Figure 2, application development in WinRT consists of three different types of programming:

C++: Historically, Win16 and Win32 programing in C++ was challenging and only for the most elite of programmers. With this new version of Visual Studio and WinRT, Microsoft promises that the C++ pain will be significantly reduced, if not totally eliminated. Clearly, C++ is still the choice for best performance for applications running on Windows. Programming to WinRT is the only way to write Metro applications.

C# and VB.NET: The .NET fear, uncertainty, and doubt (FUD) has been alleviated because the programming languages of C# and VB.NET do have a place in Windows 8 in WinRT, as does a new version (4.5) of the .NET Framework in Desktop mode. In Desktop mode, which is not the native Metro interface mode of Windows 8, .NET applications will have a place as will legacy applications. Yes, I intended to make that inference. And there will be a way to get to .NET Framework classes through WinRT, albeit this capability is currently limited in the preview release. Carl Franklin of .NET Rocks! fame does a really interesting comparison of the components of Silverlight and WinRT in his wiki that I suggest you check out if you want to do a study of what's currently there and what isn't.

It is very clear that the "pretty boy" of applications for the next decade is going to be HTML5. And Microsoft assured us that it's going to throw everything at HTML5 to ensure Microsoft is the leader in the HTML5 space. In fact, that total focus on HTML5 is what put the .NET world into a panic several months ago. With HTML5, in combination with Cascading Style Sheets 3 (CSS3) and JavaScript, Microsoft promises to provide the absolute best tooling in Visual Studio 2011 and Expression Blend 5 to take advantage of the power and ease of the platform in WinRT. (More about this a bit later.)

The Tools

A surprisingly stable and full-featured new developer version of Visual Studio was announced and distributed at the BUILD conference and is now generally available for download from MSDN. The new version, Visual Studio 2011, has garnered rave reviews from the first set of early adopters. Visual Studio 11 promises to provide an integrated development experience that spans the entire life cycle of software creation, from architecture to code creation, testing, and beyond. As you'd expect, Visual Studio 11 is fully integrated with Visual Studio Team Foundation Server, enabling an entire team to collaborate throughout the development cycle. Microsoft has come a long way to compete quite nicely in the life cycle tools space.

I could talk about new Visual Studio features all day long, and there are plenty of Internet resources available for that, but my favorite feature comes from Microsoft Research (MSR). I frequently call MSR the place where great technology dies because often, if they lack a clear revenue model, really cool things get killed by Microsoft business people. But, the Code-Clone Analysis tool made its way out of MSR and into Visual Studio 11. The Code-Clone Analysis tool examines your solution and looks for logic that is duplicated, enabling you to factor this code out into one or more common methods. According to Jason Zander, corporate vice president, Visual Studio, "The tool does this very intelligently; it does not just search for identical blocks of code, rather it searches for semantically similar constructs using heuristics developed by Microsoft Research." Seeing the Code-Clone Analysis tool in action is believing. It is truly amazing.

What surprised me the most in the tooling suite is the new version of Expression Blend, version 5. I have grown to love the existing Blend 4.0 tool for producing XAML in WPF and Silverlight applications. Microsoft Expression Blend 5 not only produces XAML but also HTML5.

Because of HTML5's dynamic nature, it is pretty much impossible to see how a web page is going to look unless it's running in a browser. Blend 5 has a new interactive design mode that enables you to run your app on the design surface as a live app instead of a static visual layout. This saves a ton of time, precluding you from switching back and forth from a browser to the toolset. Drag-and-drop styling is Blend's bold promise. You can hack on the XAML or HTML5, of course. But experts in Blend can often style an entire application without ever looking at the code.

In their preview versions, both tools produce the exact same project templates for building Metro applications, and although this might not be obvious, they produce and are compatible with the same solution files and consequently behave well together. You can have the exact same solution open at the same time, and either tool will warn you to reload when a change is made in the other tool. Use Visual Studio to write code; use Blend to style your app.


The other main important part of this new era is that Microsoft is betting the farm on HTML5. Having studied HTML5 and the HTML5 ecosystem for a year now, I've totally "bought in." I love HTML5 -- and I love its potential even more. Ironically, I was the one in the mid-1990s who, after looking at HTML, said, "Oh my God, who would do this? It's awful!" You see, I have gray hair. I came from a compiled-code background and was formally trained in programming at school. A markup language? "Well, it's not even a programming language," I said. "It doesn't even support recursive programming structures." The first versions of HTML were never designed to do the things we have contorted it to do. "And TCP/IP?" I said. "It's an inefficient, disconnected, and stateless protocol. It's bound to collapse under the weight of demand." You see, I came from a mainframe background of beautiful and efficient binary protocols. Little did I know that Cisco Systems would make a bad thing worse by inventing that little 8550 router.

HTML5 is beautiful because it's terse. It's simple, brief, and readable. It's refactored. The before and after screen shots in Figures 4a and 4b give you a glimpse of HTML5's simplicity. They show the exact same, simple "Hello World!" HTML page in HTML4 and HTML5.

Figure 4a: HTML4 "Hello World!" page

Figure 4b: HTML5 "Hello World!" page

You can identify a web page as HTML5 by looking at the first line of HTML code. An HTML5 page always starts with the simple form of the Doctype declaration, which triggers a standards mode in all HTML5-compatible browsers. If you view source from your browser on many of the bigger, popular sites on the Internet, you'll see everyone is already using HTML5. Apple is doing it; Google is doing it; Microsoft is doing it.

By the way, the World Wide Web Consortium (W3C) has targeted 2014 for the ratification of the HTML5 standard. The W3C is the body that owns the copyright to HTML and is responsible for HTML5 and all the ancillary standards around the open web. Interestingly, May 2001 was the last call to confirm the technical soundness of the W3C specification for HTML4. That was a long time ago. Once a standard has been blessed, the W3C turns its focus to implementation. How does a standards body focus on implementation? Well, it works on a battery of tests of compatibility. We are in the phase where the W3C is creating in excess of 200,000 tests. When two of the major browsers pass all those tests, at 100 percent, then HTML5 is done, and the W3C moves its focus to HTML6, which, of course is already in the scope and spec phase. So those are the exit criteria for HTML5.

HTML5 is an HTML that has grown up. When you add the 1-2-3 punch of HTML5-CSS3-JavaScript and the tools of Visual Studio 11 and Blend 5, you have a cross-platform, cross-device solution for building and deploying applications that will be hard for the competition to reckon with.

If Microsoft Builds It, Will They Come?

Only time will tell how significant Windows 8, Metro, and WinRT are. Time will tell whether Windows 8 with its Metro application style will be a true leader or just another slowly adopted desktop OS whose associated application development platform has had limited acceptance. It's still unknown how quickly Windows 8 will be adopted, and it won't even be released for another year or so. So, as awesome as it is to build Metro apps, and as powerful and fun as it is to build HTML5 apps, if customers are slow to adopt Windows 8, we won't get to build these apps. I sure hope we will.

Nevertheless, a few things are perfectly clear: First, .NET is not dead. A new version of .NET Framework is coming: .NET 4.5, which installs nicely on Windows 8, and its apps run in desktop mode. I expect that businesses with existing investments in .NET applications will continue to invest in .NET, even apps built on Windows Forms and WPF, which many in the .NET world had written off as dead. Second -- and this is no surprise -- Visual Studio 11 and Expression Blend 5 are true leaders in the tool space and will live up to bold expectations. Third, WinRT is cool and elegantly designed to make the balance of the application developers happy. And finally, .NET programmers take heed: There is a new sheriff in town, and his name is HTML5. The future is now, and the future is HTML5.

Tim Huckaby ([email protected]) is CEO and founder of Actus Interactive Software and InterKnowlogy, experts in .NET and Microsoft platforms. He has worked on and with product teams at Microsoft for many years, has co-authored several books, and is a frequent conference speaker.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.