At the Build conference in September 2011, Microsoft provided
details about their next operating system release, code name
“Windows 8.” Leading up to this conference there has been a
fair amount of uncertainty about the future direction of the
Microsoft development platform, including Microsoft .NET and
Microsoft revealed that Windows 8 supports two broad
categories of application: traditional desktop applications and
the new WinRT, or “Metro” style applications.
The new WinRT API and the Metro style applications it enables
may represent the future of smart client development on
the Windows operating system. However, it is important to
understand that Microsoft stated their clear intent that all
applications that run today on Windows 7 will run in the
Windows 8 desktop environment. This means that applications
built using Silverlight, WPF, Windows Forms, or other existing
technologies will continue to run on Windows 8.
WinRT is a new operating system programming interface (API),
updated for modern technologies and concepts. It replaces the
aging Win32 API, enabling the creation of applications that can
better take advantage of modern networking, power, and user
“Metro” is a set of user experience and interaction design
guidelines that Microsoft recommends for WinRT applications.
Microsoft describes Metro as a language for touch-based
applications. To this end, Metro defines a language for touch
gestures comparable to the existing language for mouse
gestures, along with a set of UI style, animation, and interaction
guidelines for applications.
No current technologies directly map to the WinRT/Metro
environment. The current technology that is closest to WinRT
is Silverlight. Developers using Silverlight today will find that
their skills remain relevant, and that much of their code can be
rewritten for WinRT with reasonable effort.
Developers using WPF and HTML5 today will find that their
skills transfer to WinRT, but it is unlikely that existing WPF or
web application code will easily move to WinRT.
This document will explain the Windows 8 development
environment, based on the current understanding of the
technology. It will then discuss high level migration strategies
from today’s technologies to WinRT.
Metro Style vs. Traditional
WinRT/Metro style applications differ from the traditional
“Windows” look by eliminating the Windows “chrome” such
as frames, window borders, control corners, etc. in favor a full
screen, immersive experience. Metro style applications are
intended to leverage asynchronous features in the UI controls
and languages to provide a very “fast and fluid” interface.
Figure 1. Traditional Windows application.
Figure 1 is an example of a traditional Windows application. Notice the following UI elements:
- Title bar with control corners
- Ribbon/toolbar with many controls
- Visual scrollbar controls
- Status bar with information
- Busy visual appearance
- Window borders even when full screen
Figure 2. WinRT/Metro style application.
Figure 2 shows a typical Metro style application. Notice the
- The page is full screen.
- The page is “chrome” free.
- Visual display is not cluttered, and is easy to read and
- There are no large scroll bars. Instead, there are visual
clues that there is more to the right (a well-written Metro
style application only scrolls in the “natural” direction –
in this case left and right).
- The entire experience is “touch ready,” but works with
a keyboard and mouse equally well (e.g. touch is a first
class citizen). Designing for touch will support mouse
and keyboard in most cases.
WinRT vs. Win32
The Windows Runtime API (WinRT) replaces the old Win32
libraries for accessing operating system functions. The WinRT
API is object oriented, largely asynchronous, and callable easily
by a wide variety of programming languages.
Win32 continues to be supported by Windows 8, and it is what
enables all existing Windows 7 applications to function in the
Windows 8 desktop environment.
Figure 3 illustrates the Windows 8 development platform,
showing the WinRT and Win32 APIs, along with the development
technologies supported by each API.
Figure 3. Windows 8 development platform.
The Win32 API continues to support existing technologies,
- Windows Forms
- C++ (MFC and ATL)
ActiveX, Flash, and Silverlight
The new WinRT API supports the following technologies:
The .NET, C++, and HTML5 application models are restricted
to the WinRT API and functionality allowed within the WinRT
security sandbox. The browser that runs in WinRT does not
allow plug-ins, so custom toolbars, Flash, and Silverlight are all
The main advantages to the WinRT API are as follows:
- Sandboxed security model with restricted functionality
that is deemed safe within the sandbox
- Simpler and more stable API as compared to the older
- Support for an easy, asynchronous, object-oriented
- Callable by all supported development tools and
- Easy access to hardware such as the camera, sensors, and
other modern hardware devices in few lines of code
In summary, Windows 8 offers two broad application
development models: WinRT and Win32. The Win32 API allows
existing applications to run on Windows 8. The WinRT API
enables the creation of new applications that can take advantage
of modern hardware, networking, and other services provided
by the new API.
Windows 8 Development Strategy
When considering the impact of Windows 8 on future software development, the following broad strategies should be evaluated:
- Continue to use existing technologies, and run the
application in the desktop environment.
- Create a WinRT/Metro style smart client application that
takes full advantage of the new WinRT and Windows 8
- Create a browser-based web application that relies on no
plug-ins, so it can run in the browser in both the WinRT
and desktop environments.
The first two options are the most likely options if your current
applications are smart client applications that use WPF,
Silverlight, or Windows Forms.
Although it is possible to write a new web application to replace
existing smart client applications, this involves a completely
different developer skill set, and offers no ability to reuse any
existing code assets. However, it is also the case that web
applications provide the broadest reach of all application types.
Such applications can run on any device with a browser, including
all major platforms and devices, such as Windows, Mac, iPhone,
iPad, Android, etc.
The third option is ideal if your current applications are
web applications, because it is likely that your existing web
applications will continue to offer the same behaviors and value
to the end user in Windows 8 as they do today.
In summary, you must first decide whether to create smart
client applications or web applications. If you decide to create
smart client applications, you must then decide whether to
support WinRT, or to build applications for the Win32 desktop
The remainder of this paper assumes you are considering the
creation of smart client applications on WinRT.
Figure 4. Mapping current technologies to Windows 8.
No existing technologies map directly to the WinRT platform.
Figure 4 shows how existing technologies map to the Windows 8
As you can see, all existing technologies map directly to the
Windows 8 desktop environment. This is illustrated by the green
lines, indicating that these applications are expected to work in
Windows 8 with no effort.
The yellow line for Silverlight indicates that many Silverlight
applications can be migrated to WinRT with reasonable effort.
We will discuss this in more detail later in the paper.
The red line for WPF indicates that migration to WinRT is
possible, but will require more substantial effort.
The red dashed line for HTML indicates that development skills
will transfer, and a limited amount of existing HTML, CSS, and
code assets may apply to WinRT application development.
Applications written using existing technologies will require effort
to migrate to WinRT. For applications written with technologies
other than Silverlight and WPF, the term “rewrite” is probably
more accurate than “migrate”.
Common Migration Scenarios
Silverlight to WinRT .NET
Silverlight provides a reasonable migration path to WinRT. We
come to this conclusion because of the following:
- Silverlight and WinRT use XAML to describe the UI layout
- The WinRT subset of .NET is not that different from the
existing Silverlight subset of .NET.
- Silverlight and WinRT both require asynchronous
interaction with servers, so Silverlight applications are
already architected and designed to be asynchronous.
It is important to understand that Silverlight applications won’t
“just run” on WinRT. Although they use similar XAML and have
a similar .NET subset, there are enough differences that any
migration effort will require some reworking of the XAML and
application code. We expect substantial XAML and code asset
reuse, but with some effort.
One important consideration is to use clear layering and
separation of concerns when building Silverlight applications.
Applications should avoid all “code-behind” the XAML controls,
and should use the MVVM (model-view-viewmodel) design
pattern to cleanly separate all code from the XAML.
WPF to WinRT .NET
WPF shares some common technologies with WinRT (and
Silverlight). These include the XAML language for describing the
UI layout and interaction, along with the C# or VB languages,
and the .NET base class library.
However, WPF is less likely to provide an easy migration to
WinRT than Silverlight. We come to this conclusion because of
- WPF provides access to the full .NET API, and it is quite
likely that existing WPF applications make use of .NET
features that don’t exist in WinRT.
- Few WPF applications use asynchronous interaction
with servers, and moving synchronous code to an
asynchronous model usually requires a lot of effort.
Notice that these assumptions can be overcome. If you are
extremely careful to apply some constraints to your use of WPF,
the migration process can be more reasonable. Specifically:
- Avoid using parts of the .NET API that aren’t available in
Silverlight (such as direct file system access).
- Use only asynchronous server access.
- Maintain clear layering and separation of concerns.
- Avoid all “code-behind” the XAML controls, and use the
MVVM design pattern.
By following these guidelines when building WPF applications
today, the chances of reusing existing XAML and code assets
Web Applications to WinRT HTML5
Web applications share some common technologies and
concepts with HTML5 smart client applications in WinRT, but
there are fundamental differences. Web applications assume
the use of a web server, and the majority of web application
code typically runs on the web server. An HTML5 smart client
application doesn’t have a web server, and all application code
runs on the client.
Existing web development skills in HTML and CSS layout, along
WinRT development. Optimistically, it is possible that some
HTML and CSS markup can be moved from a web application to
highly focused on user interaction and HTML manipulation.
client application, or refactored into service interfaces that
can be installed on an application server to be called from the
In summary, existing applications will not run in WinRT without
change. Of all current technologies, Silverlight offers the best
potential for migrating code assets. Existing WPF and HTML
skills will carry over to WinRT development, but little or no
existing code assets are likely to carry into the new platform.
The new WinRT API and Metro style applications it enables
may represent the future of smart client development on the
Windows operating system. Existing applications will continue
to run in the Windows 8 desktop environment. Additionally,
existing web applications that avoid the use of plug-ins will run
in the WinRT web browser.
If you decide that the WinRT and Metro style application model
is a platform you may wish to support in the future, your best
strategic move is to start developing today using Silverlight.
Alternately, you can use WPF with extreme care to emulate the
Silverlight development model.
In any case, existing developer skills in XAML, C#, VB, .NET, and
Silverlight carry forward to WinRT development. The same is
Contributing authors: Kevin Ford, Jason Bock, Sergey Barskiy,
Stuart Williams, Chris Williams and Rockford Lhotka.
Appendix A: Technology Comparison Chart
Click chart to enlarge.
* Note: combinations of factors not listed here may point to two or more UI technologies being needed.
- If touch is needed in the future, application can be designed to Metro style standards.
- Windows 8 phones are planned to be supported with Metro applications.
- HTML5/JS Metro applications could be selected if there is an internal skill set for that technology.
- WebForms are generally considered an older technology, in general use ASP MVC unless there is a compelling reason to use WebForms.
- For applications not in the app store, a deployment system will be needed.
- Mono may make app store approval more difficult.
- Windows Phone 7 leverages .NET skill sets.