Thank you. So, I did miss on some stuff, such as -lucrtapp and "store" (now that I've looked, there's also "uwp") subdirectory in MSVC installation. I think with this I can at least make sure that library builds and behaves as expected when built for UWP configuration.
I'm trying to be careful about which functions I use, and if something is not available to UWP, add conditionals to control whether this code is included. (Funny enough, now that I decided to get rid of using CRT's _locale_t type, I have removed usage of mbstring.h string function, and *currently* I have no more code that is not available to UWP apps) I think I'll try to write README for winstorecompat, but don't mind my English skills :). ________________________________ From: Martin Storsj? <[email protected]> Sent: Sunday, November 23, 2025 6:20 AM To: mingw-w64-public <[email protected]> Subject: Re: [Mingw-w64-public] A few questions about UWP apps and winstorecompat 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 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
