Cannot compile for UWP (Universal Windows Platform)

[michaelcowan]

Description

I am porting an existing project that makes use of Catch to UWP. When compiling I get the following errors (amongst others):

error C3861: 'AddVectoredExceptionHandler': identifier not found
error C3861: 'SetThreadStackGuarantee': identifier not found
error C3861: 'RemoveVectoredExceptionHandler': identifier not found
error C3861: 'SetThreadStackGuarantee': identifier not found
error C3861: 'GetStdHandle': identifier not found
error C2065: 'CONSOLE_SCREEN_BUFFER_INFO': undeclared identifier

It would seem that UWP does not supply these classes.

Steps to reproduce

1. Using VS2017 create a new UWP App
   File -> New Project -> Installed -> Visual C++ -> Windows Universal ->DirectX 11 App (Universal Windows)
2. Add catch.hpp to the project
3. Include the header

#define CATCH_CONFIG_RUNNER
#include "catch.hpp"

4. Compile

Extra information

• Catch version: v1.9.6 also tried v2.0.0-develop.3

[horenmar]

Interesting. I guess it makes sense that Win32 APIs when building for UWPs, but I wonder why CONSOLE_SCREEN_BUFFER_INFO is not present either. Can UWP applications run in console?

[michaelcowan]

@horenmar Looking at the templates available and a quick Google seems to suggest that you cannot create console application using UWP. This makes sense to me as the point in UWP (as I understand it) is that the 'App' can run on Desktop, Tablet, Phone, Console etc

[horenmar]

This should be fixed in Catch 2

[michaelcowan]

@horenmar Thats awesome, thanks very much!
I have manually tried this change and everything compiles as expected.

I think maybe we got our wires crossed about the console though. Although I don't think you can create a console only App using UWP, it is still possible to write to the console output window using OutputDebugString.

[michaelcowan]

@horenmar I tried release v2.0.0-develop.4 and now I am getting:

error C2039: 'OutputDebugStringA': is not a member of '`global namespace''

Its also worth noting that when I replace this with my own writeToDebugConsole method, it is never actually called.

[CBaiz]

I had the same problem with OutputDebugStringA on Windows with Visual Studio 2017 in a console application project.
Solved it by writing this:

#include <windows.h>
#define CATCH_CONFIG_MAIN
#include "catch.hpp"

[horenmar]

That is weird. We forward declared OutputDebugStringA to avoid including windows.h in the common path, so it looks like the final single include header gets stitched wrong.

---

The problem is definitely with stitching. We are working on making it saner, but didn't have much time lately.

[horenmar]

Can you check whether the attached single include works for you?
catch.zip

[CBaiz]

I've tested it without #include <windows.h> and it works like a charm.
Good work and nice reaction time 👍

[michaelcowan]

@horenmar That build works for me too using UWP. Still no console output though. When a test fails all that is shown is

Exception thrown at 0x00007FF9B3149E08 in testapp.exe: Microsoft C++ exception: Catch::TestFailureException at memory location 0x000000774BAFC554

And its lost in a lot of other debug output.

[horenmar]

@michaelcowan Well, UWP apps do not provide proper stdout, you will have to redirect it yourself to wherever.

We could do it as well, but the only place that is at least semi-guaranteed to exist is the debug output and that can already be pretty full.

[michaelcowan]

@horenmar A quick look at the Catch source and I can see its using ::OutputDebugStringA(...) which is available in UWP. Is it possible for UWP to be able to use this too without running into the issues with the exception handling originally reported?

To be clear, In my UWP application I can simply:

#include <windows.h>
// snip
    ::OutputDebugStringA("test");

[horenmar]

@michaelcowan I know. However, the debug output can already be quite noisy, thus I think it is better to let our user redirect stdout to wherever is most appropriate for their application (or use -o). I am willing to be convinced otherwise though.

[michaelcowan]

@horenmar Because I'm working on several platforms at once, it was consistency I was looking for.
I am using a config like this:

Catch::ConfigData config;
config.showDurations = Catch::ShowDurations::Always;
config.useColour = Catch::UseColour::No;
session.useConfigData(config);

For iOS (XCode) the test results are written to the Output window.
For Windows and UWP the test results are not.

I found though that I can have all platforms write results to their output windows by adding:

config.outputFilename = "%debug";

I'm not sure if this is a bug or not but from a user experience I expected all platforms to work the same.

That said I'm more than happy with the build you provided as it does exactly what I need with this tiny tweak.

Thanks for all the help and the impressively speedy updates - its really appreciated 👍

[horenmar]

@michaelcowan You could argue that the inconsistency stems from inconsistent behaviour between XCode and Visual Studio. By default, Catch writes its output to stdout. UWP apps do not show stdout anywhere, but it can be redirected by freopen and the like. It just so happens that XCode redirects stdout to its debug output on its own, while VS doesn't.

However, as you found out, you can ask Catch to redirect the output to a file (including a special file, %debug). Under everything that is not Visual Studio, the %debug file just writes to stdout. For Visual Studio, we use OutputDebugStringA, which does place the output to its debug output.

[michaelcowan]

@horenmar Yup, agreed. That makes sense to me.

[philsquared]

Is there anything outstanding on this issue?
@michaelcowan are you reasonably happy with where we are now?

[michaelcowan]

@philsquared Absolutely!

[philsquared]

Cool - thanks