On Fri, 21 Nov 2025, Kirill Makurin wrote:
First think I wanted to know - are Windows Store apps and UWP apps the
same thing? They conclusion I came to - Windows Store apps may be UWP
apps, but do not have to. The only useful bit of information I was able
to find is that back in Windows 8*, Windows Store apps required to be
packaged apps, but it seems that now Windows Store allows unpackaged
apps as well.
Yes, I think this is right. I'm not sure if this changed right around
Windows 10 or if it happened sometime later at some point though.
Another question is whether linking against windowsapp.lib
(-lwindowsapp) is required when building for UWP? The only mention of
windowsapp.lib I could find in Microsoft docs is this[1]. If I
understand correctly, windowsapp.lib exports all symbols available to
UWP apps, so in theory, if I accidentally reference a symbol which is
not available to UWP apps, I will get a link error due to undefined
reference?
There can be a couple other details involved as well. If you look in your
MSVC vc/tools/msvc/<version>/lib/<arch> directory, there's a subdirectory
named "store". For building for UWP, you need to set the linker to look
there before other directories. So MSVC comes with a bunch of libraries
built separately for UWP targets.
For mingw-w64, there's usually no such separately built libraries - but
the strategy is that you link with winstorecompat/windowsappcompat, which
provides stubs for things that prebuilt code in your toolchain may
reference.
For mingw-w64, you also want to link with -lucrtapp instead of -lucrt. The
regular -lucrt links against api-ms-win-crt-private-*.dll, which isn't
allowed in UWP mode. -lucrtapp includes more or less primitive
reimplementations of those functions that otherwise would be provided by
api-ms-win-crt-private-*.dll.
Most important question - how do actually build for UWP, does it require
anything special? With MSVC, at first, I thought that /ZW[2] option
would be required, but it seems I was mistaken as this option is used to
compile C++/CX code. Currently, I just link with windowsapp.lib and
define WINAPI_FAMILY macro. This at least allows to verify that this
configuration builds. I feel like I must be missing something, or is
that it?
For building library code, that's pretty much all you need to do - build
with WINAPI_FAMILY=WINAPI_FAMILY_APP and link against the right libraries.
For actually building the application and packaging it, there are probably
a bunch of things that you need to do, that I'm not aware of ways to do
outside of MSVC. So in practice, the use of mingw-w64 for UWP is to build
libraries that you'd then include in an MSVC UWP app build.
The last question - when you need to use mingw-w64's winstorecompat and
windowsappcompat libraries? Do I understand correctly that they just
provide stubs for functions which are not available to Windows Store and
UWP apps?
Yes, pretty much. As mentioned above, this goes hand in hand with the
strategy to not provide separate "store"/UWP versions of toolchain
libraries, but instead link in stubs between those prebuilt files and the
actual import libraries.
Also, do I understand correctly that you need to use winstorecompat if
you build Windows 8* Store app and use windowsappcompat when build UWP
app?
Yes, that's right.
I think we could add a README file to mingw-w64-libraries/winstorecompat
subdirectory with some basic information on using winstorecompat and
windowsappcompat. Currently it just has an empty INSTALL file.
Sure, if you're interested in trying to write it. :-)
FWIW, as far as I know, VLC may be the only user of the store/UWP stuff in
mingw-w64. They did ship things with this around Windows 8 times at least,
but since the rules around the MS Store have changed a lot, I'm not sure
if it has been used and verified lately, or if they've switched to
publishing the regular desktop version.
Also - another aspect around UWP. The limitations around what functions
from which DLLs are allowed aren't really enforced on a techincal level.
When developing an UWP app locally, you can very well call functions
you're not allowed to. Ideally the toolchain won't allow you to do that of
course, but in practice when using mingw-w64 it can certainly happen. It
would probably be caught at some point when publishing such a package
though.
There's a "Windows App Certification Kit" in WinSDK that you can run
locally to check your app as well. And more practically, there are XML
files that list which symbols you're allowed to import, from which DLL
name. The exact set of allowed APIs change between versions of the WinSDK
as well, so the exactly policy is, as mentioned, quite fuzzy.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
