Elad Maimoni
Elad Maimoni

Reputation: 4595

Is there a way to bypass UWP restrictions on certain APIs?

I have experimented with creating a Windows-10 C++ UWP xaml application.

My motivation in choosing this platform was to avoid using multiple languages (C# for WPF gui, C++-CLI for interop) and only use C++ with some C++-CX.

My goal was to create an in-house tool for debugging a PCI driver, not to create some sort of highly secured windows store application.

It appeared to me that UWP application are very restrictive when it comes to using some WIN API functions. For instance, I can't use my static libraries because they use CreateFile & DeviceIoControl. I get an error that says: error C3861: 'CreateFileA': identifier not found.

Even if I somehow manage to link my native libraries (by hiding the use of these functions in .cpp files) those functions seem to fail at runtime.

Is there anyway to bypass those restrictions? I only want to use this platform for its C++ UI capabilities.

Upvotes: 1

Views: 2351

Answers (2)

Victor Derks
Victor Derks

Reputation: 378

Many "old" win32 functions are still available or have become available in Windows 1803. Targeting the UWP API is of course different then the Win32 API. Microsoft has a list of official supported Win32 APIs at: https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-apis

CreateFileA is not on that list, but CreateFile2 is.

For device access UWP provides functionality in the namespace Windows.Devices.Custom

LoadLibrary\GetProcAddress can also be a solution.

Most of the restrictions only apply to UWP apps that are uploaded to the Store, and not for a side by side loaded application. You can just create the package and put it on a local network share or http server.

Upvotes: 2

Yury Schkatula
Yury Schkatula

Reputation: 5369

Sorry for the bad news. Indeed, if you don't match mentioned restrictions your choice is not UWP. Do WPF instead.

UWP apps are intended for centralized control. So that, you can distribute them via Store, limit their filesystem access, manage memory footprint & lifetime etc. You can think about it like an attempt to discontinue Win32 API (which is rather old, hacker-prone and anarchic) and employ sand-boxing as a superseder.

Upvotes: 4

Related Questions