Terminal: C# GUI app integration example

[pingzing]

Hi! Building on @waf's good work with his C# ConPTY sample I put together an (_extremely_) basic sample of what a custom console might look like as implemented in WPF and UWP. Strong caveat, it currently doesn't parse, or properly render the VT codes, but it shows the skeleton of what such an app might look like.

https://github.com/pingzing/ModernPseudoSh

This was mostly a proof-of-concept that I thought would be fun to throw together, to see what was possible. However, it occurs to me that it reveals some useful things about what's required to get a GUI application talking to and displaying a ConPTY. Would this be a useful thing to have as a sample in the repo?

[ysc3839]

Is it possible to use ConPTY API in UWP Apps?

[pingzing]

It seems like the answer is "broadly, yes". I did notice that pwsh.exe threw an error setting up its filesystem access, but I suspect that's because I was missing the broadFileSystemAccess capability. I'm already using the runFullTrust capability, which allows the UWP app to start arbitrary external processes.

Do note that both of those capabilities will torpedo your chances of distributing through the Store, though.

[zadjii-msft]

Is it possible to use ConPTY API in UWP Apps?

Boy what a question this is.

I believe it's certainly possible to build an app like @pingzing has here that'll run as a UWP. However, that comes with some strong caveats:

1. CreatePseudoConsole and the other conpty APIs are part of the "desktop" api partition, not the "App" API partition. This means that although they exist in the SDK, your app won't pass certification in the store if you try and call them. This is mainly due to the fact that all of the PROC_THREAD_ATTRIBUTE API's are also only in the Desktop partition. It wouldn't make sense to be able to create a pseudoconsole from a UWP, and not be able to attach anything to it.

1. Any UWP can technically call CreateProcess on any arbitrary commandline - you don't need RunFullTrust for that. However, when you do launch that external process, it will also be running in the same Low-IL app container as the UWP app itself. That's why it seems as though powershell is unable to access the filesystem, because it doesn't have the permission to do so from within the app container.

2. RunFullTrust only works for "Desktop Bridge"/Centennial/ apps. These are Win32 apps that are running as an app package basically. Unfortunately, the RunFullTrust capability does not magically make your UWP application a Medium-IL, non app containered thing. It actually doesn't do anything to a UWP app :/.

3. RunFullTrust won't torpedo your chances of being in the store - there are plenty of Win32 apps in the store nowadays with the RunFullTrust capability.

[pingzing]

RunFullTrust only works for "Desktop Bridge"/Centennial/ apps.

I suspected that might be the case, and that actually informed my initial approach. My first stab at this had a regular Windows Desktop console app as a "host", and then wrapped it to inside a Centennial package. I couldn't find a way to transmit data between it and the UWP app except by using AppService, though, and that has a number of complicated drawbacks, especially for a bitty li'l PoC. Though it occurs to me that this Bridged app might also have the same App Container sandbox issues. Hmm.

At any rate, the WPF app presents many fewer issues =P

[miniksa]

It looks like @zadjii-msft is being a bit coy. This is actually what he's been spending a lot of time investigating as of late. We let the ConPTY API out in the world and now we're trying to sand the rough edges off and one of the biggest ones is around using it with UWP. He's exploring many solutions to it. Ask him how many meetings he has had related to it. :P I can't say much more without upsetting the planning and management gods, but trust that he is on top of it and we'll let you know more when we figure it out.

@pingzing on your other question, I personally think more samples is more better. I hate not having a variety of samples when trying to code something. If you clean them up and want to contribute them along side our original example and @waf's C# one, I'd be happy to review your pull request. Maybe just start with the WPF one and let the UWP hang for a bit?

[pingzing]

@miniksa oho, very interesting indeed! Best of luck to you, @zadjii-msft. (If you _do_ find a way to pull it off, open source iiiiiit)

But yeah, WPF alone seems like a reasonable enough thing to do. I'll clean it up a bit and come back with a PR.

[zadjii-msft]

Why, I was being coy :P It's been a LOT of meetings across Windows, and I think I'm getting awfully close to the line of what I can and can't say.

My first stab at this had a regular Windows Desktop console app as a "host", and then wrapped it to inside a Centennial package. I couldn't find a way to transmit data between it and the UWP app except by using AppService, though

That was one of many attempts we had at enabling this. Unfortunately the AppServiceConnection doesn't provide any ordering guarantees, so you'd have to implement that yourself... there are basically a TON of drawbacks to doing it that way.

Suffice to say, working with a Pseudoconsole in a UWP application is not a workflow the platform currently (Windows 1809) supports.

[Biswa96]

I've zero idea about UWP world! But I have some useful info. Quote from @zadjii-msft's first point:

This is mainly due to the fact that all of the PROC_THREAD_ATTRIBUTE API's are also only in the Desktop partition.

Those PROC_THREAD_ATTRIBUTE APIs aka. UpdateProcThreadAttribute() and InitializeProcThreadAttributeList() function manipulates some value in struct _PROC_THREAD_ATTRIBUTE_LIST which is appended with struct _STARTUPINFOEXW.
So if OP translates those functions to C# then it may be possible to convert ConPty to UWP (without Desktop Bridge/Centennial).

[zadjii-msft]

From experience: don't do that. While yes, technically possible, it's mostly just a red herring. The much bigger issue with UWP is getting the child process out of the app container.

In fact, you don't even need to translate them to C#: you can build a UWP in straight-up C++. However, if you do call those functions, again, you're going to end up failing certification.

[ysc3839]

Found this feature, which allows you use UWP XAML UI in Win32 apps.

Windows 10 now enables you to use UWP controls in non-UWP desktop applications so that you can enhance the look, feel, and functionality of your existing desktop applications with the latest Windows 10 UI features that are only available via UWP controls.
https://docs.microsoft.com/en-us/windows/uwp/xaml-platform/xaml-host-controls

[zadjii-msft]

Ah yes, XAML Islands. That is another route you could take for embedding some UWP XAML elements within a Win32. It's got some caveats, but if you've got an existing WPF app, it's a really good way to incrementally include some UWP controls.

[doubleyewdee]

Stumbled on this while trying to figure out a since-resolved issue. I'm not sure it makes sense to include my project as a direct sample but it night be worth a link in the examples area? https://github.com/doubleyewdee/condo is what I've been up to.

With noting I also briefly looked at UWP and ended up peeling off due to the mentioned issues.

[miniksa]

@pingzing, is this still relevant?

[pingzing]

Nope! Though it is fun looking back at this discussion now =) Will close this.