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.
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.
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.
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.
