14 ms·

Introducing the Windows Pseudo Console (ConPty)

297 points by mnkypete 8y ago

zadjii 8y ago
Hey I'm one of the Console devs who's been working on this feature for a while now. I'll be hanging around in the comments for a little while to try and answer any questions that people might have. TL;DR of this announcement: We've added a new pseudoconsole feature to the Windows Console that will the people create "Terminal" applications on Windows very similarly to how they work on *nix. Terminals will be able to interact with the conpty using only a stream of characters, while commandline applications will be able to keep using the entire console API surface as they always have.
- jamesgeck0 8y ago
  This is awesome. Thank you for all ya'll's hard work!
- llampx 8y ago
  Will this replace Command Prompt or Powershell? Or is this more the back-end for these apps? I believe that we are heading for console overload (in a good way?!) with Command Prompt and Powershell installed on every computer and Debian/Ubuntu available on the MS store.
  - nailer 8y ago
    The back end. Basically people like ConEmu and Hyper and Terminus have been having to use various unreliable hacks for ages because there was no real console API. Now there is one.
  - zadjii 8y ago
    First off: command prompt (cmd.exe) and powershell are commandline client applications. They are shells just the same as bash is. All commandline clients run attached to a console server, and that server is conhost.exe. Conhost is responsible not only for being the console server, but drawing the actual terminal window these apps run in. So when you alunch cmd or powershell, what you're seeing is conhost.exe "hosting" these console applications. What we're exposing here is the "master side" of conhost, which will the other applications act as Terminals, like how there is gnome-terminal, xterm, terminator, etc on linux.
    - paulie_a 8y ago
      Is there any chance cmd and powershell will improve from a user interface perspective? And perhaps become usable? Cmd has been garbage since it's inception.
      - zadjii 8y ago
        cmd is parked for pretty much everything except for major issues. It's a scary codebase that has a LOT of code that's dependent on it, and we can't really add any new features there without the possibility of breaking someone. This feature is mostly focused on the other end of the communication, on being able to create new Terminal windows to run shells inside of them.
        paulie_a 8y ago
        Is there a chance this will be connected to a functional shell interface. I get your point that cmd cannot be upgraded because of legacy issues and that is understandable and unfortunate, but windows needs a proper shell. This is obviously a great start for one side of the equation. But until there is a decent terminal app, windows will continue to be a nonstarter.
        zadjii 8y ago
        It sounds like you're asking for two different things here: cmd.exe is a shell, and that's the guy that's parked. conhost.exe is a terminal, and that's under active development, though it's slower than something like VsCode, because we can't just go adding features as we see fit, we have a LOT of back compat we still need to support. Fortunately, conpty will allow for the creation of new terminal applications on Windows. If you're looking for a better shell experience on windows, I can point you to powershell or even [yori](http://www.malsmith.net/yori/ http://www.malsmith.net/yori/), which looks pretty cool
        cryptonector 8y ago
        I think u/paulie_a is just asking for a better shell. If cmd can't be made better, then make a new one.
- nailer 8y ago
  Zadji I love your work. Which build is this going to land in? Do you know if any of the third party console apps using the new API yet?
  - zadjii 8y ago
    It's already available in current insider's builds, and will be landing officially in the next available Windows release some time later this year. We're still working with ConEmu, VsCode, and OpenSSH to get them all over to the new API, with varying levels of adoption in the next few months likely. Currently, WSL is also using the same functionality, if you open a WSL distro and run any Windows executables (eg `cmd.exe`), they'll run attached to a conpty. I use this as my daily driver.
    - cryptonector 8y ago
      Out of curiosity, are you backporting onto Windows 10, or is Windows 10 the only release vehicle for everything in master? If the latter, how are you releasing piecemeal?
      - zadjii 8y ago
        Pretty much any new features we release are only available on new Windows 10 releases. Unless there's a gigantic demand for a feature, or business impact, we're not really capable on our team of backporting anything.
        cryptonector 8y ago
        What I meant is: are you building a Windows 11, or is Windows 10 the only release vehicle? I'm trying to imagine you pushing to a master branch to integrate into what becomes the insider builds, and then... either those become a future release of Windows 10, or you backport onto a Windows 10 branch. Neither option would be very appealing to me if it was up to me.
        8y ago
- zokier 8y ago
  While it is nice that MS is focusing on console and command line now, it seems to me that you are mostly working on improving compatibility with legacy UNIXy stuff. Do you have some vision or plans to go well beyond the classic UNIXy style of console and command line? I'm thinking in the lines of projects like DomTerm http://domterm.org/ http://domterm.org/ which could have nice interactions with e.g. PowerShell.
  - cryptonector 8y ago
    The ConPTY is not just about compatibility with nix. It's about proper remoting of consoles. Unix got that right / Windows got that wrong, and now Windows will finally get it right too -- that it helps nix compat seems like a happy accident (though obviously they want that too, so not so accidental.
    - quotemstr 8y ago
      Right. For a long time, the MS remoting philosophy was that applications should be remoted, not text streams. The stance goes all the way back to DCOM. That's why PowerShell remoting looks more like a local PowerShell executing commands on a remote machine than it looks like you just connecting to a PowerShell running elsewhere. The difference is important, since in the traditional MS model, each program that wants to do the remote thing needs to essentially implement its own client-server setup, albeit with a massive amount of help from various runtimes. Named pipes and central authentication made this approach not quite as horrible as it sounds. This new API is a departure from this model. It will make it possible to just remote via text streams. Perhaps that's uglier --- everyone knows in-band signaling is fragile. But long experience shows they just remoting the damn text streams is easily the more pragmatic option.
      - cryptonector 8y ago
        I mean, it could be a packet stream where some packets are control packets, and then the Console API could be used and remoted, but you'd need clients that understand it. The fragility of in-band signaling in the TTY world is not *nix's fault or anything. VMS had that too, since VMS too had to deal with TTYs. The fact is that a) the system evolved from real, hardware TTYs of the 1970s, b) using a text stream with some in-band signaling doesn't even half suck -- mostly it rocks, and all you have to do for it to rock is get the right $TERM value and not output binary files to the tty.
- rogerbinns 8y ago
  Have you given thought on how to solve the "unwanted console" problem? For example if you run a .py file (Python) under Windows then you get a console. That is fine for command line stuff, but beyond annoying if the file displays as a gui. So there are now two Python binaries - python.exe and pythonw.exe. The only difference is the latter ensures no console appears. Also good luck if the script printed a help message since often the console disappears before you even know that happened. I presume many tools deal with this issue, and do it in different ways. Perhaps it is as simple as making the console itself only appear once there is any output, or a blocking read of input.
  - zadjii 8y ago
    Technically, any executable that's compiled as a commandline application is going to get a console allocated for it, no matter what on Windows. I don't believe that's something we can fix retroactively unfortunately, that's just a part of how things have to be. Now, I believe that python could have python.exe compiled as a win32 application, then call AllocateConsole as soon as the script called print() or something. If the app was already running in a console, I believe (don't quote me) that AllocateConsole won't allocate a new console for it, but if it doesn't yet have a console it'll spawn one.
    - cryptonector 8y ago
      Why... can't you have I/O redirection to the null device and have it understand (and throw away) Console API messages? You might as well also add some pseudo-device to convert Console API messages into Unix-style text streams (with or without metadata converted to terminal control sequences), so that one could redirect console programs' output to files / pipes. When the user's (programmer's) intent is to run a program with no console window, then that's what they should get: no console window.
    - rossy 8y ago
      I think the behaviour of cmd.exe is part of the problem here. When an interactive cmd.exe launches a console-subsystem app, it waits for the process to finish before showing the prompt again, but when it launches a GUI-subsystem app, cmd.exe writes the prompt again immediately, so even if the new process calls AttachConsole(ATTACH_PARENT_PROCESS) before it tries to write to the console, it will write over cmd.exe's prompt, which makes a poor user experience. So, if someone wants to make a "dual-mode" app that works as a win32-subsystem app when launched from Explorer and a console-subsystem app when launched from a console, they have to choose between two bad options. They can make their app a console-subsystem app, which means a console will always briefly appear on screen when the app is started (no matter how quickly the app calls FreeConsole(),) or they can make their app a GUI-subsystem app (that opportunistically calls AttachConsole(),) which behaves sub-optimally in cmd.exe. Maybe the solution is to add a flag (in the .manifest file?) that makes the console initially hidden for a console-subsystem app. That would prevent the brief appearance of a console window when launching a console-subsystem app from Explorer. Then there would be no need for pythonw.exe and python.exe could show the console window only after a message is printed.
- berbec 8y ago
  Will there be the ability to disown, background, nohup processes and close the console, leaving the commands running?
  - zadjii 8y ago
    Those sound like they'll be more like the responsibility of the terminal emulator, unfortunately. Windows console applications aren't really able to live without being attached to a console. Now, a terminal might be able to implement those features... actually now you've got me thinking. I'll play around with that idea. Definitely non-committal, but it might be possible in the future.
    - cryptonector 8y ago
      I mean, the same is true on Unix. If an app is in the background and wants to write to (or read from) the terminal, it gets SIGTTOU (SIGTTIN) sent to it immediately. It might have to be impossible on Windows to ignore SIGTTOU/SIGTTIN/SIGTSTOP, but I think that's just fine. Mind you, ptys + tmux/similar is certainly very good, and if that's all we'll get that's still way way better than the current state of affairs, but if that's all that will be possible it should at least be possible to pause the console's output (and flow-control the console application).
    - JdeBP 8y ago
      The sad thing is that this was all already implemented and done in Microsoft's second POSIX subsystem for Windows NT. It provided signals and process groups support for job control shells. It had a full control sequence interpreter for output and control sequence generator for extended keys. There were termcap/terminfo database records that people had added to other operating systems. It had a line discipline with "canonical" and "raw" modes. It had pseudo-terminals, with both BSD and System 5 access semantics. * https://technet.microsoft.com/en-gb/library/bb497016.aspx https://technet.microsoft.com/en-gb/library/bb497016.aspx * https://technet.microsoft.com/en-gb/library/bb463219.aspx https://technet.microsoft.com/en-gb/library/bb463219.aspx * https://news.ycombinator.com/item?id=12866843 https://news.ycombinator.com/item?id=12866843 * http://jdebp.info./FGA/interix-terminal-type.html http://jdebp.info./FGA/interix-terminal-type.html And Microsoft owns it.
- quotemstr 8y ago
  Can conhost still do anything that users of the new API can't?
  - zadjii 8y ago
    Excellent question! There are a few limitations that we have to place on the ConPty to make it work quite right. Primarily, client apps running attached to the conpty will not be able to have separate viewport and buffer sizes. On *nix, the entire "console buffer" is just the size of the window, but on Windows, technically, the buffer is much larger than the window. (as an example, when you open up a command prompt, there's a giant empty space at the bottom if you scroll down). Fortunately, we haven't came across any apps that _need_ the buffer to be a different size than the viewport, and it's a technically valid console configuration, so apps should have been able to support it before. Input is also tricky - VT doesn't let you express input with as much fidelity as a console app might be expecting, though this we're working on a solution for :)
    - quotemstr 8y ago
      Now Windows just needs to ship with a decent pager. :-) Programmatic access to scroll back is useful for a few things. For example, back when I was on Windows Phone, I wrote a compiler wrapper that would scroll back to the first error message. It'd be nice for the POSIX terminal world to standardize on similar scrollback access. I know the zsh people would love it.
    - caf 8y ago
      *nix consoles typically have two buffers - many full-screen temrinal applications switch to the "alternate screen" on start and back to the principal screen on exit. That's why when you exit vim(1), you see the terminal state back as it was before you started it. Will ConPty support this?
      - cryptonector 8y ago
        I hate the alternate screen with a passion.
- theclaw 8y ago
  I'm unclear as to whether I'll be able to pipe binary data between a classic console application and a ConPTY application due to the VT translation and rendering components in ConHost. So, for example if I was to pipe into 7z.exe, a classic console app, using something like "type mybinaryfile.bin | 7z.exe a -si c:\temp\myarchive.7z" from a ConPTY console, would the VT translation affect the piped stream?
  - zadjii 8y ago
    Nope! We're only rendering the effect of any attached processes to the VT on the conpty side of things. On the client side (where cmd, type, 7z.exe are all running), they're going to keep working just the same as they always have. They're all running on the "slave" side of conpty, while the emitted VT is coming from the "master" side of the conpty.
docode 8y ago
Where can we try a .NET solution with this ConPty?
linuxlizard 8y ago
This is very exciting. I'm looking forward to seeing where it goes.
cryptonector 8y ago
What next? Job control signals?? :) (EDIT: How about tmux?) Anyways, this is fantastic. Finally, proper ssh functionality! This will encourage development of console (text-oriented) apps for Windows, which I hope will be much simpler. Interfacing with the console can be really difficult if you're coming from *nix. Ideally all the WIN32-specific code in, e.g., jq[0], could be ripped out. [0] https://github.com/stedolan/jq https://github.com/stedolan/jq (look in src/main.c)
- tom_ 8y ago
  The lack of signals in Windows is the very opposite of a flaw! - Windows has just never pretended you can get away without a message loop.
  - quotemstr 8y ago
    Windows does have signals! It just splits them into a few facilities. POSIX "synchronous" signals correspond to SEH exceptions and can be handled roughly the same way --- except that signals have process global handlers and Windows has thread-local ones, because the glibc people are sticks in the mud and are hostile to any attempt to make signals suck less. For asynchronous signals, like SIGINT, Windows create a new thread out of thin air to deliver your app a notification. That's not really all that much better than a signal from a concurrency perspective. Windows even has APCs, which are like regular signals that are delivered only at explicit system call boundaries. Every operating system needs some mechanism to tell a process to do something. Windows has evolved an approach that isn't all that different from Unix signal handling.
    - cryptonector 8y ago
      Spawning a new thread to handle a signal is much better than preemption: you then have no concerns about async-signal-safety that aren't plain old thread-safety concerns. I'd much rather have thread-safety constraints than async-signal-safety constraints.
      - 8y ago
hoppelhase 8y ago
If I use the System.Process API in .NET and redirect the Stdin/Stdout to a stream inside my application, does the framework spawn an invisible console and scrape the output? Or does this work differently? I always did it that way and thought the 3rd party terminal emulators also do that. Why do these emulators have to do it differently?
- quotemstr 8y ago
  That API is using pipes.
quotemstr 8y ago
Finally! I've been waiting ten years or so for this API. It's about time that alternative terminal emulation becomes possible on Windows.
21 8y ago
Does this mean that it will now be easy to port terminator to windows?
- zadjii 8y ago
  I sure hope so! I can run cmd.exe inside gnome-terminal running on WSL right now - granted, WSL is doing some magic to make that all work, but it should still work for terminator to do it to.
nasoieu 8y ago
Something looks very eerie in that Admiral Grace Hopper picture. Is it shopped?
hoppelhase 8y ago
I always liked the Console API where you can set the color of the text without actually changing the text that is written to Stdout. No issues when piping the output somewhere else. No need to check whether the output is getting piped.
- zadjii 8y ago
  That'll work just the same as it always has :) Existing commandline applications won't be affected by this feature, but it will open the doors for an entirely new class of applications.
  - hoppelhase 8y ago
    The existing Console API won't be extended with features of VT codes, or will it?
    - zadjii 8y ago
      Oh we added support for VT sequences in commandline apps years ago - case in point, WSL. see [this docs page](https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences https://docs.microsoft.com/en-us/windows/console/console-vir...) for a (surprisingly incomplete) list of VT sequences we support, and how to use them.
amluto 8y ago
For me, the most surprising thing is that the new PTY devices use UTF-8. Not UTF-16 or UCS-2 or weird little endian variants thereof, and not even wchar_t. This is so un-Windows-like.
- zadjii 8y ago
  It is! But this is a very un-windows like feature, isn't it? We want this to work on other platforms with as little modification as necessary, and frankly, jumping through the wchar_t<->char hoops is a _pain_. So we'll do it for you!
  - cryptonector 8y ago
    Hear hear! wchar_t is a disaster. UTF-16 is terrible. I'm not at all convinced that 2^21 codepoints will be enough, so someday it'd be nice to be able to get past UTF-16 and move to UTF-8, and Windows and ECMAScript are the biggest impediments to that. Your choice of UTF-8 will tend to place UTF-8 on a level playing field in Win32. I guess, too, that this is the end of codepages -- I doubt they'd go away, but there should be no more need to struggle with them, just use UTF-8. You'll still need a semblance of locale, for localization purposes, naturally, but all-UTF-8-all-the-time is a great simplification.
    - deleted 8y ago
      [deleted]
    - mehrdadn 8y ago
      Confused, where does 2^21 code points come from and how is that related to the UTF-16 vs. UTF-8 distinction? Can't both of them encode all Unicode code points? Or are you thinking of code units perhaps, and UCS-2? Although even there I'm confused where the 2^21 came from.
      - speeder 8y ago
        Utf-16 is always 16 bit, utf-8 is variable, can go from 8 to 32 as needed... This does make coding for utf-8 harder, but when it works is really wonderful stuff.
JdeBP 8y ago
I've been waiting for two decades to revise this particular Frequently Given Answer. * http://jdebp.info./FGA/capture-console-win32.html http://jdebp.info./FGA/capture-console-win32.html
- red75prime 8y ago
  I suppose it's mostly TUI programs, which use low level console API. So did you try to capture output of something like Far Manager[0]? If so, will it be much simpler to parse escape sequences of VT100? [0] https://farmanager.com/ https://farmanager.com/
ChuckMcM 8y ago
This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wish this had happened 10 years ago but hey, I'll take it.
- cryptonector 8y ago
  It's the reality of the market, which is why Windows is adding Linux compatibility (as is every *BSD, Illumos, ...). But also it's the fact that three decades of not even life support has left the Windows console in pretty sad shape -- the folks tasked with getting it into better shape were bound to see the value of ptys. Lastly, don't forget that Windows NT was meant to be a console OS, like VMS. There must still be people, even if very few, at MSFT who appreciate text-oriented apps. For me, the tty/pty, shells, screen/tmux/..., ssh, and so on, are the things that make Unix so powerful. The fact is that Win32 is far superior in a number of areas (SIDs >> UIDs/GIDs, security descriptors >> {owner, group, mode, [ACL]}, access tokens >> struct cred), but far inferior in the things that really matter to a power user trying to get things done.
  - pjmlp 8y ago
    As power user that gets things done on Windows, it never bothered me that it hasn't an UNIX like console. If fact it bothered me more that I couldn't get a Borland like devenv on Linux and had to keep myself happy with XEmacs.
  - SideburnsOfDoom 8y ago
    > Lastly, don't forget that Windows NT was meant to be a console OS, like VMS. There must still be people, even if very few, at MSFT who appreciate text-oriented apps. I expect that, like Linux compatibility, most of it is not about "apps" but about being better at running in the cloud, where a (virtual) machine or container needs to be as light as possible, and to be configured and a service launched in it as unattended/automated manner as possible. Stripping out the GUI and making command lines work better works towards these goals.
caf 8y ago
Will there be a terminfo database entry for ConPty? What TERM string should we expect to see? To elaborate: although an ordinary POSIX pty doesn't inherently have a terminal type - that's entirely down to whatever emulator is connected to the master side - the way the ConPty system translates Console API calls into terminal control codes means that it necessarily needs to pick a terminal emulation, which all actors in the ConPty system are expected to use. A terminfo database entry would be useful both for applications running on *NIX hosts but displaying on a remote ConPty master somewhere, as well as for porting existing terminal applications to Windows where they will run on a ConPty slave. As a follow-up question, presumably this means that the SSHD running on Windows as a ConPty master needs to translate between whatever terminal emulation the ssh client is connected to and the one expected by ConPty / ConPty apps (in the same way it must translate between the native ConPty UTF-8 and the remote charset)?
- cryptonector 8y ago
  I second this question. Perhaps there will only be support for vt100/vt220?
  - lokedhs 8y ago
    That would be sad, as there is already far too much software out there that hard-codes escape sequences, completely ignoring the TERM environment variable. Even worse, sometimes they won't even disable escape codes when they should not be displayed. I've posted bug reports for very popular software packages whose commandline always output vt102, even when TERM is set to dumb or when run through pipes. That makes grepping for error messages somewhat annoying. In at least some cases these reports were ignored.
- zadjii 8y ago
  So this question is a little complicated currently, but I want you to know that I am planning on coming back to answer it, probably tomorrow morning
- voltagex_ 8y ago
  Add an issue: https://github.com/microsoft/console/issues https://github.com/microsoft/console/issues
partycoder 8y ago
HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size); If Microsoft is in the mood to fix old problems, right ^there you've got another old problem: its bizarre API that is different to everything else. Designed that way to lock everyone into their OS. In 2018 nobody has the time to learn this. Just use a cross-platform API and if it doesn't run on Windows then just don't run Windows. As a developer, using Windows for development is against your own best interest. If you like to be treated as a dog that is not allowed inside the house, use Windows.
- Jasper_ 8y ago
  What cross-platform API would that be? ioctl(tty_fd, TIOCSWINSZ, &size); ? How does the user get the TTY FD? open("/dev/tty0")? Or should they implement SYSV compatibility and use "/dev/vt0"? Or perhaps follow FreeBSD, which has "/dev/ttyv0"?
- zadjii 8y ago
  Honestly, learning Windows is just like learning another programming language. This API is designed to be the Windows equivalent of a unix API - of course it's not going to be the exact same thing, but functionally it does the same thing.
asveikau 8y ago
While we're talking Unixisms, Windows needs a dup2(2). That is, given a HANDLE, you should be able to swap out its backing kernel data structure with that of another HANDLE. Without this, I/O redirection is slightly broken. Last I checked you can't change where stderr goes after the process starts, for example. [SetStdHandle doesn't do it at the right layer.]
exikyut 8y ago
Wow. I remember the photo miniksa posted to GitHub when this was in process: https://github.com/Microsoft/WSL/issues/111#issuecomment-238592841 https://github.com/Microsoft/WSL/issues/111#issuecomment-238... Awesome to see it's finally up and running! \o/
voltagex_ 8y ago
Wow, there might be able to be a proper ncurses port now!
- lambdas 8y ago
  No termcaps which ncurses depends on though so I don't think so
- zadjii 8y ago
  Functionally, we support all of the VT sequences you'd need to make ncurses work resonably well on windows for a few releases now (ever since WSL was introduced). If you could build an ncurses that assumed TERM=xterm-256color, then you might be able to get it to work on windows.
kpil 8y ago
-- Those who don't understand Unix are condemned to reinvent it, poorly. Henry Spencer
- oblio 8y ago
  This is such a cliché. Do you think that the people who implemented the Windows Console, especially the people working on Windows NT, did not know about Unix? People try different approaches, sometimes they don't work out. And it's not like Unix is the Word of God, anyway, it has plenty of flaws. (Yeah, after a long time on internet forums I get kind of touchy after someone copy-pastes the same old and tired line.)
  - gaius 8y ago
    Microsoft understood Unix very well, Xenix was a product of theirs in the 80’s
  - JdeBP 8y ago
    The problem is that in this case it's not understanding Microsoft's own prior software that condemns one to reinvent it. Microsoft's second POSIX subsystem for Windows NT, a.k.a. Interix, had all of this.
  - kpil 8y ago
    Since it took them 20 years to make a half-decent shell and 30 years how to figure out how stdout should work: no they had no clue. Maybe they knew how a kernel should work though, but weren't the NT guys old VMS guys? That's a totally un-unixy OS actually.
    - c487bd62 8y ago
      It's all about pushing Azure and dedicating resources to said goals
    - oblio 8y ago
      1. They didn't care about command line tools, in many ways (usability) they're a huge regression. After all, it was in the name of the product: Windows. 2. Who says that in-band communication like Unix is doing is necessarily better? See pastejacking and other shenanigans.
red75prime 8y ago
I hope control-S (XOFF) is disabled by default.
mschuster91 8y ago
Is there any way to get this backported to Windows 7 - or run a W7 userland on top of a W10 kernel? I'm actually serious about this one, I can't stand this semi-"mobile-first", flat UI of newer Windows generations, and the privacy invasions and ads are other hard blockers for me - but that WSL layer or the new console subsystem seem to be pretty nice features.
mobilehnuser 8y ago
Thanks to WSL and this, I'm very hopeful that my next development laptop can be a windows device
OnlyRepliesToBS 8y ago
They're going to fuck up console like they fucked up the Registery, COM+, WPF, DirectDraw, Silverlight, WCF, etc... It will be a clusterfuck of weird syntax that no doubt will embrace and extend what a console can do but then become proprietary as fuck. Watch. Cycle repeat.
borekb 8y ago
I currently use ConEmu + zsh via MSYS2 as my preferred shell on Windows. I need to run many interactive programs like `python`, `node` etc. via winpty, e.g.: ``` alias node='winpty node.cmd' ``` With the new ConPTY, will I be able to run native Windows programs directly? If so, that would be huge, winpty (while I'm really thankful it exists) is a PITA in practice, see e.g. https://github.com/Microsoft/vscode/issues/45693 https://github.com/Microsoft/vscode/issues/45693.

297 points by mnkypete 8y ago

Hey I'm one of the Console devs who's been working on this feature for a while now. I'll be hanging around in the comments for a little while to try and answer any questions that people might have. TL;DR of this announcement: We've added a new pseudoconsole feature to the Windows Console that will the people create "Terminal" applications on Windows very similarly to how they work on *nix. Terminals will be able to interact with the conpty using only a stream of characters, while commandline applications will be able to keep using the entire console API surface as they always have.

jamesgeck0 8y ago
This is awesome. Thank you for all ya'll's hard work!
llampx 8y ago
Will this replace Command Prompt or Powershell? Or is this more the back-end for these apps? I believe that we are heading for console overload (in a good way?!) with Command Prompt and Powershell installed on every computer and Debian/Ubuntu available on the MS store.
- nailer 8y ago
  The back end. Basically people like ConEmu and Hyper and Terminus have been having to use various unreliable hacks for ages because there was no real console API. Now there is one.
- zadjii 8y ago
  First off: command prompt (cmd.exe) and powershell are commandline client applications. They are shells just the same as bash is. All commandline clients run attached to a console server, and that server is conhost.exe. Conhost is responsible not only for being the console server, but drawing the actual terminal window these apps run in. So when you alunch cmd or powershell, what you're seeing is conhost.exe "hosting" these console applications. What we're exposing here is the "master side" of conhost, which will the other applications act as Terminals, like how there is gnome-terminal, xterm, terminator, etc on linux.
  - paulie_a 8y ago
    Is there any chance cmd and powershell will improve from a user interface perspective? And perhaps become usable? Cmd has been garbage since it's inception.
    - zadjii 8y ago
      cmd is parked for pretty much everything except for major issues. It's a scary codebase that has a LOT of code that's dependent on it, and we can't really add any new features there without the possibility of breaking someone. This feature is mostly focused on the other end of the communication, on being able to create new Terminal windows to run shells inside of them.
      - paulie_a 8y ago
        Is there a chance this will be connected to a functional shell interface. I get your point that cmd cannot be upgraded because of legacy issues and that is understandable and unfortunate, but windows needs a proper shell. This is obviously a great start for one side of the equation. But until there is a decent terminal app, windows will continue to be a nonstarter.
        zadjii 8y ago
        It sounds like you're asking for two different things here: cmd.exe is a shell, and that's the guy that's parked. conhost.exe is a terminal, and that's under active development, though it's slower than something like VsCode, because we can't just go adding features as we see fit, we have a LOT of back compat we still need to support. Fortunately, conpty will allow for the creation of new terminal applications on Windows. If you're looking for a better shell experience on windows, I can point you to powershell or even [yori](http://www.malsmith.net/yori/ http://www.malsmith.net/yori/), which looks pretty cool
        cryptonector 8y ago
        I think u/paulie_a is just asking for a better shell. If cmd can't be made better, then make a new one.
nailer 8y ago
Zadji I love your work. Which build is this going to land in? Do you know if any of the third party console apps using the new API yet?
- zadjii 8y ago
  It's already available in current insider's builds, and will be landing officially in the next available Windows release some time later this year. We're still working with ConEmu, VsCode, and OpenSSH to get them all over to the new API, with varying levels of adoption in the next few months likely. Currently, WSL is also using the same functionality, if you open a WSL distro and run any Windows executables (eg `cmd.exe`), they'll run attached to a conpty. I use this as my daily driver.
  - cryptonector 8y ago
    Out of curiosity, are you backporting onto Windows 10, or is Windows 10 the only release vehicle for everything in master? If the latter, how are you releasing piecemeal?
    - zadjii 8y ago
      Pretty much any new features we release are only available on new Windows 10 releases. Unless there's a gigantic demand for a feature, or business impact, we're not really capable on our team of backporting anything.
      - cryptonector 8y ago
        What I meant is: are you building a Windows 11, or is Windows 10 the only release vehicle? I'm trying to imagine you pushing to a master branch to integrate into what becomes the insider builds, and then... either those become a future release of Windows 10, or you backport onto a Windows 10 branch. Neither option would be very appealing to me if it was up to me.
        8y ago
zokier 8y ago
While it is nice that MS is focusing on console and command line now, it seems to me that you are mostly working on improving compatibility with legacy UNIXy stuff. Do you have some vision or plans to go well beyond the classic UNIXy style of console and command line? I'm thinking in the lines of projects like DomTerm http://domterm.org/ http://domterm.org/ which could have nice interactions with e.g. PowerShell.
- cryptonector 8y ago
  The ConPTY is not just about compatibility with nix. It's about proper remoting of consoles. Unix got that right / Windows got that wrong, and now Windows will finally get it right too -- that it helps nix compat seems like a happy accident (though obviously they want that too, so not so accidental.
  - quotemstr 8y ago
    Right. For a long time, the MS remoting philosophy was that applications should be remoted, not text streams. The stance goes all the way back to DCOM. That's why PowerShell remoting looks more like a local PowerShell executing commands on a remote machine than it looks like you just connecting to a PowerShell running elsewhere. The difference is important, since in the traditional MS model, each program that wants to do the remote thing needs to essentially implement its own client-server setup, albeit with a massive amount of help from various runtimes. Named pipes and central authentication made this approach not quite as horrible as it sounds. This new API is a departure from this model. It will make it possible to just remote via text streams. Perhaps that's uglier --- everyone knows in-band signaling is fragile. But long experience shows they just remoting the damn text streams is easily the more pragmatic option.
    - cryptonector 8y ago
      I mean, it could be a packet stream where some packets are control packets, and then the Console API could be used and remoted, but you'd need clients that understand it. The fragility of in-band signaling in the TTY world is not *nix's fault or anything. VMS had that too, since VMS too had to deal with TTYs. The fact is that a) the system evolved from real, hardware TTYs of the 1970s, b) using a text stream with some in-band signaling doesn't even half suck -- mostly it rocks, and all you have to do for it to rock is get the right $TERM value and not output binary files to the tty.
rogerbinns 8y ago
Have you given thought on how to solve the "unwanted console" problem? For example if you run a .py file (Python) under Windows then you get a console. That is fine for command line stuff, but beyond annoying if the file displays as a gui. So there are now two Python binaries - python.exe and pythonw.exe. The only difference is the latter ensures no console appears. Also good luck if the script printed a help message since often the console disappears before you even know that happened. I presume many tools deal with this issue, and do it in different ways. Perhaps it is as simple as making the console itself only appear once there is any output, or a blocking read of input.
- zadjii 8y ago
  Technically, any executable that's compiled as a commandline application is going to get a console allocated for it, no matter what on Windows. I don't believe that's something we can fix retroactively unfortunately, that's just a part of how things have to be. Now, I believe that python could have python.exe compiled as a win32 application, then call AllocateConsole as soon as the script called print() or something. If the app was already running in a console, I believe (don't quote me) that AllocateConsole won't allocate a new console for it, but if it doesn't yet have a console it'll spawn one.
  - cryptonector 8y ago
    Why... can't you have I/O redirection to the null device and have it understand (and throw away) Console API messages? You might as well also add some pseudo-device to convert Console API messages into Unix-style text streams (with or without metadata converted to terminal control sequences), so that one could redirect console programs' output to files / pipes. When the user's (programmer's) intent is to run a program with no console window, then that's what they should get: no console window.
  - rossy 8y ago
    I think the behaviour of cmd.exe is part of the problem here. When an interactive cmd.exe launches a console-subsystem app, it waits for the process to finish before showing the prompt again, but when it launches a GUI-subsystem app, cmd.exe writes the prompt again immediately, so even if the new process calls AttachConsole(ATTACH_PARENT_PROCESS) before it tries to write to the console, it will write over cmd.exe's prompt, which makes a poor user experience. So, if someone wants to make a "dual-mode" app that works as a win32-subsystem app when launched from Explorer and a console-subsystem app when launched from a console, they have to choose between two bad options. They can make their app a console-subsystem app, which means a console will always briefly appear on screen when the app is started (no matter how quickly the app calls FreeConsole(),) or they can make their app a GUI-subsystem app (that opportunistically calls AttachConsole(),) which behaves sub-optimally in cmd.exe. Maybe the solution is to add a flag (in the .manifest file?) that makes the console initially hidden for a console-subsystem app. That would prevent the brief appearance of a console window when launching a console-subsystem app from Explorer. Then there would be no need for pythonw.exe and python.exe could show the console window only after a message is printed.
berbec 8y ago
Will there be the ability to disown, background, nohup processes and close the console, leaving the commands running?
- zadjii 8y ago
  Those sound like they'll be more like the responsibility of the terminal emulator, unfortunately. Windows console applications aren't really able to live without being attached to a console. Now, a terminal might be able to implement those features... actually now you've got me thinking. I'll play around with that idea. Definitely non-committal, but it might be possible in the future.
  - cryptonector 8y ago
    I mean, the same is true on Unix. If an app is in the background and wants to write to (or read from) the terminal, it gets SIGTTOU (SIGTTIN) sent to it immediately. It might have to be impossible on Windows to ignore SIGTTOU/SIGTTIN/SIGTSTOP, but I think that's just fine. Mind you, ptys + tmux/similar is certainly very good, and if that's all we'll get that's still way way better than the current state of affairs, but if that's all that will be possible it should at least be possible to pause the console's output (and flow-control the console application).
  - JdeBP 8y ago
    The sad thing is that this was all already implemented and done in Microsoft's second POSIX subsystem for Windows NT. It provided signals and process groups support for job control shells. It had a full control sequence interpreter for output and control sequence generator for extended keys. There were termcap/terminfo database records that people had added to other operating systems. It had a line discipline with "canonical" and "raw" modes. It had pseudo-terminals, with both BSD and System 5 access semantics. * https://technet.microsoft.com/en-gb/library/bb497016.aspx https://technet.microsoft.com/en-gb/library/bb497016.aspx * https://technet.microsoft.com/en-gb/library/bb463219.aspx https://technet.microsoft.com/en-gb/library/bb463219.aspx * https://news.ycombinator.com/item?id=12866843 https://news.ycombinator.com/item?id=12866843 * http://jdebp.info./FGA/interix-terminal-type.html http://jdebp.info./FGA/interix-terminal-type.html And Microsoft owns it.
quotemstr 8y ago
Can conhost still do anything that users of the new API can't?
- zadjii 8y ago
  Excellent question! There are a few limitations that we have to place on the ConPty to make it work quite right. Primarily, client apps running attached to the conpty will not be able to have separate viewport and buffer sizes. On *nix, the entire "console buffer" is just the size of the window, but on Windows, technically, the buffer is much larger than the window. (as an example, when you open up a command prompt, there's a giant empty space at the bottom if you scroll down). Fortunately, we haven't came across any apps that _need_ the buffer to be a different size than the viewport, and it's a technically valid console configuration, so apps should have been able to support it before. Input is also tricky - VT doesn't let you express input with as much fidelity as a console app might be expecting, though this we're working on a solution for :)
  - quotemstr 8y ago
    Now Windows just needs to ship with a decent pager. :-) Programmatic access to scroll back is useful for a few things. For example, back when I was on Windows Phone, I wrote a compiler wrapper that would scroll back to the first error message. It'd be nice for the POSIX terminal world to standardize on similar scrollback access. I know the zsh people would love it.
  - caf 8y ago
    *nix consoles typically have two buffers - many full-screen temrinal applications switch to the "alternate screen" on start and back to the principal screen on exit. That's why when you exit vim(1), you see the terminal state back as it was before you started it. Will ConPty support this?
    - cryptonector 8y ago
      I hate the alternate screen with a passion.
theclaw 8y ago
I'm unclear as to whether I'll be able to pipe binary data between a classic console application and a ConPTY application due to the VT translation and rendering components in ConHost. So, for example if I was to pipe into 7z.exe, a classic console app, using something like "type mybinaryfile.bin | 7z.exe a -si c:\temp\myarchive.7z" from a ConPTY console, would the VT translation affect the piped stream?
- zadjii 8y ago
  Nope! We're only rendering the effect of any attached processes to the VT on the conpty side of things. On the client side (where cmd, type, 7z.exe are all running), they're going to keep working just the same as they always have. They're all running on the "slave" side of conpty, while the emitted VT is coming from the "master" side of the conpty.

docode 8y ago

Where can we try a .NET solution with this ConPty?

linuxlizard 8y ago

This is very exciting. I'm looking forward to seeing where it goes.

cryptonector 8y ago

What next? Job control signals?? :) (EDIT: How about tmux?) Anyways, this is fantastic. Finally, proper ssh functionality! This will encourage development of console (text-oriented) apps for Windows, which I hope will be much simpler. Interfacing with the console can be really difficult if you're coming from *nix. Ideally all the WIN32-specific code in, e.g., jq[0], could be ripped out. [0] https://github.com/stedolan/jq https://github.com/stedolan/jq (look in src/main.c)

tom_ 8y ago
The lack of signals in Windows is the very opposite of a flaw! - Windows has just never pretended you can get away without a message loop.
- quotemstr 8y ago
  Windows does have signals! It just splits them into a few facilities. POSIX "synchronous" signals correspond to SEH exceptions and can be handled roughly the same way --- except that signals have process global handlers and Windows has thread-local ones, because the glibc people are sticks in the mud and are hostile to any attempt to make signals suck less. For asynchronous signals, like SIGINT, Windows create a new thread out of thin air to deliver your app a notification. That's not really all that much better than a signal from a concurrency perspective. Windows even has APCs, which are like regular signals that are delivered only at explicit system call boundaries. Every operating system needs some mechanism to tell a process to do something. Windows has evolved an approach that isn't all that different from Unix signal handling.
  - cryptonector 8y ago
    Spawning a new thread to handle a signal is much better than preemption: you then have no concerns about async-signal-safety that aren't plain old thread-safety concerns. I'd much rather have thread-safety constraints than async-signal-safety constraints.
    - 8y ago

hoppelhase 8y ago

If I use the System.Process API in .NET and redirect the Stdin/Stdout to a stream inside my application, does the framework spawn an invisible console and scrape the output? Or does this work differently? I always did it that way and thought the 3rd party terminal emulators also do that. Why do these emulators have to do it differently?

quotemstr 8y ago
That API is using pipes.

quotemstr 8y ago

Finally! I've been waiting ten years or so for this API. It's about time that alternative terminal emulation becomes possible on Windows.

21 8y ago

Does this mean that it will now be easy to port terminator to windows?

zadjii 8y ago
I sure hope so! I can run cmd.exe inside gnome-terminal running on WSL right now - granted, WSL is doing some magic to make that all work, but it should still work for terminator to do it to.

nasoieu 8y ago

Something looks very eerie in that Admiral Grace Hopper picture. Is it shopped?

hoppelhase 8y ago

I always liked the Console API where you can set the color of the text without actually changing the text that is written to Stdout. No issues when piping the output somewhere else. No need to check whether the output is getting piped.

zadjii 8y ago
That'll work just the same as it always has :) Existing commandline applications won't be affected by this feature, but it will open the doors for an entirely new class of applications.
- hoppelhase 8y ago
  The existing Console API won't be extended with features of VT codes, or will it?
  - zadjii 8y ago
    Oh we added support for VT sequences in commandline apps years ago - case in point, WSL. see [this docs page](https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences https://docs.microsoft.com/en-us/windows/console/console-vir...) for a (surprisingly incomplete) list of VT sequences we support, and how to use them.

amluto 8y ago

For me, the most surprising thing is that the new PTY devices use UTF-8. Not UTF-16 or UCS-2 or weird little endian variants thereof, and not even wchar_t. This is so un-Windows-like.

zadjii 8y ago
It is! But this is a very un-windows like feature, isn't it? We want this to work on other platforms with as little modification as necessary, and frankly, jumping through the wchar_t<->char hoops is a _pain_. So we'll do it for you!
- cryptonector 8y ago
  Hear hear! wchar_t is a disaster. UTF-16 is terrible. I'm not at all convinced that 2^21 codepoints will be enough, so someday it'd be nice to be able to get past UTF-16 and move to UTF-8, and Windows and ECMAScript are the biggest impediments to that. Your choice of UTF-8 will tend to place UTF-8 on a level playing field in Win32. I guess, too, that this is the end of codepages -- I doubt they'd go away, but there should be no more need to struggle with them, just use UTF-8. You'll still need a semblance of locale, for localization purposes, naturally, but all-UTF-8-all-the-time is a great simplification.
  - deleted 8y ago
    [deleted]
  - mehrdadn 8y ago
    Confused, where does 2^21 code points come from and how is that related to the UTF-16 vs. UTF-8 distinction? Can't both of them encode all Unicode code points? Or are you thinking of code units perhaps, and UCS-2? Although even there I'm confused where the 2^21 came from.
    - speeder 8y ago
      Utf-16 is always 16 bit, utf-8 is variable, can go from 8 to 32 as needed... This does make coding for utf-8 harder, but when it works is really wonderful stuff.

JdeBP 8y ago

I've been waiting for two decades to revise this particular Frequently Given Answer. * http://jdebp.info./FGA/capture-console-win32.html http://jdebp.info./FGA/capture-console-win32.html

red75prime 8y ago
I suppose it's mostly TUI programs, which use low level console API. So did you try to capture output of something like Far Manager[0]? If so, will it be much simpler to parse escape sequences of VT100? [0] https://farmanager.com/ https://farmanager.com/

ChuckMcM 8y ago

This is pretty huge. For as long as I can remember the response to command line applications talking to command line applications was "Why would you want to do that? Use (RPC | shared memory | some other IPC mechanism)." And nobody at Microsoft seemed to understand how much simpler it was to use ptys. They seem to have completely capitulated to the notion ptys and are dropping them into the next release of W10. I wish this had happened 10 years ago but hey, I'll take it.

cryptonector 8y ago
It's the reality of the market, which is why Windows is adding Linux compatibility (as is every *BSD, Illumos, ...). But also it's the fact that three decades of not even life support has left the Windows console in pretty sad shape -- the folks tasked with getting it into better shape were bound to see the value of ptys. Lastly, don't forget that Windows NT was meant to be a console OS, like VMS. There must still be people, even if very few, at MSFT who appreciate text-oriented apps. For me, the tty/pty, shells, screen/tmux/..., ssh, and so on, are the things that make Unix so powerful. The fact is that Win32 is far superior in a number of areas (SIDs >> UIDs/GIDs, security descriptors >> {owner, group, mode, [ACL]}, access tokens >> struct cred), but far inferior in the things that really matter to a power user trying to get things done.
- pjmlp 8y ago
  As power user that gets things done on Windows, it never bothered me that it hasn't an UNIX like console. If fact it bothered me more that I couldn't get a Borland like devenv on Linux and had to keep myself happy with XEmacs.
- SideburnsOfDoom 8y ago
  > Lastly, don't forget that Windows NT was meant to be a console OS, like VMS. There must still be people, even if very few, at MSFT who appreciate text-oriented apps. I expect that, like Linux compatibility, most of it is not about "apps" but about being better at running in the cloud, where a (virtual) machine or container needs to be as light as possible, and to be configured and a service launched in it as unattended/automated manner as possible. Stripping out the GUI and making command lines work better works towards these goals.

caf 8y ago

Will there be a terminfo database entry for ConPty? What TERM string should we expect to see? To elaborate: although an ordinary POSIX pty doesn't inherently have a terminal type - that's entirely down to whatever emulator is connected to the master side - the way the ConPty system translates Console API calls into terminal control codes means that it necessarily needs to pick a terminal emulation, which all actors in the ConPty system are expected to use. A terminfo database entry would be useful both for applications running on *NIX hosts but displaying on a remote ConPty master somewhere, as well as for porting existing terminal applications to Windows where they will run on a ConPty slave. As a follow-up question, presumably this means that the SSHD running on Windows as a ConPty master needs to translate between whatever terminal emulation the ssh client is connected to and the one expected by ConPty / ConPty apps (in the same way it must translate between the native ConPty UTF-8 and the remote charset)?

cryptonector 8y ago
I second this question. Perhaps there will only be support for vt100/vt220?
- lokedhs 8y ago
  That would be sad, as there is already far too much software out there that hard-codes escape sequences, completely ignoring the TERM environment variable. Even worse, sometimes they won't even disable escape codes when they should not be displayed. I've posted bug reports for very popular software packages whose commandline always output vt102, even when TERM is set to dumb or when run through pipes. That makes grepping for error messages somewhat annoying. In at least some cases these reports were ignored.
zadjii 8y ago
So this question is a little complicated currently, but I want you to know that I am planning on coming back to answer it, probably tomorrow morning
voltagex_ 8y ago
Add an issue: https://github.com/microsoft/console/issues https://github.com/microsoft/console/issues

partycoder 8y ago

HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size); If Microsoft is in the mood to fix old problems, right ^there you've got another old problem: its bizarre API that is different to everything else. Designed that way to lock everyone into their OS. In 2018 nobody has the time to learn this. Just use a cross-platform API and if it doesn't run on Windows then just don't run Windows. As a developer, using Windows for development is against your own best interest. If you like to be treated as a dog that is not allowed inside the house, use Windows.

Jasper_ 8y ago
What cross-platform API would that be? ioctl(tty_fd, TIOCSWINSZ, &size); ? How does the user get the TTY FD? open("/dev/tty0")? Or should they implement SYSV compatibility and use "/dev/vt0"? Or perhaps follow FreeBSD, which has "/dev/ttyv0"?
zadjii 8y ago
Honestly, learning Windows is just like learning another programming language. This API is designed to be the Windows equivalent of a unix API - of course it's not going to be the exact same thing, but functionally it does the same thing.

asveikau 8y ago

While we're talking Unixisms, Windows needs a dup2(2). That is, given a HANDLE, you should be able to swap out its backing kernel data structure with that of another HANDLE. Without this, I/O redirection is slightly broken. Last I checked you can't change where stderr goes after the process starts, for example. [SetStdHandle doesn't do it at the right layer.]

exikyut 8y ago

Wow. I remember the photo miniksa posted to GitHub when this was in process: https://github.com/Microsoft/WSL/issues/111#issuecomment-238592841 https://github.com/Microsoft/WSL/issues/111#issuecomment-238... Awesome to see it's finally up and running! \o/

voltagex_ 8y ago

Wow, there might be able to be a proper ncurses port now!

lambdas 8y ago
No termcaps which ncurses depends on though so I don't think so
zadjii 8y ago
Functionally, we support all of the VT sequences you'd need to make ncurses work resonably well on windows for a few releases now (ever since WSL was introduced). If you could build an ncurses that assumed TERM=xterm-256color, then you might be able to get it to work on windows.

kpil 8y ago

-- Those who don't understand Unix are condemned to reinvent it, poorly. Henry Spencer

oblio 8y ago
This is such a cliché. Do you think that the people who implemented the Windows Console, especially the people working on Windows NT, did not know about Unix? People try different approaches, sometimes they don't work out. And it's not like Unix is the Word of God, anyway, it has plenty of flaws. (Yeah, after a long time on internet forums I get kind of touchy after someone copy-pastes the same old and tired line.)
- gaius 8y ago
  Microsoft understood Unix very well, Xenix was a product of theirs in the 80’s
- JdeBP 8y ago
  The problem is that in this case it's not understanding Microsoft's own prior software that condemns one to reinvent it. Microsoft's second POSIX subsystem for Windows NT, a.k.a. Interix, had all of this.
- kpil 8y ago
  Since it took them 20 years to make a half-decent shell and 30 years how to figure out how stdout should work: no they had no clue. Maybe they knew how a kernel should work though, but weren't the NT guys old VMS guys? That's a totally un-unixy OS actually.
  - c487bd62 8y ago
    It's all about pushing Azure and dedicating resources to said goals
  - oblio 8y ago
    1. They didn't care about command line tools, in many ways (usability) they're a huge regression. After all, it was in the name of the product: Windows. 2. Who says that in-band communication like Unix is doing is necessarily better? See pastejacking and other shenanigans.

red75prime 8y ago

I hope control-S (XOFF) is disabled by default.

mschuster91 8y ago

Is there any way to get this backported to Windows 7 - or run a W7 userland on top of a W10 kernel? I'm actually serious about this one, I can't stand this semi-"mobile-first", flat UI of newer Windows generations, and the privacy invasions and ads are other hard blockers for me - but that WSL layer or the new console subsystem seem to be pretty nice features.

mobilehnuser 8y ago

Thanks to WSL and this, I'm very hopeful that my next development laptop can be a windows device

OnlyRepliesToBS 8y ago

They're going to fuck up console like they fucked up the Registery, COM+, WPF, DirectDraw, Silverlight, WCF, etc... It will be a clusterfuck of weird syntax that no doubt will embrace and extend what a console can do but then become proprietary as fuck. Watch. Cycle repeat.

borekb 8y ago

I currently use ConEmu + zsh via MSYS2 as my preferred shell on Windows. I need to run many interactive programs like `python`, `node` etc. via winpty, e.g.: ``` alias node='winpty node.cmd' ``` With the new ConPTY, will I be able to run native Windows programs directly? If so, that would be huge, winpty (while I'm really thankful it exists) is a PITA in practice, see e.g. https://github.com/Microsoft/vscode/issues/45693 https://github.com/Microsoft/vscode/issues/45693.