Windows 8 Architecture from a Developer’s Point of View : Windows 8 Development Architecture

As you have learned, Windows 8 enables you to develop a new kind of application — Windows 8 style applications — while traditional desktop applications still run on Windows. Moreover, you can still use your favorite tools and technologies to develop Windows 8 style applications.

The architects of Windows 8 made an important decision when they created a new stack of architecture layers for Windows 8 style applications. Therefore, in Windows 8, you have two fundamental stacks of technologies (one for Windows 8 style applications, and one for desktop applications) that can be used side-by-side, as shown in Figure 1.


NOTE An architecture layer is a set of components having the same role (for example, communicating with the operating system). A stack of architectural layers mirrors how the services of those layers are built on each other.

Figure 1: Windows 8 has separate stacks of architectural components for Windows 8 style applications and desktop applications

Although these Windows 8 style applications and desktop applications use the same operating system kernel, you have some important things to consider when it comes to application development. Table 1 provides a comparison of the two kinds of applications.

Table 1: Desktop Applications and Windows 8 Style Applications

Desktop Applications Windows 8 Style Applications
Desktop applications can be programmed either on top of the Win32 application programming interface (API) that dates back to 1995 (and many of its parts even to 1991), or with the .NET Framework that uses managed base classes. Although the richness of options is a great thing, from an application development point of view, it can be a disadvantage. Depending on the aim of your application — or your intention — you may pick up a mix of languages or technologies to program the expected functionality. Windows 8 style applications represent a new approach. They are about providing a first-class user experience with multi-touch and sensors, and they are very sensitive in terms of user interface (UI) responsiveness. Imagine an application where you can drag an object on the screen with your finger, rather than experiencing a choppy response as you move the object across the screen with your mouse. To ensure the perfect experience, the API used for Windows 8 style applications should support UI responsiveness natively. Of course, Windows 8 style apps still support perfect mouse and keyboard integration.
Most desktop applications display windows and dialog boxes on the screen, and wait for user input, response, or confirmation. Sometimes these applications show more than one modeless dialog box (that is, dialogs that let you you switch back to the main applications without closing the dialog) over the main window. While working, the user must shift from one window to another, often focusing on distinct tasks simultaneously, sometimes unconsciously. Windows 8 style application development is about providing an intuitive UI where the application owns the full screen. This approach does not encourage using dialog boxes popped up on the screen, but rather suggests using application pages, just as web applications running in the browser do. Windows 8 style applications can be deployed through Windows Store, and must conform with UI and user experience guidelines published by Microsoft in order to pass the certification process.
Desktop applications generally require a standard setup procedure that incorporates a few screens that guide the user through the installation steps. The whole process may take a minute (or even more) while all files and resources are copied to the computer, and necessary registrations take place. Removing an application also follows a standard procedure, and it requires the user to start with the Control Panel. Windows 8 style applications are for consumers who are not necessarily familiar with concepts like files, the registry, and setup procedures. These users expect to be able to add an application to their portfolio with a simple touch or click, and all the other steps are automatically done by the system. These users want to be able to remove programs with the same ease — not caring how Windows implements this procedure behind the scenes.

As you can see, as a result of a consumer-centric approach to this information technology, expectations for Windows 8 style applications are very different compared to traditional desktop applications. The Windows architect team decided to create a separate subsystem for Windows 8 style applications, and also a distinct API to build them.

Before diving into the details of this new API, let’s first take a look at the architectural components of traditional desktop applications.

Desktop Application Layers

To build traditional desktop applications, the developer has available a wide variety of application types with related component stacks. It is funny (but not surprising) how the word “traditional” now has a totally different meaning than it used to have a few years ago (say, perhaps five years ago). Although, with the emergence of Windows 8, you can call all the application stacks shown in Figure 2 “traditional,” the managed application stack was quite new in 2002, and the Silverlight stack is the youngest, available since 2008.

Figure 2: Desktop application layers


NOTE Do not feel intimidated if you do not know all the technologies depicted in Figure 2. The aim of this figure is to show you the variety of technology components related to desktop application development. If you are interested any of them in particular, search the MSDN (http://msdn.microsoft.com) using their names.

Notice in Figure 2 the relationship between the Language Layer and the UI Layer. As you can see, the chosen programming language fundamentally determines the stack of technologies you can use to create your desktop application.

For native applications, choosing C or C++ (or other native languages such as Visual Basic, Object Pascal, and so on) that are compiled directly to CPU-specific code means that you must use graphics device interface (GDI) or GDI+ technologies for the UI.

With managed applications, you could still use GDI and GDI+. (In .NET, they are used under the alias of Windows Forms.) A more modern and powerful choice is Windows Presentation Foundation (WPF)—which is based on eXtensible Application Markup Language (XAML)—or its younger (but not less powerful) sibling, the Silverlight XAML.


NOTE While native applications are compiled directly to CPU-specific code, managed applications are translated to an intermediate language (IL). When you run a managed application, the IL is transformed to CPU-specific code by a just-in-time (JIT) compiler.

Though it is not common to create desktop applications with HTML and related technologies, you can create them using HTML Applications (HTAs).

Your language preference also determines the available runtime libraries and environments you can use while programming (the Runtime Layer shown in Figure 2). These libraries contain operations that are natively used by the language to access operating system services, such as displaying values, managing files, or communicating through the network. With native applications, each language used to have in its own language run time, such as Microsoft Foundation Classes (MFC) and Active Template Library (ATL) for C/C++, VB Runtime for Visual Basic (the good old Basic language before the emergence of .NET), or Visual Component Library (VCL) for Delphi (Object Pascal).

.NET eliminated this by introducing its own Base Class Library that is available in all .NET languages, including C# and Visual Basic (as well as other popular .NET languages such as F#, IronPython, IronRuby, and others). Nonetheless, this uniform picture got a bit blurred with the release of Silverlight, which has yet another .NET run time available both in browser applications (such as Internet Explorer, Firefox, Safari, and in a few others) and in desktop applications. The Silverlight Base Class Library is only a subset of runtime types available in .NET.

The runtime libraries of native applications are built on top of the Win32 API (shown in the API Layer in Figure 2), which is a flat API with tens of thousands (actually unrelated) entry points that invoke Windows Core OS Services (the Kernel Layer in Figure 2). In contrast, .NET has its own runtime environment — called Common Language Runtime (CLR)—that provides a better abstraction of the Win32 API in forms of objects that package related data structures and operations into reusable types.

Imagine that you’re an architect who wants to create the development component stack for Windows 8 style applications. Would you merge it with the existing desktop application technologies? Perhaps, but nonetheless, the architect team at Microsoft decided to create a new, independent set of APIs to get rid of the technology fragmentation.

Windows 8 Style Application Layers

With the consumer-centric approach of the Windows 8 operating system, Microsoft now faces new challenges. Creating an intuitive, multi-touch-enabled, always-responsive UI is only one of the challenges. A bigger challenge is establishing a platform that supports developers the right way, allowing them to use the technology and tools they know, and most importantly of all, to be productive.

The Challenge

Microsoft has a very strong development community working with Windows. A vast number of developers have experienced the “consumerization” of IT through web application development. However, only a very small number of developers are familiar with Windows-based consumer devices, namely Windows Phone developers. For a long time, Windows Phone was the only real consumer device from Microsoft.

Many web developers and hobbyists around the world — more than the whole Microsoft community camp — have experience with consumer application development for the Android (Google) or iOS (Apple) platforms. Windows 8 is intended to be an operating system that attracts not only professional Windows developers, but also those who are not closely related to the Microsoft community.

Microsoft seems to have begun gearing up very late in the competition for winning over consumers. Creating new devices and their operating systems is one important step to meeting the competition, but without having a great development platform and strategy, it would not be possible to provide quality applications that were good enough to strengthen Windows, and provide quality alternatives to consumers.

Microsoft has always provided great development tools that have been continuously evolving over time, tools that have offered great productivity. Instead of betting on only one programming language for its platform (such as what Apple and Google do), Microsoft accommodates a plethora of programming languages, and lets its developers choose the one they intend to work with. Providing the best platform for creating consumer applications is definitely a key factor to attaining a better market position.

Microsoft has answered this challenge with the development platform for Windows 8 style applications.

Architecture Layers Overview

By creating an independent stack of layered components for Windows 8 style applications, Microsoft has introduced a new concept that casts off the issues of traditional desktop application development, and reimages the idea of Windows API and language run times. This new concept embraced the support for multiple languages over a single programming API, as shown in Figure 3.

Figure 3: Windows 8 style application technology layers

You can derive a few important things from Figure 3.

All Windows 8 style applications have one ultimate API layer — Windows Runtime — to talk to Windows Core OS Services, and there is no other API a program would need to access them. Independently of the programming language used, every service is available without any limitation, so that you can access from C++, C#, Visual Basic, and JavaScript, too.

HTML and CSS are used by millions of developers all around the world to create websites and web pages. These developers use JavaScript to add (sometimes complex) UI logic to their web pages. In the Windows 8 style application model, Microsoft augmented the potential for JavaScript to access the full set of APIs offered through Windows Runtime.

The newest standard of HTML (HTML5), combined with Cascading Style Sheets 3 (CSS3) and JavaScript, is more powerful than its predecessors. HTML5 sites can natively play multimedia and display vector graphics — leveraging the hardware acceleration of the graphics processing unit (GPU) in the computer. Over the past couple of years, thousands of new websites have been built with HTML5 to provide the user experience of a new era. All this power can be immediately used by developers familiar with HTML and JavaScript technologies to create Windows 8 style applications.

In Windows 8, the core of the XAML-based WPF and Silverlight technologies has become a part of the operating system — rewritten in native code. The UI of C++, C#, and Visual Basic applications can be defined in XAML. The same XAML produces the exact same UI in every language — without constraints or barriers. Because of the uniform UI technology and the same APIs providing access to the operating system services, application models are the same for C++, C#, and Visual Basic.

If you compare the desktop application architecture layers in Figure 2 with Windows 8 style application layers in Figure 3, you can immediately see that the latter is simpler by means of runtime, API, and UI technology choices. Independent of whether you are a web developer, a C++ fan, or a .NET programmer, the entry barrier for creating Windows 8 style applications is actually lowered when compared to creating traditional desktop applications.

Your preference of programming language determines only the UI technology you must utilize in your programs. JavaScript is tied to HTML, whereas other languages (C++, C#, and Visual Basic) are bound to XAML. Generally, developers use more than one programming language and markup language, and they are used to being multilingual, so to speak. Learning a new language should be a motivating rather than a restraining force, however, dealing with separate runtime libraries and components is pretty cumbersome.

Windows 8 style application development strides over this issue. Regardless of your programming language of choice, you must learn only a single set of APIs — provided by Windows Runtime.