Any ETA when it will be available in Microsoft Store?

[ghost]

P.S. Thanks a lot for the app! I have some ideas and I hope I'll contribute with pleasure when I get more free time 😉

[felixse]

Current ETA is never 😄

I would love to add this to the store, but there are 2 problems with getting this past the certification:

1. It is not compatible with Windows 10 S, since there is no cmd.exe/powershell.exe in this version of Windows, which would render the app completely useless.
2. I am bypassing a network isolation rule which blocks UWP apps from connecting to localhost. We need this for our websocket connection between the xterm.js in our WebView and our winpty backend.

We might be able to circumvent the second problem by switching to https://github.com/darrenstarr/VtNetCore.UWP once it is ready to use, but changes are high that the certification will still fail due to the Windows 10 S support

[balcsida]

@felixse: Several, larger apps (eg. Photoshop Express, Paint.NET) doesn't work on Windows 10 S either, I don't think this would be a problem.

[ghost]

It is not compatible with Windows 10 S, since there is no cmd.exe/powershell.exe in this version of Windows, which would render the app completely useless.

As far as I can tell that's not a problem, because you can specify which Windows editions do you support by your app.

I am bypassing a network isolation rule which blocks UWP apps from connecting to localhost. We need this for our websocket connection between the xterm.js in our WebView and our winpty backend.

Unfortunately I have nothing to say, but I hope that's can be implemented / fixed.

@felixse Thank you again, love your app 😉

[balcsida]

I am bypassing a network isolation rule which blocks UWP apps from connecting to localhost. We need this for our websocket connection between the xterm.js in our WebView and our winpty backend.

Edge extensions have the same limitations, which can be bypassed by the setting described on qzind/tray#6

There is a registry entry to that, so simply adding this reg file should resolve this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap]
"IntranetName"=dword:00000000

See webextension-toolbox/webextension-toolbox#22 for more info (we use local WS connection to autoreload extension and tab on save)

If you have time, could you please try this method?

[felixse]

Hey,
we already have a workaround for this limitation (see: https://github.com/felixse/FluentTerminal/blob/master/FluentTerminal.SystemTray/LoopbackEnabler.cs)
The problem is that Microsoft most certainly will not allow these hacks in the store.

[Riebart]

Stumbled across this documentation that seems to be an officially schema manifest entry for allowing a UWP app to talk to its own service. Looks like it will enforce that we can't talk to other things on localhost, but this might be good enough, and also might help with #43 ?

This MSDN thread has some illuminating discussion.

[felixse]

The loopbackAccessRules are designed to help with connecting to other app packages, not to your own, where (in general) that's not necessary as loopback is allowed. It looks like your desktop app being full trust threw a curveball at how this works. I haven't tracked this all the way down, but the behavior suggests that since it's not running fully in the package's security context it's not being allowed as part of the package.

Sounded too good to be true 😕

So the crash in #43 was related to the missing loopback exemption?
I guess a native terminal renderer will be the best option for this and a few other issues.
So either this or swallow the pill and write it ourself 💀

[Riebart]

Yeah, I read that "only for other apps" comment, but it didn't seem to make sense since it claims that UWP apps have access to other sockets on localhost started by processes within their package, but that seems to not be true. Unless the FullTrust-ness of the system tray application breaks it out of the UWP app package boundary? I don't know enough about UWP development to make heads or tails of those inconsistencies.

I actually bumped into this with the UWP RDP app as I usually SSH port-forward RDP connections through a gateway, and the UWP RDP app was refusing to allow me to connect to localhost. But yes, this loopback connection is indeed the issue for #43 (I'll be posting a comment there momentarily).

That said, it looks like you can use named pipes across processes within a package boundary (ref)? I still need to do some more reading, but if we can get the JavaScript WebSocket in the main terminal view, and then pass the named pipes from the system tray to the main terminal view, that could work.

[felixse]

Yes, to me it also sounds like FullTrust is 'outside' of the package in regard of the network sandbox.

The double piping you described sounds like an interesting idea. I will hack something together and see how it performs 😄

Another thing I tried this evening was to move winPTY into the app itself, but I cannot get it to create the pipes it needs to operate on.

[Riebart]

Yeah, the UWP portion of the app won't be able to load the winpty DLL, as the DLL environment of UWP apps is tightly controlled, so that makes sense that the winpty interface needs to be in the tray application.

That said, we should be able to create the pipes in and out of the system tray using named pipes as you currently do, and just move the fully .NET WebSockets library into the UWP app. That removes the localhost-across-processes issue, and moves it into a named-pipes-inside-the-package context. This will make the required Windows version 1709 or newer, but I think that's probably fine.

Here's to hoping that Microsoft's documentation is correct. 😸

[felixse]

I'm on this right now, really hope this will work, and not perform like crap 😃
Its getting a bit weird, we have pipes from winPty, connected to UWP conform pipes, connected to a webSocket.
1709 is already the minimum version, at least one thing less to worry about 😄

[felixse]

No luck so far with getting your idea running. I have pushed my current working state to Dev/NamedPipe if you want to have a look at it. Maybe you find something I overlooked, but it seems to me that the SystemTray running outside of the app's security context also means that we cannot use a \LOCAL pipe between the App and the SystemTray.

Next thing I will try is to use the AppServiceConnection instead of the named pipes. Not my favorite option since this would basically limit use to one connection for all open terminals, but let's see how it turns out.

[Riebart]

Aw fudge. I was hoping that would work, but now that I've done some more reading, it looks like FullTrust processes are indeed outside of the app container boundary, so both the localhost loopback, and the named pipes in the LOCAL context are out. The AppServiceConnection async message-passing mechanism is the only way that you are supposed to be able to communicate it seems.

I think my effort should be first applied to getting #45 updated and merged in, then I'll spin back around to this.

[felixse]

Good news everybody.
Using AppServiceConnection for a little problem seems to be not as bad as I thought. Its working quite good on Dev/AppServiceCommunication, just needs some more polishing.

After this is done I will try to submit a version to the Store 😃

[felixse]

I just submitted a version to the store. Let's hope the best 🤞

[felixse]

Short update: It got rejected because it crashes on launch. I think this might be because they tested it with Windows 10 S. I'm a bit short on time right now, but I will try to set up a Windows 10 S environment to check this

[NatoBoram]

In that case, would it be a good idea to check for the existence of cmd.exe and powershell.exe?

[felixse]

That's actually handled already. I received a video from Microsoft showing the instant crash but I had no luck reproducing this on a Windows 10 S test environment. The plan right now is to add some more features/fixes and then resubmit it. If it continues to fail I will see if I can get some assistance from Microsoft.

[villasv]

Really looking forward to this. I think it'll be a major adoption accelerator for WSL!

[DuIslingr]

Any update on this?

[DRSDavidSoft]

@felixse You might provide a pseudo-shell on Windows S, that could be useful if you have time to write one.

[davidanthoff]

Any update? I just started using this, it is awesome, the only (somewhat) inconvenient stuff is the installation, having it in the store would be awesome!

[sheikalthaf]

@felixse Thanks for the wonderfull terminal.

Any update on store publishing. It is good to have in store so that it will be an alternative to the windows terminal for those who need more features.

[felixse]

I might try submitting it again after the next version is released. Until then you can also install this from here or on chocolatey

[xa0082249956]

Short update: It got rejected because it crashes on launch. I think this might be because they tested it with Windows 10 S. I'm a bit short on time right now, but I will try to set up a Windows 10 S environment to check this

And one year later they published Windows Terminal in Microsoft Store even if it just crash in S Mode (but you can indeed find install it under S mode).

[felixse]

https://www.microsoft.com/en-us/p/fluent-terminal/9p2krlmfxf9t

We got a release now 🎉

Since this changes the app id again I recommend updating to the normal 0.7.1.0 release first (soon) which will improve settings migration

[villasv]

There's a missing t on that link :-) congrats!

[felixse]

thanks, fixed it

[pgalbraith]

Great news, particularly as I was having trouble getting the latest version to update properly in chocolatey!

@felixse do you think it's possible to get an administrative launch link on Fluent Terminal, like they've managed to do with the new Windows Terminal preview that's also in the store?

[felixse]

Not exactly. It's a bit complicated, but I will probably try to add something like #6 (comment) as an "run as administrator" setting in profiles