Typing inside of the default WSL terminal feels amazing (2018) | Hacker News Reader

Typing inside of the default WSL terminal feels amazing (2018)

github.com

332 pointshnbreak117 comments

Author of the GitHub issue here. I was surprised to see this title, because I thought "holy cow, finally someone else appreciates low input latency" and then I realized it was my issue haha.

By the way, wsltty 3.x also has excellent input latency now too. I've been using it for quite a while now with terminal Vim in WSL and it's about 90% as good as xterm on native Linux in terms of latency. wsltty also has no issues with tmux where as the MS terminal (both old and new) have severe issues with tmux.

There has been some discussion lately about how latencies have increased over the decades.

https://news.ycombinator.com/item?id=15485672

Another vote for low-latency here.

It’s tempting to create a YouTube channel dedicated to showing input latencies for common tasks. Question is: how do you make sure no one is cheating?

Use a measurement device and show it in the video.

Like the 1000fps camera used in https://danluu.com/input-lag/

Where this would be really transformative is if anyone could submit a video and have it verified. If they set up their own slo-mo capture they could just as easily record a sped-up screen capture.

There's definitely a way out by requiring that the tests are reproducible in a 'lab', but that throws out results from machines the lab doesn't have access to

I just want to emphasize that wsltty is the only well-behaving terminal currently available for WSL. It's the only one that supports mouse interaction in a terminal like scrolling/resizing panes in tmux/vim, unlike any Microsoft solution.

If you're using WSL on a regular basis, I highly recommend it. Its a huge quality-of-life improvement.

I am fairly certain that the inbox console host supports mouse interaction (with WSL and anything else that uses VT mouse mode). As the engineering lead for the console and terminal projects, though, I’d love to know how else we can improve!

I noticed the same issues with tmux and the new MS terminal. The events got completely absorbed.

Also there were a bunch of "crazy" display issues, such as when minimizing the window about ~30% of the time the tmux status bar would become hidden.

Or after I exit tmux or even Vim sometimes without tmux, the terminal's background color would turn yellow (but not the entire terminal's background, just the characters where input / output would be legally able to be placed).

All of these things were discovered within about 2 minutes of using it, so these aren't edge cases. They happened very frequently, and things like the mouse just didn't work all the time.

Edit:

I just put together a 10min video showing a few of these display issues with the new MS terminal at: https://www.dropbox.com/s/puzbfs6ws4p8v7a/ms-terminal.mp4?dl...

The yellow screen issue never happened on video, maybe they fixed that but within 1 minute of using the terminal I found 2 new display bugs that weren't there when I tried it months ago.

Also sorry about the quality of the video. Drop box re-encodes videos at 720p (I recorded it at 1080p) and it looks like they are really strict with bitrates too. It looks slightly better than a potato, but you can still make out the display issues.

I'm not a terminal wizard but there is one bug that constantly happens in my workflow I'm not sure how to report: if I start a powershell session then ssh into a network switch and then access the serial TTY of a kvm guest running on the switch it sets the terminal size to particular dimensions (as expected). If I exit the serial connection then sometimes the terminal is never restored to normal size, even if I exit ssh back to the original powershell session.

Like I said very easy for me to reproduce but probably hard for you guys and I'm not sure what is breaking or how to capture the session to submit a bug.

Also it'd be amazing if profiles could include panes. I find myself almost in need of making an autohotkey script to break the terminal into 4 panes and launch particular ssh commands.

wsltty loaded via ConEmu is the only acceptable terminal combination I've found for Windows, with support for mouse events, scrollwheel and remote terminal resize detection, e.g. ssh into another box and run a program like htop. I last tried microsoft/terminal about 6 months ago and found it incredibly broken.

Can you post your computer specs?

Because it's impossible for me to see any difference between the WSL terminal and Notepad. I can see a tiny difference compared with Electron apps, but I really need to concentrate to see it.

My computer is no rocket, is a higher-end desktop from 6 years ago.

Mine is a ~6 year old i5 quad core desktop. A complete list of hardware can be found here: https://nickjanetakis.com/blog/the-tools-i-use#computer-desk...

If you can't notice it much, perhaps your monitor has really bad input lag and it's overtaking any difference between terminals. My monitor has very low input lag (about 13ms) but most monitors have 50-60ms or worse.

There's another comment in this thread where I go into more details about that and how it plays a big difference in being able to perceive input latency when typing.

Your post How to Pick a Good Monitor for Software Development was really helpful when I was upgrading my home office this fall. Thank you, and anyone else who hasn't specced out a monitor in a while might find it helpful as well:

https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo...

Try changing the theme to basic. In Windows 10, using the default theme added about 50ms in latency.

Thank you for providing the praise to the Windows Terminal team many of us know they deserve, allowing us to just click the thumbs-up response on GitHub.

I truly wish more modern software were capable of reaching this level of latency performance. I understand the response provided by "miniksa" at GitHub, but I don't feel satisfied by it. The maintainers of the frameworks that are described as adding so much latency should make a concerted effort to minimize that latency. We know from experience (see ASP.NET Core) that huge strides can be made in performance (both measured as throughput and latency) and that it is massively rewarding. It requires effort, but the payoffs are real.

I fear computer science is often encumbered by a corrosive culture of "good enough" with respect to performance. We have a lot of baggage and urban myths about performance, from maxims about optimization handed down from the first acolytes of computer science, to modern opinions about UX that over-emphasize simplicity, to a repertoire of clever psychological countermeasures for under-performance such as animation. It's a shame that more people don't appreciate how much more enjoyable computing is when latency is nearly zero.

Obviously orders of magnitude matter. The change from 1000ms to 100ms is more significant than a change from 100ms to 10ms. But we cannot diminish that latter change and we should not accept 100ms as good enough. Improving from 100ms to 10ms is still huge and some of us deeply appreciate it.

> I fear computer science is often encumbered by a corrosive culture of "good enough" with respect to performance.

I feel that's more of a "software engineering" mindset.

> I fear computer science is often encumbered by a corrosive culture of "good enough" with respect to performance. We have a lot of baggage and urban myths about performance, from maxims about optimization handed down from the first acolytes of computer science, to modern opinions about UX that over-emphasize simplicity, to a repertoire of clever psychological countermeasures for under-performance such as animation. It's a shame that more people don't appreciate how much more enjoyable computing is when latency is nearly zero.

I wouldn't blame this on computer science: it's really just a long way of saying you get what you measure. It's not that computer scientists don't care about performance, or that human factors / UX isn't an entire field, but simply that most projects don't set performance goals or prioritize them and unsurprisingly most time is spent on the things which are used to judge someone's job performance.

This is especially true when you see how many issues are shared across teams — in this case talking about Windows it's important to remember that during the Ballmer lost years, Microsoft used stack ranking to force managers to categorize a set fraction of people as low performances and reportedly those rankings heavily favored new features over maintenance improvements. In an environment like that, if the change requires coordination across teams it probably just isn't going to happen unless someone very senior makes it a business priority.

How do you measure input latency?

In the tests I've done on most terminals it was an organic process.

I simply typed into the terminal and let my brain decide. I spent about an hour just flipping between different terminals / programs and doing a bunch of different types of typing tests. It was very very clear and repeatable to do a "better or worse?" test between them.

Typing fast, typing slow and also just holding down the key (this made the most noticeable difference). Terminals that have low input latency will appear to spit out characters liquid smooth if you hold down the key.

I also talked to some friends who use Windows and we came to the same conclusion in a blind test.

For measuring the latency numbers themselves, it was just making a best estimate based on how I perceive those values. I don't think the numbers matter as much as the "this feels better" or "this feels worse" test since in the end that's the deciding factor.

The surprising thing here is that this is the Ubuntu terminal. Indeed, each keystroke goes through the input driver, to USER32, through the console code, to the terminal process in question. But then it goes through a virtual input device, across the VM boundary (which, on Windows is a VM exit plus an entry), through the Linux input driver, into dash (or whatever Ubuntu uses these days), and then all the way back out again, and then it gets rendered.

The fact that this whole dance is faster than notepad.exe suggests that Linux is doing pretty well, that MS’s hypervisor stack is performing well, and that the fancier MS frameworks are really quite slow.

(To be fair, the GNOME Wayland stack has recently been upgraded from awful to sort-of-decent latency-wise. It’s all too easy to design a system where latency wasn’t a primary consideration from day 1 and to have a very hard time improving latency after the fact.)

Note that this content is one year old. At that point, WSL was not a virtual machine, it was Linux syscall emulation in the NT kernel.

Does that mean it's faster or slower now?

I would be shocked if it were faster.

It's faster now.

Depends on the operation in question. Direct syscalls should be faster, but there are some big differences between the NT and Linux kernels. You end up getting all the poor performance areas of BOTH. That, and HyperV has an extremely fast lightweight VM mode for particular hardware. For example, running containers on HyperV actually runs them with VM level isolation, a la Kata containers... and at competitive speeds.

An example of the worst of both worlds result is the filesystem. In the NT kernel, every filesystem call goes through a series of Filters: any program can provide filters for given file types. Filters can do anything, from antivirus programs scanning the file on access, to Notepad adding itself to the Context Menu as an "open with Notepad" item. This makes filesystem access - even metadata checks - very time expensive on Windows. On Linux, we keep file metadata in memory, which is memory expensive, but it makes certain filesystem operations very fast. The result of mapping one onto the other is a combined filesystem operation which is memory expensive AND slow.

So for example, on WSL 1 (mapped syscalls), using a git repo of any size is impossibly slow... on the order of 10 seconds to get a git status for a work project. But on WSL2, the same syscalls live entirely inside the VM and are almost native fast.

Also if it touches NTFS you end up with MFT contention on small files which really knackers performance on WSL 1.

"to Notepad adding itself to the Context Menu as an "open with Notepad" item"

I believe it's the job of Shell API, not NTFS filters.

It is MUCH faster.

I was specifically curious about input latency. Is that what you're saying is much faster, or just WSL in general?

WSL2 is generaly faster: https://news.ycombinator.com/item?id=19868282

Probably both on different tasks

In terms of key press latency it makes no difference. Both the old and new MS terminal have about the same input latency.

The problem is, the MS terminal doesn't work well with tmux which is a 100% deal breaker.

WSL2's I/O is better but that's out of scope for this discussion and also a pretty sketchy thing to run as of today since it requires opting into the insider's release of Windows which has very questionable telemetry requirements.

I think most of the latency between key press and rendering to screen is in the layout / drawing phase.

Forwarding a few function calls is usually pretty fast, the text layout and rendering part is what is slow. Especially since many UI frameworks don't render individual characters; you may end up redrawing a full line or more for every keystroke. (I only have experience with macOS / Cocoa rendering, and I was surprised how slow it is compared to all other things my code does)

All of the actual work can easily happen in under a millisecond. What makes input to screen output slow is anything asynchronous - polling (on the input side, e.g. in the USB protocol itself - USB to PCI uses interrupts!) and waiting for the next frame on the output side. Let's say the console waits for vsync to render its next frame, then the compositor grabs it and renders it in the next frame. That is one frame of gratuitous latency.

Then there's also the input lag of your monitor too which is really important.

A lot of monitors have really bad input lag, in the 50-60ms range and it's highly variable. This spec is also not usually listed by the manufacturer either and it's not the same thing as response time which is typically 1-10ms in most modern LCDs.

Your monitor's input lag plays a very big role in how fast key presses are perceived because ultimately what makes something feel fast and snappy requires an end to end measurement of you pressing a key and then your eyeballs being able to register it.

The monitor I picked has about 10-14ms of input lag which is very good compared to the average. That's running at 2560x1440 (60hz) at 1:1 scaling too.

If anyone is interested in that sort of thing, a while back I put together a very detailed post on picking a good monitor for software development at: https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo...

I still use the same monitor today and I would buy it again today if I were thinking about upgrading. Although I kind of regret writing that blog post now because the monitor is almost twice as expensive today as it was 3 years ago.

> Physical size doesn’t constitute how much you can fit on a monitor. For example my mom thinks that a 25” 1080p monitor is going to let her fit more things on her screen than a 22” 1080p monitor. Don’t be my mom!

> The only thing that matters for “fitting more stuff on the screen” is the resolution of the monitor.

This is only true under the assumption that your eyes have infinite resolution. In the more likely case that they don't, the larger size of the pixels at a higher physical screen size means you need fewer pixels, with the result that you can indeed fit more stuff on the screen at the same resolution.

It's not just eye resolution, its how the application is designed. An older WinForms application will have very compact ui and mad information density, but some modern web apps will dedicate an entire 1080p window to display 1 icon and two buttons.

I would say that combined with DPI scaling, his port provides a reasonable rule of thumb.

One frame of latency is not gratuitous; it's perfectly reasonable to not draw directly "ahead of the beam" and instead double-buffer. Otherwise you get a lot of tearing.

I very much doubt the console is watching vsync either.

The extra frame that I mean is: console renders, vsync, compositor grabs it and renders, vsync. That is what happens on X11 with compositing AFAIK. Only one frame time / one vsync is really required before you consider specifics of the software involved. I've read somewhere that Windows also has an extra frame of latency for similar reasons as X11.

The answer is triple buffering and not using a compositor/ using triple buffering and a compositor that plays nice with it.

If anyone else is curious about measuring things like this, try the https://isitsnappy.com/ app on a modern phone.

It’s real nice to have some competition for macOS on this front — and especially when it moves out of terminals into related tools like editors (VSCode was close to Terminal.app the last time I measured while e.g. Atom was fully an order of magnitude worse). This is a frictional productivity cost which most people discount because it’s not as obvious.

I just tried it and I'm blown away and confused: why is Windows Terminal faster in an ubuntu tab (WSL1, in my case) than in a cmd.exe / powershell tab? I mean the exact same terminal window. Three tabs side by side. The ubuntu one is instantaneous and the others have short but noticeable lag.

This really surprises me.

> Of course this also means that we have trade offs. We don't support fully international text like pretty much every other application will. RTL? No go zone right now. Surrogate pairs and emoji? We're getting there but not there yet. Indic scripts? Nope.

You could say that a longer version of that answer is "Text Rendering Hates You": https://gankra.github.io/blah/text-hates-you/

I'm curious how alacritty compares to it. The alacritty devs basically consider another terminal app rendering faster than them to be a bug on their part ;-) But it does sound like it would be a good challenge.

Kitty seemed faster than alacritty to me. I'd love to see it benchmarked, but I'd class them both in the 'fast enough' category.

I use kitty and alacritty interchangeably on Linux/X and I don't literally can't tell the difference between the two. Sometimes I forget which one I'm using. Using pretty much anything else it's very obvious.

> I'm curious how alacritty compares to it. The alacritty devs basically consider another terminal app rendering faster than them to be a bug on their part

Note: Alacritty prides itself on fast rendering speed, but not necessarily on low latency[0]. I'm a happy Alacritty/Linux user, but I'm not sure it would win on this benchmark.

[0]: https://news.ycombinator.com/item?id=18006751

Alacritty has kind of a lot of input latency, it's noticeably worse than wsltty and the default WSL terminal -- at least back when I checked it a year ago.

I think some work has been done to improve it, but at this point IMO if you're on Windows then wsltty is as good as it gets for a general purpose terminal. If you're on Linux, xterm is top notch.

What's top notch on Wayland?

I never used Wayland, sorry.

Xorg

I don't know, I've got two panes here opened next to each other (tiled/xmonad) with xterm and alacritty, and I've been typing in those for the last 5min, and I really can't tell the difference (my monitor has 5ms latency).

Does it have 5ms response time or "input lag" because both are very very different and input lag isn't a spec you'll find on the box.

You typically need special hardware to measure it, or find review sites that go out of their way to cover it.

According to [1] xterm and mlterm achieve the best values for latency.

1.: https://lwn.net/Articles/751763/

I find it interesting that Even though I don’t care about any of the above features, I still pay for them working with text in other applications. They are a constant tax on latency. It would be great if applications had a “ascii” mode and a “full” mode. You can take the performance or the features, but you can’t have both.

I could be wrong, but I think the payment for one pays for the others. International text is one of those "a large portion of the world wants this" sorts of features. Once you've gotten that, emojis sort of come along for the ride.

Emojis add complexity that other scripts don't, mostly in the form of color processing (all other scripts are monochrome!).

WSL terminal is garbage. Here's what irks me:

* I click on the icon and I get a terminal up (nevermind that it doesn't accept focus on startup, so I start typing and the characters keep going to my task bar).

* I type in "clear && ls" and hit enter.

* My line of text vanishes and I'm left with a completely black terminal. If I scroll up with the mouse-wheel I can see what I should have seen (the output of ls).

* I press up (to step backward through my command history) and all the text vanishes again.

The only workaround I have is to run something like tmux, which is somehow smart enough to render the text on-screen.

I agree, been trying to make this setup work for over a year now because I use Windows at work for a few things here and there but it's just not worth it really...

You would do much better to install Linux and virtualize windows, then you get the best of both worlds. it's great that windows decided to add a terminal after every other OS has had it for decades but I think this thread is a bit like having rose colored glasses on top of your drunk goggles because WSL and Windows terminal are still an ocean away from a usable low latency terminal environment compared even to OS/2 if we're being brutally honest...

Say what?

Exactly which release of Windows do you think didn't supply a terminal?

I'm a heavy WSL user, ever since I switched to Windows last year (after using MacOS for 6 years, and Linux before that).

I must agree that typing is pretty responsive compared to other windows applications, but still nothing near the native experience. I also run clear linux natively on my laptop, and typing in that terminal is just faster.

This is great to see. My experience with windows in general is that the typing latency is usually very bad compared to ubuntu. I can literally notice the lag. Plus some apps have these awful typing animations which make typing feel like wading through mud.

I didn't realize how bad input latency had gotten in general until recently when I needed to boot directly into a terminal. Sometimes I could swear the character appears on the screen before I even hit the key. It's a weird feeling, but I would like more of it.

I know the feeling.

A few months ago I was installing Debian on a desktop, and there's this one part during the installer where it prompts you for some information before your desktop is ready to go.

The input processing was so fast it was stupid. It somehow felt even faster than xterm which is already so much better than just about any app on any OS.

Long time ago we used RXVT because XTerm and ATerm were both too slow

RXVT sucks, but typing on it feels so good that it is what I use.

Correct me if I'm wrong but I've been struggling to really nail down my development process of linux software on Windows, and based on my readings, a lot of articles state that applications perform far better on traditional hypervisors like VMWare and VirtualBox than WSL.

I mean it may be great that the WSL terminal feels good, but if my program takes 2-5x slower in WSL for testing, I'm still going to opt for a hypervisor.

Discussed earlier this year: https://news.ycombinator.com/item?id=19471857

I feel like there was a larger discussion too, but can't find it. Anyone?

I really wish there was a way for the browser to blit pixels to the screen in the shortest amount of time possible. Like talking directly to the GFX hardware using a restricted API like the Canvas 2d context.

That is literally what DirectX/Vulkan is for. They are the fastest API to blit pixels to screen (surfaces/textures as they call it).

I don't have high hopes for something designed by committee.

The Chromium team are experimenting with Low-latency (desynchronized) canvas, although I haven't been able to measure any differences in latency, the only difference is that desyncronization will cause some render issues.

I guess latency is a "full stack" problem where you have to design everything with low latency in mind. eg. keyboard, keyboard driver, render framework, gfx driver, and screen.

Here's an interesting article: https://danluu.com/input-lag/

Sounds like it'd open up some security holes.

How I wish that I could use the new terminal app on the windows 10 build that is installed on my work Laptop.

what is good about this app?

It's faster and works better than old conhost.exe

they're also planning to overhaul it with more modern features judging from its trailer[0] (yes, this terminal has a fancy 3D trailer)

[0]: https://www.youtube.com/watch?v=8gw0rXPMMPE

The real app look nothing like this clip. Really awful, that I have go back to Cmder

I'd see that video more as a "where we want to head this tool in the future" rather than an actual showcase of its current state to be honest

I'd recommend giving it another go and digging into the documentation. They've made the UX much less clunky and support panes now as well as tabs, proper copy/paste etc. My only wish is modal keybindings but if I cared enough I'd send a PR for them.

It was extremely barebones six months ago but it's come a long way, and faster than anything else I've tried.

is it because it's distributed through the store or because you're on a too old version of Windows? In the first case, you could probably build it yourself and install it on your own

EDIT: you can download built packages from the Releases tab https://github.com/microsoft/terminal/releases

yeah, you can download it but not run it and my windows build is not recent enough according to the docs of microsoft/terminal

Wow your work laptop is up to 10 already? We've started to plan our migration.

Windows 7.1 extend support ends on January 14, 2020. So is your org planning a very fast rollout or is it paying $$$ for Extended Security Updates?

There is nothing called Windows 7.1. Windows 7 extended support ends January 14, 2020. Windows 8.1 won't end its extended support until January 10, 2023.

It most likely is a reference to Windows 7 SP1. I've never seen it written as "7.1" but that is probably what they meant.

Yes sorry, that was a brain fart. I did indeed mean SP1. The Windows SDK version is 7.1 so I got muddled.

Windows 7 (without SP1) is already unsupported.

My org is a battleship lol.

Ah, $$$ it is!

we even have WSL. I think someone in upper management pressured IT to either upgrade or start supporting Ubuntu laptops and that kind of got them going.

Does Debian benefit from this work?

TLDR (only slightly sarcastic); 'Because we do things the hard way instead of buying into the 30 layers of abstraction hype'

Qt KTerm, and VTE both supported complex typographies close to 20 years ago and nevertheless achieve similar performance.

It is a testament just how much behind times MS was up until recently.

From my perspective though, libVTE performance is terrible. On modern systems it may not be a concern, but on some of my older systems VTE terminals are unusable for any significant throughput of text (while xterm and rxvt run like greased lightning).

While I've never benchmarked them, the original NT console running on that same old hardware feels roughly in the same class as xterm. Per the dev response on the Issue, it sounds as though not too much has changed under the hood. If adding support for such typographies would put it in the same performance class as VTE, I'd consider that a serious regression (at least an order of magnitude).

Or are you saying that the Windows terminal has already regressed that far?

Can a mod add (2018) to the title?

Done now!

I often find myself using cmd (the old terminal prompt that is default WSL) on windows. It's not perfect, but I found a patch to enable ANSI color support and it's so much better latency-wise. I hope others work as well in the future; the fancy new much-lauded windows terminal, on the other hand, is to horribly latent for comfortable use (as are many others).

Anyone else notice that typing directly on the tty is much faster than in a terminal emulator in X11?

Sounds like the terminal emulator you're using is no good. Is it the default for your distro?

Yes, without exception. It's less noticeable on today's powerful systems, but it's still true. Text mode is just faster than graphics mode, at least on any system where I've used both.

lol, it crashes when output a lot of text try: yes

I just did. It works fine. How long should I let it run?

this one https://github.com/microsoft/terminal

30 seconds or so

This is about the classic conhost, not the new Windows Terminal.

the one that can't handle ctrl+c to cancel yes? lol

Ctrl-C works fine in WSL on the current/old console.

wsltty is the most underrated app i use on the regular. i was pumped about the new microsoft terminal for all of 5 seconds, then i used it, what a letdown.

with alot of help from wsltty and autohotkey, i am quickly approaching some sort of windows+linux singularity event, https://i.imgur.com/cXykxPN.png

What apps are you using there?

Too bad it doesn’t handle Unicode. Also it’s a shame that it doesn’t have tabs or any hot keys for increasing productivity. It’s really a good shell if you don’t have work to do.

Yeah, that's why I switched to wsltty many many months ago. It has comparable input latency, good hotkey support, clickable URLs, unicode support, etc..

Thank you very much! I will try that out.

Windows terminal preview is another option. It has tabs and is configurable.

I was excited about WSL when I first heard about it. But that excitement quickly faded when I realized most real apps, such as gcc, don't work under it. The best way to get a Linux prompt on Windows is to use Docker. Use the -v option to share your drive.

Most of those issues should be fixed with WSL2 given that it now uses a VM instead of syscall translation/emulation.

Think it'd be worth trying on wsl2 again. The first version was too slow to use, but I am loving wsl 2 now. The integration between windows and the wsl2 vm is a lot more seamless than it used to be. You can navigate the c drive from the wsl shell and also do stuff like `explorer.exe .` to open a windows folder app in the current wsl directory. The vscode integration is amazing as well. After using a mac for many years, it took me about a week to be sold on using a windows laptop from here on out.

I've never had a problem with GCC. GCC is, like, my primary use case.

It's funny, because I quit using WSL because of high latency. I can't say input latency is a big deal to me. I can always wait 100ms for the buffer to catch up with my typing.

But when most commands have 500ms of overhead that is another story. My Xfce4 terminal running in a Hyper V VM is so much faster. If only there were seamless copy-paste. (Incidentally, I tried using Virtualbox but the latency there is more like WSL.)

You could always run VcXsrv to act as an X server.

Then you can launch GUI apps through your Hyper-V based VM (or any hypervisor).

It has seamless clipboard sharing that works out of the box once you enable the option.

I even went as far as running i3wm through VcXsrv for a while but ultimately gave that up since multi-monitor support didn't really work, but if you have 1 monitor it was actually quite usable.

Reply on news.ycombinator.com