Comparison between Windows Presentation Foundation (WPF) [607744]

Comparison between Windows Presentation Foundation (WPF)
and Universal Windows Platform (UWP)

David -Traian Belenesi1, Ovidiu Constantin Novac2

University of Oradea, Romania,
1Master Student: [anonimizat],
2Department of Computers and Information Technology, Faculty of Electrical Engineering and Information Technology
Universității Str., 410087 Oradea, Romania, E-Mail: [anonimizat]

Abstract – In this paper I present two types of desktop
application development technologies which are
somewhat similar, but still, very different at the core and
the architectural part. Windows Presentation
Foundation (WPF) apps are desktop applications
developed with the WPF framework , which is based on
the Win32 API. WPF has been the replacement for
Windows Forms, coming with a lot of new and improved
features such as great support for separation of concers
and XAML -based UI. Universal Windows Platform
(UWP) is a development platform which was built b ased
of WPF, but is using Windows Runtime calls. UWP
allows the creation of Windows Store compatible
applications, which means UWP is not only targeting
desktop apps, but also tablet/mobile apps, basically apps
for any device running Windows 10.

Keywords : operating system; wpf; uwp; windows 10 ;
.net framework; C#

I. INTRODUCTION IN .NET DESKTOP APP
DEVELOPMENT

In order to be able to talk about desktop
development and WPF/UWP, we first have to look up
the term operating system . An operating system is a
collection of sof tware programs which have the role of
managing the computer for the user. The operating
system is managing both physical and logical resources,
and there are quite a few different operating systems
competing for this job. When we are talking about WPF
or U WP applications, we are immediately thinking of
the Windows operating systems. So far, at the time of
this writing, WPF and UWP are Windows -based
frameworks , but in the future, we might see cross platform for these frameworks, especially with the rise
of .NET Core.
Operating systems which are part of the Windows
family are defined by the Windows API [1]. The API is
a collection of functions which allow programmers to
interact with the operating system on a relatively low
level, offering access to a lot of Windows features, but
in a controlled environment. API calls ensure that
whatever the programmer is trying to achieve from the
OS, it will be done in a controlled and safe way,
according to the way Microsoft developers created the
API function.
The Window s kernel and the Windows API were
written completely in C mostly. C and C++ represent
unmanaged environments, while C#/.NET is a managed
environment .
Since both WPF and UWP are technologies based
on C# and the .NET Framework, it is important to
understand the core difference between the way
.NET/C# and C/C++ work. One of the main differences
is the way they allocate memory for variables . While C
and C++ require the programmer to allocate memory
and free it up when it is no longer needed, C# /.NET
come up wit h a garbage collector . Memory for objects
instantiated in C# is allocated automatically, and when
the objects are no longer in use, the garbage collector
frees up the memory. In both cases, memory allocation
is done through the controlled way offered by th e
Windows API. However, .NET offers another wrapper
on top of that [2].
In order to run WPF apps, the user must have the
.NET Framework installed [3]. The framework installs,
aside other things, the CLR (Common Language
Runtime), which is the base layer be tween the MSIL –
converted C# code and the operating system itself, thus
the CLR being responsible with allocating and freeing

up memory. Running UWP apps also requires the user
to have a version of Windows 10, UWP apps being
unable to run on prior versions of Windows.

II. WINDOWS PRESENTATION FOUNDATION
(WPF)

WPF [4] is the successor of Windows Forms,
coming up with a lot of improvements in 2006. While
retaining, to a certain degree, the looks and feel of
WinForms applications, WPF apps had numerous
improvements when it comes to UI, the way of writing
code and application stability.
One of the most noticeable features WPF brought,
which moved on t o UWP as well, is the separation
between UI code and actual logic code. This is done
through the XAML Markup Language. XAML is used
by both WPF and UWP in order to design the UI of the
application (both layout and styling are done through
XAML).
The busin ess logic code is done separately as C#
code. This is extremely helpful for application
development and maintenance.
Besides this, WPF also improved when it comes to
resolutions and DPI. WPF UI is able to scale smoothly
for different resolutions, and it also takes into
consideration the DPI when rendering the UI.
WPF applications are based on the Win32 API,
which means they can run on all versions of Windows
based on the NT kernel (Win9x is not supported ).
However, WPF apps are unable to work on Xbox or
some other specific Microsoft devices.

III. UNIVERSAL WINDOWS PLATFORM

UWP [5] is a relatively new technology which came
up in 2015 as an obvious attempt to encourage
developers into moving from WPF towards UWP
development. The main purpose and use of UWP is
running applications of all Windows 10 devices. This
means an application written in UWP can be ran on a
desktop Windows 10 PC and also on a Xbox One or a
Microsoft tablet.
This cross -platform concept is appealing to
developers who are targeting multiple platforms. UWP
is similar to WPF, at a first glance, however they are
very different when it comes to architecture and the way
they work.
UWP applications are running in a sandbox
environment. This means that everything they do is
contained in a s pecific sandbox, and they require certain permissions when ever they want to move out and
access certain resources such as writing to an arbitrary
location on the disk.
This is a very important concept, as, while being a
security improvement, not allowing malicious code to
access unwanted parts of the computer and the
operating system without consent from the user , it also
means the developer is quite restricted by the UWP
architecture. Permissions for UWP apps are similar in
concept to other mobile operati ng systems such as
Android.

IV. COMPARING WPF AND UWP

As mentioned above, while they might look like
they are very similar and serve the same purpose, these
two frameworks are quite different where it matters the
most: at the base, the core architecture.

Fig. 1. The architecture of WPF [6]

As we can see in Fig 1, the main presentation
framework of WPF, which includes UI elements etc., is
at the top of the chain. As we go down, we can observe
the aforementioned Common Language Runtime
(CLR). The next layers contain the Milcore, which
translate C# code in MSIL code, and the User32 +
DirectX layers. UI in WPF applications is rendered
using DirectX . These are already at a low level, sincer
right after there is the Windows Kernel.
UWP is different: it does not contain lower levels in
its hierarchy. Basically, UWP is characterized by the
One Windows component, which is what allows UWP
to run on all Windows 10 devices smoothly. The next
layer is what translated the UWP application and
adjusts it for different platforms. Depending on the
device that the app is trying to run on, different device
modules will be used. Basically, when writing the
application, developers do not have to worry about
platform specific code, as everything is being done by
UWP and the W indows Runtime themselves.
The UWP architecture can be observed in Fig 2.

Fig 2. Architecture of UWP [7]

After having a look at the architecture of these two
technologies, we can already identify some differences.
While WPF has a more static architectu re and
communicates with Win32 API features, UWP is a
sandbox, which can run on any Windows 10 device
thanks to the different device -specific modules which
are part of its architecture.
This also means that WPF apps have full access to
Windows features and also they can get full file system
access, meaning they can write anywhere on the disk,
provided the user running the application has said
permissions. UWP, on the other hand, works differently
in this aspect.
UWP applications are allowed to read and writ e data
only in their own sandbox, which, physically, is
determined as a specific folder inside LocalAppData
called LocalState. That folder contains the data that the
application stores on disk, and the application has full
read and write permissions for th at directory. However,
other locations on the disk cannot be directly written
using UWP C# code. There are specific UI controls
such as file pickers, which allow the user to select a
specific location on the disk where to read or save a file.
That way, use rs are able to access arbitrary locations on
the disk, but user input is required for this to work, as
the file picker can only allow access to that location by
the user selecting the file or folder. WPF apps can write
automatically, in the background, to any location on the
disk.
When it comes to the things they have in common,
we could easily say that the way developers design app
UI is one of the biggest similarities, as both
technologies are using XAML for this. However, even
XAML controls are not 100% the same, as UWP has
some controls which were not available on WPF.
Also, they are both supporting data binding, which
was also one great feature that came up with WPF over
WinForms. Data binding implicitly allows greater
separation of concerns and lets th e developer use
certain helpful design patters such as MVVM. One great feature of UWP that WPF does not have
out of the box is the touch -screen support. UWP
libraries contain certain Windows controls which have
built in touch screen support. This means the developer
does not have to write any code in order to get a touch –
screen compatible application. WPF is not optimized
for touch -screen, but for keyboard and mouse.
When it comes to the application model, we can see
clear differences between these two tech nologies. The
runtime on which they run is different: WPF uses the
.NET Framework, while UWP uses the Windows
Runtime (WinRT) . Also, while WPF supports C#,
VB.NET and F#, UWP supports only the first two.
WPF is built from scratch, with more than 80%
managed code, while the XAML UI of UWP is a
complete new native UI stack.
A similarity they both share is the rendering. While
in fig. 2 we do not see the DirectX layer, both WPF and
UWP use vector graphics bas ed on DirectX when it
comes to rendering the UI.
When it comes to the ability to style applications
and layouts, they are similar, but UWP is more
restrictive. The same can be said about control
customizations and custom control creation.
When it comes to deployment or distribution, WPF
apps are using the classic way of installing applications
on Windows: XCOPY deployment or MSI installers.
UWP, however, is limited to Microsoft Store or
sideloading for internal distribution. In order to deploy
to the Micros oft store, the app must pass some certain
Microsoft quality tests. Sideloading does not require
interaction with the Microsoft Store and does not need
the pass of any tests, but there is an .appxbundle file
which must be distributed to the computers on whi ch
the application must be installed.
Going back to the resource access of these apps,
WPF apps are allowed to access any resource the
logged in user has permission for, but UWP apps, even
if given certain permissions, cannot overcome certain
restrictions such as starting another process or
Windows Service or doing interprocess
communication.
When it comes to the performance of the
applications, we can say UWP wins pretty easily. While
WPF apps are managed code, which is in general
slower than native code a nd requires more memory,
UWP apps written in C# or VB.NET are compiled to
.NET native. This means the app has almost the same
high-performance of a native app.
Both technologies have long term support, since
WPF is part of the .NET Framework and UWP is par t
of Windows. While WPF is a mature technology,
currently in maintenance state (innovative

improvements are not expected anymore), UWP is
developed actively.
Both WPF and UWP can be developed using Visual
Studio. The Microsoft IDE provides full support for
these two frameworks, including a designer, for a
preview of how the developed UI will look without
having to compile and run the code. Visual Studio has
some other useful features in writing and compiling
these applications, like the ability to modify XA ML
code and see changes in real time, while the application
is running.
There are also different API methods and functions
for certain features. Some of the WPF concepts have
been rewritten for UWP differently, while others did
not exist at all in WPF. One good example is the use of
the StorageFile class in UWP. Normally, WPF apps are
working with the System.IO.File class in order to
access files on the filesystem. However, UWP
introduces the StorageFile class. This class is specific
for UWP and the way UWP works, as it can usually
only read from the local storage folder, which is called
LocalState. In addition, there is also StorageFolder and
some other classes which are only available with the
UWP Windows 10 SDKs.
We can also have a look at the way UWP app s are
organized on the disk, compared to traditional WPF
Win32 -based applications. While WPF apps have an
.exe file which is visible and accessible for the user, on
a certain location on the disk, UWP apps use the
sandbox concept. Thus, running a WPF app i s done by
running its corresponding .exe file. UWP apps,
however, do not have a direct, accessible .exe file for
users to run. Technically, there is an .exe file, but it only
serves as a shell for the main UWP application and it is
in a pretty enclosed loc ation on the disk. Double
clicking the UWP exe file does nothing but show an
error informing the user the app must not be ran from
the exe, but from the start menu, as that will also load
the application itself, inside the shell program. This
feature is ob vious, as it allows integration with multiple
platforms, such as Xbox One.
The sandbox behavior of UWP also offers the app a
certain directory, in which all app related files are
present, called the application local folder. The local
folder for UWP apps i s located inside the
LocalAppData folder in Windows, and it contains a few
directories. One of them is the aforementioned
LocalStorage, which contains different files that the
app has either saved or must read from (such as
databases, pictures etc.). This is the only location on the
disk that a UWP app can directly access, thus the
sandbox -style of the apps. They are basically isolated
from the rest of the filesystem and the rest of the operating system. This means there is a better security,
as UWP apps ca nnot run malicious code, they cannot
execute malware or write files on random locations on
the disk. They are also not able to write registry files or
start other Windows Services.
When it comes to the UI, we can find differences
between how the UI control look and work.

Fig. 3. UWP controls (no styles applied)

Fig. 3 shows how UWP textboxes look by their
default style in universal windows platform apps. UWP
also introduces controls which were not previously
present by default in WPF, such as the Toggle Switch
control which can be seen in fig. 3. As a comparison, a
similar UI for WPF is shown in fig. 4.

Fig. 4. WPF controls (no styles applied)

V. CONCLUSIONS

While not as popular as they used to be in the past,
losing ground to Web application, desktop applications
are still widely used and develop ed around the globe,
with a considerable demand in sc ientific and medical
domains, domains where the application must
communicate with certain hardware components such
as scientific devices, spectrometers, foam analyzers etc.
Therefore, the use of desktop application
development frameworks speeds up development a lot,

and developer s have a few options to choose from.
Obviously, UWP is the newer and more modern –
looking technology, but WPF should not be eliminated
from the equation either, since WPF is a framework
which has been used successfully for years, has a lot of
community supp ort and controls and is loved by the
developers for its freedom, as opposed to UWP’s
obvious constrains on the developer.
The choice between these two frameworks should
be considered when starting a development project
based on the needs of the applic ation. If the application
is a simple online shop app where touch screen support
is crucial and which must work flawlessly on tables and
phones, UWP should definitely be considered.
However, if the target application has to write in
arbitrary locations on the file system, does not require
touch screen support or mobile support and perhaps
communicates with certain hardware components and
windows services, then WPF is a much better candidate
over UWP.
REFERENCES

[1] https://en.wikipedia.org/wiki/Windows_API
[2] https://en.wikipedia.org/wiki/Managed_code
[3] https://en.wikipedia.org/wiki/.NET_Fra mework
[4] https://en.wikipedia.org/wiki/Windows_Presentation
_Foundation
[5] https://en.wikipedia.org/wiki/Univer sal_Windows_P
latform
[6] https://www.tutorialspoint.com/wpf/wpf_overview.h
tm
[7] http://justsajid.com/technology/architecture -of-
universal -windows -platform/