What's interesting is that (at the bottom of the stack of JavaScript turtles) xterm.js depends on pty.js. Windows does not provide a pseudoterminal API like Linux, so there is no official way of writing a terminal emulator that behaves like the builtin one (conhost.exe.) Because of this, pty.js uses winpty-agent.exe and winpty-agent.exe does its magic by starting a hidden conhost.exe in the background, effectively screen-scraping it, then writing a sequence of xterm-like control sequences to a pipe that will recreate the state of conhost's screen buffer.
This works well enough in practice, but it relies on a few strange hacks. For example, it writes a marker into the console's backbuffer to detect window scrolling, and it enables mark-mode in the hidden conhost window to "freeze" it while it queries for changes. Also, it's not very robust to changes in the console implementation, so it broke for a little while due to the console changes in Windows 10 (though this was fixed quickly.)
Because of this, it's strange to see Microsoft using it in an official product. I'd love to see them add a proper pseudoterminal (pseudoconsole?) API to Windows 10. There is clearly a need for it.
I suppose if you had the Linux Subsystem enabled, you could host a session there, and I'm sure there are a billion tried and true ways of sharing that session with the built-in VSC terminal.
If the Linux Subsystem were standard, you could depend upon it, but I guess not since it needs to specifically be enabled?
I find it amusing that the stack I'm using to write a systems application is javascript all the way down, from the editor window to the terminal it runs in.
(not bashing. just saying it's amusing. I freakin love VSC.)
Like all high-performance JS VM's their JIT's already emit efficient machine code. If Google, Apple or MS could get JS running any faster they would've.
