Windows-rs: Sanity check: should this be possible?

[ndarilek]

Sorry if this doesn't belong here, but I'm fairly new to all this and am not sure how to go about debugging.

I have a TTS library which includes a working WinRT-based backend. Examples in that repository compile to plain .exe files which run fine.

I have another library which depends on tts-rs. I then attempt to use this library with Godot's UWP export, thus bundling it plus my tts-rs DLLs into a .appx file. My Godot game runs fine except for the TTS functionality, which simply doesn't work.

Before I sink much more time into this, I wanted to sanity-check what I'm doing, especially since I know next to nothing about UWP apps. Is there any reason a DLL built with this crate, and which works fine in Win32 apps, shouldn't work in a UWP .appx artifact? I'm not entirely sure where the DLLs are expected to be, but I've scattered them throughout the test app I'm building and I can't get TTS working. So I don't think this is a DLL location issue, though I could be wrong.

Assuming there's no obscure reason why this shouldn't work, how would I go about debugging it from the command line? I've got env_logger in my top-level library and a bit of logging throughout the dependent library, so if I can get at stdout/stderr in whatever process hosts the appx, that would probably help. I recognize I may need to set env_logger's level manually since passing in environment variables may not be possible, but that's fine. I found this article about windbg, but that doesn't seem to be available in my VS2019 developer command prompt, so either I'm missing something or I'm about to go down another wrong path. :)

Thanks for any help.

[ndarilek]

FWIW, I've since installed windbg, but .querypackages just hangs for me at "Retrieving information." I hope there's an easier way to either get at stdout/stderr, or otherwise figure out why this code works fine directly in a .exe but not in an .appx.

[bdbai]

Since you are going to consume the DLL in a UWP, you probably need to build that crate with target *-uwp-windows-* to link against right libraries, as well as some linker options (say /APPCONTAINER) which have been set up for you in the target specification. Note that some Win32 APIs will be unavailable.

stdout/stderr does not work for UWP apps, probably because of the nature of MTA? Try ETW mechanism with WinRT API instead?

[ndarilek]

Happy to report that I did finally get this working. I found a setting in Godot that makes it log stdout/stderr to a file, tracked down the package storage location, found the logs, discovered that Godot wasn't correctly finding my DLL due to a configuration issue, and eventually got it loading. So I'm successfully building a DLL running in a UWP app that installs to my Windows 10 VM. Tomorrow, hopefully, the Xbox. :)

I'll close this, but I do have two questions. 1. I didn't need a UWP target in Rust. What would that have gotten me? This was tricky to debug, so if me not using a UWP-specific target will come back and bite me later, I'd rather fix that now. :) I seem to be able to use the same DLL on both 64-bit Windows and in my UWP app.

1. Any chance we can get an ETW logger compatible with the log crate? Access to logging would be very helpful.

Thanks again for letting me know this should have worked--I'd likely have given up without that reassurance. :)

[weltkante]

I didn't need a UWP target in Rust. What would that have gotten me?

Probably restricts itself to only use UWP-cleared APIs. This is relevant if you want to distribute through the store, they reject images referencing certain legacy APIs. This isn't checked when you install/run without using the store, you get full access to Desktop APIs, its _mostly_ a verification thing not a runtime thing, but your application may not run on non-Desktop UWP platforms if Desktop-only APIs happen to be used.

[rylev]

If you're looking for a ETW crate which works through the log crate, I suggest checking out https://crates.io/crates/win_etw_provider

[bdbai]

The UWP targets will put a special bit to the binary, indicating the image must execute in an AppContainer which enforces some degree of isolation.

[ndarilek]

Am I correct in reading that UWP targets are tier 3, not built
automatically, and so not available via rustup? If so, then that's
probably where my work has to end for now. I would like to submit my
game to the store, but would rather not maintain my own compiler builds
to do that.

Thanks.

[bdbai]

In case someone bothers to try out UWP targets, xargo would be a good choice.

[ndarilek]

Hmm, I'll look into that. Thanks.

Alternatively, you mentioned a special bit being set by the UWP target.
I assume that's IMAGE_DLLCHARACTERISTICS_APPCONTAINER? If so, is it
possible to add that bit to an existing DLL somehow? My DLL does
currently work fine in a packaged app. Not sure if manually setting that
flag might break things, assuming it can even be done.

Thanks again for the help.

[bdbai]

I assume that's IMAGE_DLLCHARACTERISTICS_APPCONTAINER?

Exactly.

My DLL does currently work fine in a packaged app. Not sure if manually setting that flag might break things, assuming it can even be done.

I have not tried this, but passing the linker option via rustflags is possible. You probably want to test your app with Windows App Cert Kit to check if it is necessary.

[kennykerr]

The app container bit in a DLL is not necessary. This is a relic of the past that we've since disabled as it adds no value.