1. 10
  1.  

  2. 2

    While it’s great Microsoft is finally adding features to the Windows console, I’ve been a happy user of http://cmder.net/ whenever I wanted a real terminal on Windows.

    1. 7

      The problem isn’t just what terminal to use: Most Windows Applications use the console API which sucks because it doesn’t support basic functionality that UNIX-based environments have had for years or map real-world expectations (e.g. the powershell example), and there’s nothing you can do about it except rewrite all the programs.

      The good news is that’s exactly what Microsoft is suggesting now:

      This issue further amplifies the recommendation to start writing (or update existing) Command-Line apps to emit VT enriched text, rather than calling Win32 Console APIs to control/format Console output: VT-enabled apps will not only benefit from rendering improvements like those described above (with more on the way), but they’ll also enjoy richer features available via VT-sequences, like 24-bit color support, and default foreground/background color support.

      That’s big news, and hopefully it’ll get more publicity than the closing remarks of a very long (and self-congratulatory) blog post, since it’ll only make tools like cmder better.

      1. 6

        Most Windows Applications use the console API which sucks because it doesn’t support basic functionality that UNIX-based environments have had for years

        As a developer, I often feel the opposite. The unix terminal is a crippled mess, while the Windows console works fairly easily. Look at keyboard input, for example. The Windows API will return nice key codes with modifier flags. It’ll even tell you key up events if you care! Unix terminals can only send you character events easily, and the rest of the keyboard is a mix of various sequences that may or may not give you the modifiers. Assuming the sequences are all xterm or using ncurses etc kinda sorta takes care of the various sequences. Kinda. Sorta. They still frequently don’t work or get broken up or have awkward delays (you can’t assume the esc char is the escape key without checking for more input). Some terminals send stuff you cannot detect without a full list.

        Oh, and try to treat shift+enter differently than enter in a Unix terminal program. Some terminals send codes to distinguish it… which can make programs do random stuff when they don’t recognize it.

        On Windows, the structs are tagged. You can easily skip messages you don’t want to handle. Of course, both Windows and unix are based on some underlying hardware and I appreciate the history of it, but…

        …I loathe the VT “protocol”. …but alas, rewriting all those programs isn’t going to happen, so I get it. And I know there’s some advantages. I like the pty thing as much as the next person - it is cool to be able to easily redirect all this stuff, and it is reasonable efficient in terms of bytes transferred, and the cooked mode has potential to massively decrease latency (though most programs turn that off as soon as the can since it sucks in practice)… I just wish we were redirecting a sane, well-defined protocol instead, and I prefer the console API as the base features.

        Oh well. Hopefully everyone will at least just agree to use xterm escape sequences everywhere.

        1. 1

          If they are referring to non-interactive programs with color output, and even shells with readline-style editing, then it’s better to port to standard VT protocols. Input is not much an issue for such programs, benefits are using more standard interface and being usable from SSH.

          For heavyweight TUI programs it might be better to stay with WinAPI, for the same reason that many users of Emacs prefer its GUI version (even on unixes).

          1. 3

            readline-style editing has a lot to gain by using a sane input system, too. No more ^[[3~ showing up when trying to edit something!

            But on ssh, note that Microsoft are actually handling this: they are putting a layer in the OS console driver to translate api calls to VT sequences when used through a pty. So it is still possible to use those programs over ssh. They are covering a lot bases here - I am excited to try it (my computer refuses to take the windows update with the new pty stuff so far though, so I gotta wait a lil longer. But I can test both my terminal emulator and terminal client library with it and see how it works - and I expect it will be cool to mix and match.)

    2. 2

      recommendation to start writing (or update existing) Command-Line apps to emit VT enriched text, rather than calling Win32 Console APIs to control/format Console output: VT-enabled apps will not only benefit from rendering improvements like those described above (with more on the way), but they’ll also enjoy richer features available via VT-sequences, like 24-bit color support, and default foreground/background color support.

      Do they recommend to update input handling too? I don’t see problems with VT-style output, but input is messy, compared to WinAPI. I can’t imagine Far Manager to be rewritten to use VT-like input, with quirky alt/meta key and escape key repurposed both for sending escape codes and for “cancel” action. (On the positive side, it will be usable through ssh and closer to porting to other OSes).

      (At first I thought it was about XBox, referring to terminal as “console” is one of these strange Microsoft terms)

      1. 1

        Following some links from that post, I discovered that Microsoft is finally updating the default console palette to something a little nicer than the traditional Windows VGA 16-color palette.

        If only it were easier to load custom palettes into GNOME Terminal…

        1. 1

          I never understand Microsoft’s approach to the terminal. It is the single most important reason I prefer a Linux environment. I can literally put a USB in my desktop, enter three lines of code (download my own install script, make it executable, and execute it), and come back half an hour later to an installed, configured desktop.

          Meanwhile, Powershell sucks big time. If you enter a non-existent command the background color of the error message doesn’t even match the background of the terminal window. This is something that a junior dev should be able to fix in a couple of hour. Not something that’s in the most important automation tool in the biggest OS made by one of the richest companies on earth. While it’s not important, it is typical of the attitude that Microsoft has towards empowering users.

          It’s good they are finally deciding to drop some policies which are mostly harmful for themselves. They are finally jumping on the open source bandwagon, even though they are extremely late to the party (like you can expect from a company that big and presumably bureaucratic).

          1. 1

            If you enter a non-existent command the background color of the error message doesn’t even match the background of the terminal window. This is something that a junior dev should be able to fix in a couple of hour. Not something that’s in the most important automation tool in the biggest OS made by one of the richest companies on earth. While it’s not important, it is typical of the attitude that Microsoft has towards empowering users.

            I randomly had to do some work in Powershell recently, after 10 years of working with mac/linux only. I noticed the jarring error colours too (black background, red text, right?) and I could only conclude that it’s intentional: In Powershell it’s very clear that you’re looking at an error message.