Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI] add Universal Windows Platform build #612

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

robUx4
Copy link
Contributor

@robUx4 robUx4 commented May 24, 2023

This should fail without #611

Edit: it failed, but not during compilation...

Edit2: It does work with MSVC as in recent SDKs GetFileInformationByHandle() is allowed to compile, even though the documentation says otherwise twice.. So the problem is with mingw-w64 that needs to be updated accordingly.

This should avoid compiling code silently code that is not supposed to link.
It may link UWP apps with the wrong library if CMake is not configured properly.
But we can find these errors early during compilation.
Which actually results in this error:

error C4703: potentially uninitialized local pointer variable 'converted' used
In MSVC we can get this error

error C4146: unary minus operator applied to unsigned type, result still unsigned

In the end it's clearer to set the constant in hexadecimal with the
amount of bits we want.
The appxManifest generated by CMake won't use it and use the executable
name instead.
@ktmf01
Copy link
Collaborator

ktmf01 commented May 24, 2023

Thanks for trying to make this work. I hate to be blunt, but isn't UWP deprecated since about 18 months ago? I haven't had many complaints about it not working, and AFAIK the FLAC libs work fine for anyone wanting to use them in an UWP app.

If you can get it to work, that would be great, but I'm not sure it is worth a lot of trouble?

@robUx4
Copy link
Contributor Author

robUx4 commented May 24, 2023

It does compile and should work (no extra patch needed, as soon as mingw-w64 is patched). This extra CI would be to make sure it doesn't break in the future. Not sure if not running tests would be an option, otherwise we're close.

As for being dead, it's hard to tell. If you want to publish Apps on the Xbox that's still the only way to go. Otherwise there's the GDK option (not available to everyone) and then you have other restrictions triggered by WINAPI_FAMILY_GAMES instead of WINAPI_FAMILY_APP. This MR could totally be switched to that. That mode is definitely alive at Microsoft. They even added support to vcpkg for it (semi officially).

@ktmf01
Copy link
Collaborator

ktmf01 commented May 24, 2023

Oh, OK. It seemed the information about the state of UWP is rather vague at best.

@ktmf01
Copy link
Collaborator

ktmf01 commented May 26, 2023

I've tried to run this locally, it seems UWP apps need to run in some kind of sandbox? Whatever I compile for UWP, it won't run apparently. That seems to be the reason the tests fail now. @dmitrykos perhaps you know how to run/test the compiled executable?

@dmitrykos
Copy link
Contributor

dmitrykos commented May 26, 2023

@ktmf01 I have no experience with UWP tests automation, so can't point to some ready solution unfortunately but what I know is that UWP Console app (I assume test is a console app) has to declare self as console app - desktop4:Subsystem="console". Microsoft gives some hints in Create a Universal Windows Platform console app.

When I was experimenting with #581 I installed "Console App (Universl) Project Templates" NuGet extension via Extensions menu, then created "Hello World!" console app based on UWP Console app template and when started it Visual Studio deployed compiled UWP Console app to the OS, so I could see it in Start menu. Later it could be invoked in PowerShell.

UWP app can be built in command line as such:

msbuild my_test.sln /t:Build /m:4 /p:Configuration=Release /p:AppxPackageDir=%APPX_OUTPUT_DIR% /p:UapAppxPackageBuildMode=StoreUpload /p:AppxBundlePlatforms="x86|x64|ARM" /p:AppxBundle=Always

To be able to side-load into the OS and then execute it, package must be signed with developer certificate I believe.

Some additional pieces of information related to UWP app automation can be obtained in Set up automated builds for your UWP app.

@robUx4
Copy link
Contributor Author

robUx4 commented Jun 2, 2023

I identified the issue. The problem is that when building for UWP, it relies on a vcruntime140_app.dll for some runtime calls (memcmp, strchr, strrchr, memset, memcpy, memchr, memmove). The _app part of the DLL name means it's only for UWP/UAP apps. Except that DLL is not in the PATH when running Ctest. Once you put it in the PATH, the tests work (the .exe of the tests are found in the proper location). In mingw-w64 we can get around this problem by using api-ms-win-crt-private-l1-1-0.dll which contains all the API's we need.

Now the question is how to put that DLL in the PATH, or not use it at all when using Visual Studio. I suppose it should be found in the Windows SDK to be redistributed, but it doesn't seem so. It is found in some WinSxS package in the Windows folder, but it's only meant to be used through a manifest. It also seems to be found in some path like C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.32530.0_x64__8wekyb3d8bbwe. But I'm not sure there's an easy way to find this path.

There's also something called Hybrid CRT which is supposed to simplify those cased by using a static library for regular CRT calls. I've followed their instructions but it still ends up requiring vcruntime140_app.dll :( Although I don't have a HybridCRT.props file on my system...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants