UWP limitations in desktop apps

The phrase "Win32 desktop app" is a ill-defined since the Win32 API programming model has been around since Windows NT 3.1. It can also cover dozens of development languages and UI frameworks over the intervening two decades.

Here's a quick overview of the key UWP differences:

• API surface area. The UWP platform supports many but not all Win32 and COM APIs, and introduces new APIs. If your "Win32 desktop app" is using mostly ANSI APIs that date back to Windows 95, then you have a lot of updating to do. If you are using mostly Windows Vista era UNICODE APIs, then a lot of stuff "just works". See Win32 and COM API for Windows Runtime apps (System).

• Security context. The UWP platform runs applications in an AppContainer security context. "Win32 desktop apps" on Windows Vista or later run as "Standard User" or as "Administrator". UWP apps have less access rights than "Standard User" and can never run as "Administrator". UWP apps can request additional capabilities to get a few more rights with permission from the user, but have limited access to the system and user data. For example, you cannot read most of the filesystem, only your installed location, an isolated application data folder, and an isolated temporary file folder. See File access and permissions (Windows Runtime apps). This also means UWP apps have limited access to devices. See Device and sensor overviews.

Windows Vista User Account Control that introduced Standard User was focused on protecting the system and other users data compared to the older "everything is administrator" model, but did little to protect the current user's data files since all apps could access or even modify it. AppContainer isolation is protecting both the system and the current user's data and settings. "Win32 desktop apps" were encouraged to install to C:\Program Files which was read-only at runtime and to use application data folders, but they were not required to.

• Deployment via AppX. "Win32 desktop apps" use any number of ways of deployment, often something using MSI technology and running as "Administrator". UWP apps are packaged in AppX files and are always deployed by the system. There is no "Custom Install Step", and therefore UWP apps cannot install drivers or services, change ACLs, etc. The system takes care of deploying the C/C++ Runtime (which must be Visual C++ 2015 or later).

• Interface model. There is a plethora of interface frameworks for "Win32 desktop apps" like WinForms, MFC, WPF, etc. The vast majority of these are not compatible with UWP because UWP does not support classic Win32 windowing, WM_ messages, or GDI/GDI+. For UWP apps, you can use XAML with C++ or C# code-behind, DirectX (Direct2D and/or Direct3D) with C++ (or C# via 3rd party assemblies like SharpDX), or HTML5 with JavaScript.

• Deployment via MSIX.

Answering your question is therefore extremely difficult, if not impossible, without a complete understanding of the product's code base and dependencies.

See Get started with Windows apps