16 ms·

Inside the Windows Console

276 points by pmarin 8y ago

thomastjeffery 8y ago
> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it! Which really shows, especially since you still can't use a TTF-font without editing the registry.
- flabbergast 8y ago
  Yeah, this 30 years old code-base.. besides it is questionable only dev's below 30yr old are working on it (age discrimination, or accidental?), hardly anything changed. If I want to copy something I still have to do the ancient mark and copy sequence from the right click menu! What are they working on then? Still fixing bugs?
  - nitinreddy88 8y ago
    Powershell. All of these shortcomings were fixed in it. Currently its also supported in Windows/*nix
    - ygra 8y ago
      PowerShell is a shell, thus a console application, buy not the console. So it's just the settings of the console window if you observe any differences. The PowerShell shortcut on the start menu may have different settings from the command prompt shortcut.
    - Someone1234 8y ago
      I love Powershell, but it still uses the exact same ConHost as cmd and command.com before it. When scripting PS this is a non-issue, but using it interactively remains painful.
      - zadjii 8y ago
        May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
        ocdtrekkie 8y ago
        Not the parent, but personally, my only real pet peeve with PowerShell as an IT admin is that the right click start menu replaced cmd with PowerShell despite it still being drastically slower to load on many PCs. There's a setting to change it back, but if you are working on other computers all the time, that's not useful at all. This is my main peeve with the Settings panel as well: It's slower to get things done with, but the legacy panels have been intentionally made harder to reach[1] before performance parity has been reached. My understanding is that improving PowerShell's start time is a big part of the next release of Windows 10, and that's great, but once that's done was the right time to put PowerShell as the default console on Windows, not before. 98% of why I open a prompt is to run "ping", and waiting for the prompt to actually show up in PS takes longer than a ping timeout. (Which is to say, if you need one takeaway from this post: Remember that no matter how cool you make PowerShell, most of us are only opening it to ping something, that's the most important experience to get right.) Especially some of the decisions with the install screens for Windows 10 seem to highlight that people at Microsoft aren't aware how some subtle changes cause significant pain/delay for IT folks. Like with 1803 being forced to come up with security questions when creating the local account on a PC you're about to domain join. [1]Example: Programs and Features from the legacy control panel no longer appears in search, even if you type it all the way out. Typing "appwiz.cpl" is the fastest way to see what's installed on a computer (and what versions) at a glance, but kinda a pro trick.
        rosege 8y ago
        You could change the right click back to cmd by using a group policy to change the registry. E.g. https://blogs.msmvps.com/russel/2016/11/18/defaulting-to-powershell-instead-of-cmd/ https://blogs.msmvps.com/russel/2016/11/18/defaulting-to-pow...
  - ocdtrekkie 8y ago
    This is also not true as of Windows 10 build 16299/Fall Creator's Update (what I'm currently using), and may not be true of an earlier release or two. Ctrl+C and Ctrl+V both work just fine in cmd. I found evidence it was considered an "experimental feature" available in the Command Prompt's Properties dialogue back in 2015, it looks like it's been folded into the default behavior at this point. Microsoft's done a lot of work on legacy components of Windows like cmd and notepad in the last few years, assumptions about behavior that has worked the same for the last twenty years may no longer be valid. ;)
  - zadjii 8y ago
    Have you tried enabling QuickEdit mode in the Properties (right click on the titlebar)? Quick edit lets you use the mouse for selecting, and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!). We've been working on not only tons of bugs, but adding plenty of new features, including support for VT sequences, 256/RGB color, improving our unicode support, enhanced accessibility support. The fact that all of our devs are under 30 is merely coincidence :)
    - merinowool 8y ago
      Why do you need to select quick edit to be able to copy? That makes no sense.
      - mastazi 8y ago
        You don't need to but it makes it easier
    - sun41 8y ago
      > and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!) Insider's release only? Wow, that sounds like really advanced stuff for something totally basic! > we've even added support for Ctrl+Shift+C/V for copy paste So, you're from Microsoft, down voting everything that has the slightest touch of criticism? With the entire team maybe? You must be a very proud employee.
      - ygra 8y ago
        > Insider's release only? Wow, that sounds like really advanced stuff for something totally basic! This has nothing to do with how large or small the feature or change is. A feature, once ready to be publicly tested, will get in the pipeline to first get into the insider releases and eventually show up in a normal build. In what kind of release such a change is is purely based on how old the change is, I guess. But of course, don't let that detract you from snarking.
      - wila 8y ago
  - pjmlp 8y ago
    What about learning to use the OS? Quick edit for UNIX style copy-paste with the mouse goes all the way back to Windows 9X. The only issue is that it was always disabled by default, until they changed to be enabled by default with the latest set of changes. Spending a couple of seconds after logging in to enable it, for the very first time on a new system, was never a big deal.
    - blkhawk 8y ago
      Its not quite UNIX style - it works like a weird frame selection instead of follow the text LtR like any *nix console I can think of. It would be super if that could be fixed as well with an option.
      - oblio 8y ago
        I'm pretty sure it's block/column selection instead of line selection. Why they made that design decision, we will never know. Maybe a dev was working with a lot of hex output? (even so, he should be slapped retroactively, unless he's Raymond Chen, cause Raymond Chen is amazing so we'll forgive his transgressions)
        icc97 8y ago
        This is one of the major changes that happened since this team started working on the console. In Windows 10 it has line selection that flows correctly over line breaks.
        tom_ 8y ago
        The console 'screen' is a grid of (character,attribute) pairs, so there are no lines as such... I'm not sure the box selection is super useful these days, but in the late 80s/early 90s, GUI-style interfaces were very popular, and a box selection makes a certain amount of sense, so you can avoid picking up borders and so on. Would have been nice if they'd got both types in from day 1 though...
- zadjii 8y ago
  That's just flat out wrong: https://i.imgur.com/ae1yyXI.png https://i.imgur.com/ae1yyXI.png We added support for TTF fonts a few releases ago.
  - sun41 8y ago
    Wow, so that's fixed after almost 30 years! Flat out amazing, what a team!
    - royjacobs 8y ago
      ...so if they don't fix it, the console sucks. But if they do fix it you still find the need to be snarky?
      - code_duck 8y ago
        I think the concept is that if they had added it a long time ago, is that would be good or average. Adding it very late is not worthy of praise, and lacking it for years is still worthy of condemnation. While the change may be part of a broader positive trend, it does not absolve them of the past.
        royjacobs 8y ago
        Why not, though? Is it really that useful to fill every Microsoft-related topic with comments that amount to "Micro$oft lol"-level trolling? I mean, they used to suck, we get it. They're actively trying to improve but that, too, is not enough. - "You used to be fat!" - "I'm thin now, though, through hard work. Isn't that worth something?" - "...but you used to be fat!"
        code_duck 8y ago
        The company has an almost 40 year history. When you’ve built up and miss trust over decades, peoples attitudes are not going to change overnight. Personally, while I was merely describing what I perceived other people’s viewpoints to be, I don’t know why it’s so hard for Microsoft to make a normal terminal app. People have the choice of a dozen adequate terminal apps on Linux. I guess this article explains any difficulty. As far as MS modernizing, one could look at it as, what would you think if 25 or 30 years ago, IBM said that they were turning around and we’re now a modern, agile company instead of a slow-moving relic of the previous era, and they built an awesome new console app for OS/2?
angelsl 8y ago
I'm not sure why the author is so excited! But it makes the article a bit difficult to read!
- zadjii 8y ago
  That's Rich for you - He's pretty passionate about everything we do :)
  - Stratoscope 8y ago
    I want to work with more people like Rich! Whatever they may lack in English convention, they more than make up for it in enthusiasm!
    - zadjii 8y ago
      lol Rich is straight outta Britain English - his English is the most English of any of ours :P edit: Now that I say that, I guess he is Welsh so maybe his english isn't the best... :P
      - bitcrazed 8y ago
        I'd swear at you in Welsh but I fear I may wear-out my 'l', 'e', and 'u' keys ;) Thanks all - appreciate that some of my enthusiasm came through, though the previous poster had a point about the sheer density of my excitement so I toned it down a little while making a few corrections, clarifications, and improvements in the update I posted this afternoon. Keep the feedback coming though - you'll also find me on Twitter a lot more than in here: https://twitter.com/richturn_ms https://twitter.com/richturn_ms
  - wila 8y ago
    Thank you, love the series. Nothing wrong with the writing style. Keep up the good work, it is great to see the console getting gradual improvements!
- dcgudeman 8y ago
gmueckl 8y ago
So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?
- zadjii 8y ago
  Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console implementation in Windows, though it's the only one available on Desktop. There was a pretty massive undertaking to unify all the separate console implementations on different SKUs under one application, so that all of them would be improved at the same time. It didn't have a terrible lot of impact on the everyday developer, but it was important to help internal engineering efforts.
  - gmueckl 8y ago
    Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there. I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? Also,I am curious about one other thing: the Windows Console is notorious for having extremely bad perfomance when displaying lots of text. Last time I checked I could only get around 100 lines of text per second on Windows while Linux terminal emulations can show more than 10 times that amount. This may seem petty, but some programs are slowed down by this in practice. Can we expect improvements in that area as well?
    - lozenge 8y ago
      As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.
oldgradstudent 8y ago
The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scrolling large amounts of text.
- izacus 8y ago
  Is that true for other UIs like conemu?
  - oldgradstudent 8y ago
    Good question. The article says that > Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would! > For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000,-32000). They then have to send keystrokes to the off-screen Console, and screen-scrape the off-screen Console's text contents and re-draw them on their own UI!! I'd guess that the third party emulators might perform worse, but someone need to test it empirically.
    - laumars 8y ago
      That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows just jumps over that STDIN read request and ploughs through the rest of the program. I can't say if this is a bug in my shell specifically or a wider problem that has lead to the work around you described, but it's literally the only problem left in my Windows port and I'm definitely not smarter than average nor have I spent any excessive time working in Windows so I cannot see how I might have solved problems that other shells are still grappling with given the limited time I've spent on the Windows specific portion of the code. As for the bug itself, I get this is a pretty major bug which severally hampers the usability of the shell but I think given enough time (and a new development machine to test it one since I now longer have access to a Windows laptop after changing jobs) I could get this bug solved too. Hopefully without resorting to the kludge you described, but who knows.
zerr 8y ago
> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it! It smells like ageism... Did you lay off the original "old" devs? EDIT: :)
- jhall1468 8y ago
  I'm hoping this is a joke. Most developers don't stay at the same company on the same team for 30 years...
- zadjii 8y ago
  Lol any original devs retired a long time ago, can you imagine what $MSFT shares from 1989 are worth now?
  - drblast 8y ago
    Don't even have to imagine. NASDAQ: MSFT $104.40
    - phs2501 8y ago
      With stock splits 1 share in 1989 would be 72 shares now. So $7,516.80.
  - sun41 8y ago
    What the heck is this related to shares? You mean to suggest all original devs are millionaire, and that being a millionaire means you don't code anymore? And you, poor guy, missed out?
    - erikbye 8y ago
      Early MSFT employees were compensated heavily with stock options. I think it's also pretty safe to say that few devs from that period are still coders, they've moved on to other roles or retired. From Show Stopper!: Technical preferences aside, the success of Windows was a windfall for Cutler and colleagues. Most had received sizable stock option grants on joining Microsoft, partly to compensate for their reduced wages. At other companies such stock grants might return 10 to 25 percent profit to a grateful employee over five to ten years. A doubling of value would be a bonanza. But lately Microsoft's stock had soared-with no limit in sight. Demand for Windows transformed Microsoft from the leader of the software pack into a giant looming over the rest of the industry. The company's net profits were especially impressive; an astonishing 25 percent of sales flowed to the bottom line. Options granted to Cutler two years earlier, while substantial at the time, were now breathtaking. And the stock price seemed a cinch to double over the next few years, given the company's bullish outlook. Even at the current stock price, Cutler's options now were worth at least several million dollars. Havens and Perazzoli, meanwhile, were assured of clearing high six figures. Even the team's rookie programmer, hired fresh from Princeton the summer before, would reap a few hundred thousand dollars within three years.
m_st 8y ago
I tried using PowerShell or Hyper. But these are just so slow to start. So I'm always coming back to cmd.exe. It is fast and serves my basic needs just perfect. When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper. So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe. Keep improving cmd.exe. But please don't make it bloated.
- ilikehurdles 8y ago
  Do you have something custom going on in powershell? I’m not a power user of windows shells but it opens very quickly for me. So much so that I never thought about the speed of either terminal.
  - userbinator 8y ago
    "very quickly" is subjective, but compared to cmd it is noticeably slower even in a fresh install of Windows --- the few times I'm forced to actually use it to configure some things.
    - Tarean 8y ago
      I think powershell is kept in memory so only the first start should be slow. Although I don't really notice the first start being slower anymore - maybe it preloads depending on settings or is just fast enough with an ssd?
      - ygra 8y ago
        Windows picks up usage patterns and pre-loads applications to match that. But indeed, right after launching an application it's still in the disk cache anyway, so subsequent launches (until heavy I/O) should be quick.
      - Catfishfinger 8y ago
        This makes sense, I use Powershell all the time, have loads of PS modules installed and it opens pretty much instantly.
tempodox 8y ago
So, MS has finally realized they're 40 years behind the civilized world. I'm curious to see how long it will take them to catch up.
- 0xFFFF0000 8y ago
  Not sure what you mean... PowerShell Console is one of the most modern and advanced consoles there is and it's from Microsoft (compared to old non object oriented and pipelined stuff like cmd here in the article) - but it's still good to see that they haven't forgotten about the good old cmd.exe :)
  - ygra 8y ago
    You're mistaking the shell for the console. As the article quite clearly points out, there's a vast difference between both, even though when you look at a console application (such as a shell) you kind of always see both.
- gaius 8y ago
  So, MS has finally realized they're 40 years behind the civilized world Yes they should be emulating a teletype like enlightened folk!
  - oblio 8y ago
    You mean you don't actually print your output?!? Heathen!
  - ziotom78 8y ago
    Very appropriate comment. Last year I was tinkering with the implementation of a TUI (Text User Interface), and I wanted it to be cross-platform. I started developing it under Windows, using the Console API (sorely lacking in features, but at least it is just an API to be called from C). I had to abandon the project once I realized that it would have been too hard to harmonize this approach with the weird way you are supposed to program a Unix console. Let's consider the difference between calling an hypotetical system API to change the text color and a raw sequence of bytes encoding. In Unix, to set the color to be used for writing characters you have to send an ESC character, some more bytes, and then an ASCII representation of the R, G, and B components (assuming your virtual terminal supports this), separated by a colon/semicolon. The terminal will then read this sequence, parse the three numbers and move the character. This approach is not precisely efficient, especially if you consider that today it is not unlikely to have full-screen terminal applications with a large resolution. For a 200x60 terminal like the one I am using right now, to color every character with a different color requires sending 500 Kb of data, compared to the 36 Kb required by a 3-byte representation of each RGB tuples. And if you are trying to read from a terminal, every time you receive an ESC key, you are always in doubt whether the user pressed ESC, or if it is the start of an ANSI sequence. The usual trick here is to check if there is a character already available immediately after you detect an ESC byte coming from standard input: if there is, you can assume it's the beginning of a sequence. Admittedly the virtual-terminal approach makes remote connections (through SSH) simpler than an API (you just have to send a bunch of bytes through a socket), but I wonder why in 2018 we are still relying on the old and quirky mechanism of "virtual consoles" when real consoles have long disappeared. Edit: small fixes.
chungy 8y ago
Technical errors regarding how UTF encodings work: * UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before Unicode settled on U+10FFFF[1] being the maximal codepoint for backwards compatibility reasons with UCS-2...) * It says UTF-16 extends UCS-2 (which is correct) by incorporating a 4-bit encoding... which probably was intended to be a "4-byte encoding" instead. The surrogate pairs reserve their first six bits for an additional 10 bits making up half of the codepoint being stored (whose value is later added to by 0x10000 to get the actual codepoint). Also, it provides 16 additional planes to the BMP. 17 total including the BMP. [1] Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict.
- jwilk 8y ago
  > Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict. This is what Unicode 11.0, §2.4 says: Noncharacter code points are reserved for internal use, such as for sentinel values. They have well-formed representations in Unicode encoding forms and survive conversions between encoding forms. This allows sentinel values to be preserved internally across Unicode encoding forms, even though they are not designed to be used in open interchange. It would wrong for a general-purpose parser to reject these codepoints.
  - chungy 8y ago
    Hmm, alright. I have seen parsers reject them, presumably from misinterpreting the standard. Thanks for the correction :)
- bitcrazed 8y ago
  Hi - Windows Console PM and author of the post here :) You're absolutely correct.I made some fixes, adjustments, and clarifications to the post this afternoon - hope they're a little more accurate. We'll be digging into this area in much more detail in future posts.
tofflos 8y ago
I love reading about the work that's being put into old apps like Console and Notepad. Keep it up!
dvfjsdhgfv 8y ago
I love Cmder, it's superior to cmd.exe in all possible ways, but from time to time it just stops working. Now I understand better why.
- ygra 8y ago
  cmd is the shell, Cmder (which is just a wrapper around ConEmu) is the console/terminal. Both have little to do with each other, apart from that one needs the other to show a window.
- EnderMB 8y ago
  I haven't done any Windows dev since last year, but I've often wondered why more .NET devs don't use Cmder. I've always been a fan of a full-screen console with split panes (tmux style), and other developers have looked at me like I'm some sort of wizard, despite using fairly basic tech. Sure, it takes a little while to get used to Powershell, but once you get over the hump it's really useful knowledge to have, especially if you have anything to do with devops or deployments.
- bitcrazed 8y ago
  G'ah - PLEASE read the posts about which you're commenting - Cmder is a terminal/Console, not a shell. Cmd.exe is a (headless) command-line shell. A shell accepts input from a terminal/Console and emits text to its connected terminal/Console to be displayed back to the user. All this is covered in some detail in the posts thus far.
  - dvfjsdhgfv 8y ago
    That's quite clear, I have no idea why people assume I confuse the two. I just said the article helped me to understand why Cmder has certain problems.
slinzer 8y ago
Too many exclamation marks.
- bitcrazed 8y ago
  Fixed! Let me know if you prefer the updated version I posted this afternoon. Thanks for the feedback :)
frankohn 8y ago
I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work remotely - the shell and the terminal are not clearly separated: the OS will open automatically a console for some kind of executables / cannot attach a shell to an arbitrary console It seems to me that it shows a few things. First, unix design was better as it was more flexible and lasted over time and computers evolution. Windows' design was sort of wrong since the beginning but they didn't change anything and developers were left to use one of their horrible APIs. This is similar to the difference between X Window and Win32 GUI API. Second, MS does not care about developers except for the user of their flagship product Visual Studio. They put 30 years of developer effort solely on Visual Studio and nothing else. Compare with Apple, they at least cared of implementing an excellent terminal and contributed greatly to the wonderful LLVM compiler infrastructure. So, okay some improvements might lands on Windows 10 at some moment but I personally don't care. At work we still use Win 7 and I think we will keep using it for a long time. The Windows Console is just horrible to use and propram for and a testament to the MS awful software and APIs that developers are forced to use because of Windows dominance.
- ygra 8y ago
  I didn't get the impression that they consider the Console API in itself a flaw. An API for this is much more robust than an in-band text API that's part of your output. For example, no Windows console application has to even think about whether printing a user-provided string can be a problem. They do note that it's an impediment for porting software to Windows, as well as the problem that the API isn't able to be implemented by any other application, e.g. ConEmu. Those applications have to rely on scraping a hidden console window to work instead of just being an alternative console implementation. I read it not so much as a testament to the perceived superiority of the Unix model, but rather that with WSL users expect certain things to work more Unix-like, just that they don't work like that right now.
  - 8y ago
a-dub 8y ago
Is Microsoft taking a page out of ol' Vladdy Putin's playbook? Why is this upvoted? The Windows console is garbage software on top of garbage software.
logcat 8y ago
There are ways to get much better terminal experience for typical web dev https://blog.ropnop.com/configuring-a-pretty-and-usable-terminal-emulator-for-wsl/ https://blog.ropnop.com/configuring-a-pretty-and-usable-term... (also works for tilix)
cbolton 8y ago
This a very candid and informative look at the Windows console and it comes from Microsoft! I'm impressed. Congrats to the writer and thanks for posting!
- sevensor 8y ago
  This is of a piece with Microsoft's GitHub acquisition -- seems to be part of a program to win developer mindshare. And it's working; I was impressed by this post, both tone and technical content. Windows having never really been suitable for the server, and rapidly losing its grip on the home user, it seems totally sensible to push the "windows is a good platform for people doing serious work" angle. It's all Windows has left.
- bitcrazed 8y ago
  Hi. Windows Console PM and Author of the post here :) Thanks for your kind words. Glad you liked it - check our blog often - LOTS more posts coming on this subject!
megaman22 8y ago
Yikes, the anti-Windows crowd is strident today. Yeah, cmd.exe is crap, and if you're expecting to use a Unix workflow rather than learn how things work in Windows, you're going to have a bad time. I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware from fifty years ago is really a great ideal either... But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, or you'll break things in a way that has been historically unacceptable in Redmond.
- vetinari 8y ago
  > I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware > But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, You do see the irony, right?
  - tom_ 8y ago
    I think his (?) point is that if you don't have the backwards-compatibility goals of Windows, you can afford to be - and perhaps should be - a lot more adventurous. Which is something POSIX systems have summarily failed to be in this respect, for all that they've managed to polish that turd to an acceptable shine.
    - vetinari 8y ago
      What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems? I read the above sentences as: 1) the legacy on $SYSTEMS_I_DONT_LIKE is bad 2) the legacy on $SYSTEM_I_LIKE is there for a reason.
      - AnIdiotOnTheNet 8y ago
        > What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems? I can still run software written for Windows 95, without recompilation, with a pretty high success rate. As far as I'm aware, only Linux has that level of ABI compatibility and unfortunately it's completely broken by userspace. Often you can't even run the same binary on two different distributions without recompilation.
gigatexal 8y ago
They should just replace it with the power shell prompt that wraps the command line.
- gigatexal 8y ago
  Too many fans of the command line from the 90s. Oh well.
nailer 8y ago
As a nix person who now spends his entire day in the Windows terminal, I wrote a guide to setting up the console and pwsh for maximum productivity: https://github.com/mikemaccana/powershell-profile/blob/master/README.md https://github.com/mikemaccana/powershell-profile/blob/maste...
7kmph 8y ago
Who cares anyway
- lagadu 8y ago
  Well, you cared enough to post. Now imagine all the people who actually enjoy reading insights about developing software that we've all used.
deejbee 8y ago
One thing I've always missed is tabbed consoles. I've use Cmder (http://cmder.net/ http://cmder.net/ I have no affiliation) for quite a while now and has been totally awesome as it provides a tabbed container window with any mixture of cmd.exe, bash shell, launching as Admin and best of all it persists all your windows after reboot.
- neilsimp1 8y ago
  Another Cmder lover here. Although when the Windows 10 "Sets" UI comes out and default Powershell/conhost has tabs built in, it may be time to just stick with that. We'll see...
  - duncanawoods 8y ago
    Pretty unhappy Cmder user here. Sooo many bugs. Currently have dash.exe crashes on start-up, fatal race conditions generating certain types of error output, performance becomes unusable in git folders with lots of files because of how it updates the auto-text in the prompt and it has the configuration/settings from hell but they just blame ConEmu. I just want a tabbed console that will remember the tab locations and command history between sessions. This would seem obvious thing but no.
    - 1996 8y ago
      I run mosh on windows 10 over bash inside cmder, I have had a few weird issues too. I thought I was the one at fault!!
- Serow225 8y ago
  https://blogs.msdn.microsoft.com/commandline/2018/04/13/tabbed-console-starts-here/ https://blogs.msdn.microsoft.com/commandline/2018/04/13/tabb...
- zadjii 8y ago
  Trust us, the pain on not having a tabbed console is felt here in the console team too. It's our most requested feature, but implementing it has always ended up a lot harder than expected. Fortunately we're working with the Tabbed Sets team to help nail that experience for the console.
OliverJones 8y ago
Very interesting. I learned a lot. The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulator. But, with respect, I think he's wrong about that. Command line history is a valuable productivity enhancer, and tying the details of its operation to the terminal rather than the shell restricts functionality and flexibility. For example, witness the differences between git bash (mingw) and cmd on Windows. Inbuilt OS stuff should be as simple as possible. It doesn't have to be precisely /dev/tty - like, but it should be simple. Partly to avoid bloat, and partly because it's much less flexible than userland stuff. Even when RAM was worth twice its weight in gold, various UNIX shells weren't heavy. Now? not worth worrying about. I admit I came up as a UNIX user so I favor sh-like history. But still, Windows terminal history just isn't as good. (I wish it didn't deduplicate repeated commands and lose them when they're edited.)
- laumars 8y ago
  There was a few points the other raised which I disagreed with and that was one of them. I completely agree with you that shell history should be managed by the shell itself. I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are. Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms. What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked. If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.
jscholes 8y ago
Found the article content quite interesting but the tone of the writing (emojis and exclamation marks everywhere) really put me off. Sounded forced and added nothing.
- degenerate 8y ago
  It reminded me of a very excited Steve Ballmer: https://www.youtube.com/watch?v=HMhrRovP9qA https://www.youtube.com/watch?v=HMhrRovP9qA
- bitcrazed 8y ago
  Fair comment - I agree and so removed a bunch of !'s and emoji for you, though I did leave a few in to convey some of my (and the team's) excitement - we're genuinely buzzed to be able to massively improve the Console. Hope you find the latest updated version more palatable.
xvilka 8y ago
Hopefully, support for bidirectional text will be added soon. Microsoft needs to lead the way of handling it in console programs. Even in UNIX systems, only a few terminal emulators support bidirectional text properly.
- zadjii 8y ago
  Could you go submit this to our UserVoice? https://wpdev.uservoice.com/forums/266908-command-prompt-console-windows-subsystem-for-l?category_id=87960 https://wpdev.uservoice.com/forums/266908-command-prompt-con... I'd say that bi-directional text is a pretty low priority at the moment. We just haven't really heard any asks for it, and like you said it's poorly supported on other platforms (if at all).
cryptonector 8y ago
I really like the point that an API-centric console does not remote well (think ssh). In general I prefer the WIN32 object-handle model to the Unix file-descriptor model, and I much prefer the WIN32 security descriptor and access token model to the Unix haphazard security model, but very clearly, the everything-is-a-file model is superior at least for remote access: it's easier to design and implement protocols for that since the protocols don't need to know anything about the remote resources' nature. Thus the Windows console cannot be exported via SSH, not without writing a layer that converts text reads/writes into ioctls, because it's not remotely file-like. That the Windows team had to and did write that layer really is fantastic news.
iforgotpassword 8y ago
Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search? Is this just me? Late to the party? In case this isn't temporary: https://web.archive.org/web/20180717165103/https://blogs.msdn.microsoft.com/commandline/2018/07/10/windows-command-line-inside-the-windows-console/ https://web.archive.org/web/20180717165103/https://blogs.msd...
- bitcrazed 8y ago
  LOL - nothing nefarious - made a few corrections and improvements to the post - aaaaand managed to bork the publishing process which took a few mins to re-generate and refresh the cache! Ugh! Should be back up and available now!
zaat 8y ago
I'm late to the party, but maybe the console guys are still lurking. If so, than first and foremost I wanted to thank you for the amazing walk you guys took the console so far. That said, as someone who uses your product for hours on daily basis, I have two pain points that I would love to have fixed, if that possible at all: 1. selection of text and deletion - works in PowerShell, doesn't work in cmd. Is this curable? 2. Customizing the console is pain. I don't mind doing it once but it is impossible to save theme and copy it between computers. It is also impossible to export registry keys - not only do they differ for various consoles, the color settings are not saved there. The only way I found so far for achieving this is copying the shortcut for the specific console - the colors are saved to the .lnk file in binary form. Seriously, can we have at least color exportable themes in a format that can be edited with a text editor?
- bitcrazed 8y ago
  Hey @zaat. Thanks for your kind words :D Alas, deleting text is an operation controlled via the shell. PowerShell's (awesome) PSReadLine does it for PowerShell, but introducing that kind of behavioral change is unlikely to be possible in Cmd because, as pointed out in the posts, Cmd is in maintenance mode, is extremely fragile, and it's key MO is backward compat, which includes behaviors because many tools, and scripts depend on behaviors (even broken ones) as "Features" ;)
  - zaat 8y ago
    Thank you for answering. Any chances on number 2, especially color themes?
- zadjii 8y ago
  I think rich (@bitcrazed) already talked a bit about #1, so I'll share a bit on #2. I agree, the current properties story is INSANE. I don't get how whoever wrote it even came up with it - it's likely a frankencode system that we're stuck supporting for now. I can't tell you how many times I've had to explain how the console settings work, and how your settings can be different depending on how you launch the console. It's been a pain point I've had a particular eye on since I started here. It's a powerful system that is very prone to "you moved my cheese" syndrome - It's REALLY hard to change it into a sane system without breaking someone's workflow. That being said, I have a bone to pick with that system, and I think I might have some spare cycles to finally get to it soon :) PS: While we're on the subject of colors, lemme quick throw out (Colortool)[https://github.com/Microsoft/console/tree/master/tools/ColorTool https://github.com/Microsoft/console/tree/master/tools/Color...]. It can be really helpful for quickly changing the color scheme of the console. It's not great for everything, but I've found it super helpful.

276 points by pmarin 8y ago

> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it! Which really shows, especially since you still can't use a TTF-font without editing the registry.

flabbergast 8y ago
Yeah, this 30 years old code-base.. besides it is questionable only dev's below 30yr old are working on it (age discrimination, or accidental?), hardly anything changed. If I want to copy something I still have to do the ancient mark and copy sequence from the right click menu! What are they working on then? Still fixing bugs?
- nitinreddy88 8y ago
  Powershell. All of these shortcomings were fixed in it. Currently its also supported in Windows/*nix
  - ygra 8y ago
    PowerShell is a shell, thus a console application, buy not the console. So it's just the settings of the console window if you observe any differences. The PowerShell shortcut on the start menu may have different settings from the command prompt shortcut.
  - Someone1234 8y ago
    I love Powershell, but it still uses the exact same ConHost as cmd and command.com before it. When scripting PS this is a non-issue, but using it interactively remains painful.
    - zadjii 8y ago
      May I ask what your specific pain points are? We've been doing a lot to try and improve our usability but there's so very much on our backlog that it's hard to prioritize. I'm always curious if people have specific requests edit: pain points with conhost*. I work on conhost, the "terminal", not PowerShell
      - ocdtrekkie 8y ago
        Not the parent, but personally, my only real pet peeve with PowerShell as an IT admin is that the right click start menu replaced cmd with PowerShell despite it still being drastically slower to load on many PCs. There's a setting to change it back, but if you are working on other computers all the time, that's not useful at all. This is my main peeve with the Settings panel as well: It's slower to get things done with, but the legacy panels have been intentionally made harder to reach[1] before performance parity has been reached. My understanding is that improving PowerShell's start time is a big part of the next release of Windows 10, and that's great, but once that's done was the right time to put PowerShell as the default console on Windows, not before. 98% of why I open a prompt is to run "ping", and waiting for the prompt to actually show up in PS takes longer than a ping timeout. (Which is to say, if you need one takeaway from this post: Remember that no matter how cool you make PowerShell, most of us are only opening it to ping something, that's the most important experience to get right.) Especially some of the decisions with the install screens for Windows 10 seem to highlight that people at Microsoft aren't aware how some subtle changes cause significant pain/delay for IT folks. Like with 1803 being forced to come up with security questions when creating the local account on a PC you're about to domain join. [1]Example: Programs and Features from the legacy control panel no longer appears in search, even if you type it all the way out. Typing "appwiz.cpl" is the fastest way to see what's installed on a computer (and what versions) at a glance, but kinda a pro trick.
        rosege 8y ago
        You could change the right click back to cmd by using a group policy to change the registry. E.g. https://blogs.msmvps.com/russel/2016/11/18/defaulting-to-powershell-instead-of-cmd/ https://blogs.msmvps.com/russel/2016/11/18/defaulting-to-pow...
- ocdtrekkie 8y ago
  This is also not true as of Windows 10 build 16299/Fall Creator's Update (what I'm currently using), and may not be true of an earlier release or two. Ctrl+C and Ctrl+V both work just fine in cmd. I found evidence it was considered an "experimental feature" available in the Command Prompt's Properties dialogue back in 2015, it looks like it's been folded into the default behavior at this point. Microsoft's done a lot of work on legacy components of Windows like cmd and notepad in the last few years, assumptions about behavior that has worked the same for the last twenty years may no longer be valid. ;)
- zadjii 8y ago
  Have you tried enabling QuickEdit mode in the Properties (right click on the titlebar)? Quick edit lets you use the mouse for selecting, and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!). We've been working on not only tons of bugs, but adding plenty of new features, including support for VT sequences, 256/RGB color, improving our unicode support, enhanced accessibility support. The fact that all of our devs are under 30 is merely coincidence :)
  - merinowool 8y ago
    Why do you need to select quick edit to be able to copy? That makes no sense.
    - mastazi 8y ago
      You don't need to but it makes it easier
  - sun41 8y ago
    > and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!) Insider's release only? Wow, that sounds like really advanced stuff for something totally basic! > we've even added support for Ctrl+Shift+C/V for copy paste So, you're from Microsoft, down voting everything that has the slightest touch of criticism? With the entire team maybe? You must be a very proud employee.
    - ygra 8y ago
      > Insider's release only? Wow, that sounds like really advanced stuff for something totally basic! This has nothing to do with how large or small the feature or change is. A feature, once ready to be publicly tested, will get in the pipeline to first get into the insider releases and eventually show up in a normal build. In what kind of release such a change is is purely based on how old the change is, I guess. But of course, don't let that detract you from snarking.
    - wila 8y ago
- pjmlp 8y ago
  What about learning to use the OS? Quick edit for UNIX style copy-paste with the mouse goes all the way back to Windows 9X. The only issue is that it was always disabled by default, until they changed to be enabled by default with the latest set of changes. Spending a couple of seconds after logging in to enable it, for the very first time on a new system, was never a big deal.
  - blkhawk 8y ago
    Its not quite UNIX style - it works like a weird frame selection instead of follow the text LtR like any *nix console I can think of. It would be super if that could be fixed as well with an option.
    - oblio 8y ago
      I'm pretty sure it's block/column selection instead of line selection. Why they made that design decision, we will never know. Maybe a dev was working with a lot of hex output? (even so, he should be slapped retroactively, unless he's Raymond Chen, cause Raymond Chen is amazing so we'll forgive his transgressions)
      - icc97 8y ago
        This is one of the major changes that happened since this team started working on the console. In Windows 10 it has line selection that flows correctly over line breaks.
      - tom_ 8y ago
        The console 'screen' is a grid of (character,attribute) pairs, so there are no lines as such... I'm not sure the box selection is super useful these days, but in the late 80s/early 90s, GUI-style interfaces were very popular, and a box selection makes a certain amount of sense, so you can avoid picking up borders and so on. Would have been nice if they'd got both types in from day 1 though...
zadjii 8y ago
That's just flat out wrong: https://i.imgur.com/ae1yyXI.png https://i.imgur.com/ae1yyXI.png We added support for TTF fonts a few releases ago.
- sun41 8y ago
  Wow, so that's fixed after almost 30 years! Flat out amazing, what a team!
  - royjacobs 8y ago
    ...so if they don't fix it, the console sucks. But if they do fix it you still find the need to be snarky?
    - code_duck 8y ago
      I think the concept is that if they had added it a long time ago, is that would be good or average. Adding it very late is not worthy of praise, and lacking it for years is still worthy of condemnation. While the change may be part of a broader positive trend, it does not absolve them of the past.
      - royjacobs 8y ago
        Why not, though? Is it really that useful to fill every Microsoft-related topic with comments that amount to "Micro$oft lol"-level trolling? I mean, they used to suck, we get it. They're actively trying to improve but that, too, is not enough. - "You used to be fat!" - "I'm thin now, though, through hard work. Isn't that worth something?" - "...but you used to be fat!"
        code_duck 8y ago
        The company has an almost 40 year history. When you’ve built up and miss trust over decades, peoples attitudes are not going to change overnight. Personally, while I was merely describing what I perceived other people’s viewpoints to be, I don’t know why it’s so hard for Microsoft to make a normal terminal app. People have the choice of a dozen adequate terminal apps on Linux. I guess this article explains any difficulty. As far as MS modernizing, one could look at it as, what would you think if 25 or 30 years ago, IBM said that they were turning around and we’re now a modern, agile company instead of a slow-moving relic of the previous era, and they built an awesome new console app for OS/2?

angelsl 8y ago

I'm not sure why the author is so excited! But it makes the article a bit difficult to read!

zadjii 8y ago
That's Rich for you - He's pretty passionate about everything we do :)
- Stratoscope 8y ago
  I want to work with more people like Rich! Whatever they may lack in English convention, they more than make up for it in enthusiasm!
  - zadjii 8y ago
    lol Rich is straight outta Britain English - his English is the most English of any of ours :P edit: Now that I say that, I guess he is Welsh so maybe his english isn't the best... :P
    - bitcrazed 8y ago
      I'd swear at you in Welsh but I fear I may wear-out my 'l', 'e', and 'u' keys ;) Thanks all - appreciate that some of my enthusiasm came through, though the previous poster had a point about the sheer density of my excitement so I toned it down a little while making a few corrections, clarifications, and improvements in the update I posted this afternoon. Keep the feedback coming though - you'll also find me on Twitter a lot more than in here: https://twitter.com/richturn_ms https://twitter.com/richturn_ms
- wila 8y ago
  Thank you, love the series. Nothing wrong with the writing style. Keep up the good work, it is great to see the console getting gradual improvements!
dcgudeman 8y ago

gmueckl 8y ago

So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?

zadjii 8y ago
Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console implementation in Windows, though it's the only one available on Desktop. There was a pretty massive undertaking to unify all the separate console implementations on different SKUs under one application, so that all of them would be improved at the same time. It didn't have a terrible lot of impact on the everyday developer, but it was important to help internal engineering efforts.
- gmueckl 8y ago
  Thank you for explaining! Please don't take my initial post as criticism of your work. There is just this visible disconnect between approximately 4 years of work and comparatively simple features that have been shown off so far. So there must be a story there. I was not aware of Windows having had different console implementations in the past. Can you elaborate on that point? How did that come to pass? Also,I am curious about one other thing: the Windows Console is notorious for having extremely bad perfomance when displaying lots of text. Last time I checked I could only get around 100 lines of text per second on Windows while Linux terminal emulations can show more than 10 times that amount. This may seem petty, but some programs are slowed down by this in practice. Can we expect improvements in that area as well?
  - lozenge 8y ago
    As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.

oldgradstudent 8y ago

The article seems to ignore the other big problem with the Windows console. It is painfully slow compare to Linux and Mac terminal programs. Especially when scrolling large amounts of text.

izacus 8y ago
Is that true for other UIs like conemu?
- oldgradstudent 8y ago
  Good question. The article says that > Alas, the story here is not a good one: There ARE some great 3rd party Consoles (and server apps) for Windows (e.g. ConEmu/Cmder, Console2/ConsoleZ, Hyper, Visual Studio Code, OpenSSH, etc.), but they have to jump through extraordinary hoops to act like a normal Console would! > For example, 3rd party Consoles have to launch a Command-Line app off-screen at, for example, (-32000,-32000). They then have to send keystrokes to the off-screen Console, and screen-scrape the off-screen Console's text contents and re-draw them on their own UI!! I'd guess that the third party emulators might perform worse, but someone need to test it empirically.
  - laumars 8y ago
    That bit you've quoted is only half the story. I've written both terminal emulators as well as ported my own UNIX shell to Windows and never resorted to those kind of tricks. However the stuff I've focused on isn't interactive commands (ie just normal POSIX-like file streams). The moment you envoke "del" or other command that prompts "Are you sure you want to delete" (or whatever) then for some odd reason Windows just jumps over that STDIN read request and ploughs through the rest of the program. I can't say if this is a bug in my shell specifically or a wider problem that has lead to the work around you described, but it's literally the only problem left in my Windows port and I'm definitely not smarter than average nor have I spent any excessive time working in Windows so I cannot see how I might have solved problems that other shells are still grappling with given the limited time I've spent on the Windows specific portion of the code. As for the bug itself, I get this is a pretty major bug which severally hampers the usability of the shell but I think given enough time (and a new development machine to test it one since I now longer have access to a Windows laptop after changing jobs) I could get this bug solved too. Hopefully without resorting to the kludge you described, but who knows.

zerr 8y ago

> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it! It smells like ageism... Did you lay off the original "old" devs? EDIT: :)

jhall1468 8y ago
I'm hoping this is a joke. Most developers don't stay at the same company on the same team for 30 years...
zadjii 8y ago
Lol any original devs retired a long time ago, can you imagine what $MSFT shares from 1989 are worth now?
- drblast 8y ago
  Don't even have to imagine. NASDAQ: MSFT $104.40
  - phs2501 8y ago
    With stock splits 1 share in 1989 would be 72 shares now. So $7,516.80.
- sun41 8y ago
  What the heck is this related to shares? You mean to suggest all original devs are millionaire, and that being a millionaire means you don't code anymore? And you, poor guy, missed out?
  - erikbye 8y ago
    Early MSFT employees were compensated heavily with stock options. I think it's also pretty safe to say that few devs from that period are still coders, they've moved on to other roles or retired. From Show Stopper!: Technical preferences aside, the success of Windows was a windfall for Cutler and colleagues. Most had received sizable stock option grants on joining Microsoft, partly to compensate for their reduced wages. At other companies such stock grants might return 10 to 25 percent profit to a grateful employee over five to ten years. A doubling of value would be a bonanza. But lately Microsoft's stock had soared-with no limit in sight. Demand for Windows transformed Microsoft from the leader of the software pack into a giant looming over the rest of the industry. The company's net profits were especially impressive; an astonishing 25 percent of sales flowed to the bottom line. Options granted to Cutler two years earlier, while substantial at the time, were now breathtaking. And the stock price seemed a cinch to double over the next few years, given the company's bullish outlook. Even at the current stock price, Cutler's options now were worth at least several million dollars. Havens and Perazzoli, meanwhile, were assured of clearing high six figures. Even the team's rookie programmer, hired fresh from Princeton the summer before, would reap a few hundred thousand dollars within three years.

m_st 8y ago

I tried using PowerShell or Hyper. But these are just so slow to start. So I'm always coming back to cmd.exe. It is fast and serves my basic needs just perfect. When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper. So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe. Keep improving cmd.exe. But please don't make it bloated.

ilikehurdles 8y ago
Do you have something custom going on in powershell? I’m not a power user of windows shells but it opens very quickly for me. So much so that I never thought about the speed of either terminal.
- userbinator 8y ago
  "very quickly" is subjective, but compared to cmd it is noticeably slower even in a fresh install of Windows --- the few times I'm forced to actually use it to configure some things.
  - Tarean 8y ago
    I think powershell is kept in memory so only the first start should be slow. Although I don't really notice the first start being slower anymore - maybe it preloads depending on settings or is just fast enough with an ssd?
    - ygra 8y ago
      Windows picks up usage patterns and pre-loads applications to match that. But indeed, right after launching an application it's still in the disk cache anyway, so subsequent launches (until heavy I/O) should be quick.
    - Catfishfinger 8y ago
      This makes sense, I use Powershell all the time, have loads of PS modules installed and it opens pretty much instantly.

tempodox 8y ago

So, MS has finally realized they're 40 years behind the civilized world. I'm curious to see how long it will take them to catch up.

0xFFFF0000 8y ago
Not sure what you mean... PowerShell Console is one of the most modern and advanced consoles there is and it's from Microsoft (compared to old non object oriented and pipelined stuff like cmd here in the article) - but it's still good to see that they haven't forgotten about the good old cmd.exe :)
- ygra 8y ago
  You're mistaking the shell for the console. As the article quite clearly points out, there's a vast difference between both, even though when you look at a console application (such as a shell) you kind of always see both.
gaius 8y ago
So, MS has finally realized they're 40 years behind the civilized world Yes they should be emulating a teletype like enlightened folk!
- oblio 8y ago
  You mean you don't actually print your output?!? Heathen!
- ziotom78 8y ago
  Very appropriate comment. Last year I was tinkering with the implementation of a TUI (Text User Interface), and I wanted it to be cross-platform. I started developing it under Windows, using the Console API (sorely lacking in features, but at least it is just an API to be called from C). I had to abandon the project once I realized that it would have been too hard to harmonize this approach with the weird way you are supposed to program a Unix console. Let's consider the difference between calling an hypotetical system API to change the text color and a raw sequence of bytes encoding. In Unix, to set the color to be used for writing characters you have to send an ESC character, some more bytes, and then an ASCII representation of the R, G, and B components (assuming your virtual terminal supports this), separated by a colon/semicolon. The terminal will then read this sequence, parse the three numbers and move the character. This approach is not precisely efficient, especially if you consider that today it is not unlikely to have full-screen terminal applications with a large resolution. For a 200x60 terminal like the one I am using right now, to color every character with a different color requires sending 500 Kb of data, compared to the 36 Kb required by a 3-byte representation of each RGB tuples. And if you are trying to read from a terminal, every time you receive an ESC key, you are always in doubt whether the user pressed ESC, or if it is the start of an ANSI sequence. The usual trick here is to check if there is a character already available immediately after you detect an ESC byte coming from standard input: if there is, you can assume it's the beginning of a sequence. Admittedly the virtual-terminal approach makes remote connections (through SSH) simpler than an API (you just have to send a bunch of bytes through a socket), but I wonder why in 2018 we are still relying on the old and quirky mechanism of "virtual consoles" when real consoles have long disappeared. Edit: small fixes.

chungy 8y ago

Technical errors regarding how UTF encodings work: * UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before Unicode settled on U+10FFFF[1] being the maximal codepoint for backwards compatibility reasons with UCS-2...) * It says UTF-16 extends UCS-2 (which is correct) by incorporating a 4-bit encoding... which probably was intended to be a "4-byte encoding" instead. The surrogate pairs reserve their first six bits for an additional 10 bits making up half of the codepoint being stored (whose value is later added to by 0x10000 to get the actual codepoint). Also, it provides 16 additional planes to the BMP. 17 total including the BMP. [1] Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict.

jwilk 8y ago
> Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict. This is what Unicode 11.0, §2.4 says: Noncharacter code points are reserved for internal use, such as for sentinel values. They have well-formed representations in Unicode encoding forms and survive conversions between encoding forms. This allows sentinel values to be preserved internally across Unicode encoding forms, even though they are not designed to be used in open interchange. It would wrong for a general-purpose parser to reject these codepoints.
- chungy 8y ago
  Hmm, alright. I have seen parsers reject them, presumably from misinterpreting the standard. Thanks for the correction :)
bitcrazed 8y ago
Hi - Windows Console PM and author of the post here :) You're absolutely correct.I made some fixes, adjustments, and clarifications to the post this afternoon - hope they're a little more accurate. We'll be digging into this area in much more detail in future posts.

tofflos 8y ago

I love reading about the work that's being put into old apps like Console and Notepad. Keep it up!

dvfjsdhgfv 8y ago

I love Cmder, it's superior to cmd.exe in all possible ways, but from time to time it just stops working. Now I understand better why.

ygra 8y ago
cmd is the shell, Cmder (which is just a wrapper around ConEmu) is the console/terminal. Both have little to do with each other, apart from that one needs the other to show a window.
EnderMB 8y ago
I haven't done any Windows dev since last year, but I've often wondered why more .NET devs don't use Cmder. I've always been a fan of a full-screen console with split panes (tmux style), and other developers have looked at me like I'm some sort of wizard, despite using fairly basic tech. Sure, it takes a little while to get used to Powershell, but once you get over the hump it's really useful knowledge to have, especially if you have anything to do with devops or deployments.
bitcrazed 8y ago
G'ah - PLEASE read the posts about which you're commenting - Cmder is a terminal/Console, not a shell. Cmd.exe is a (headless) command-line shell. A shell accepts input from a terminal/Console and emits text to its connected terminal/Console to be displayed back to the user. All this is covered in some detail in the posts thus far.
- dvfjsdhgfv 8y ago
  That's quite clear, I have no idea why people assume I confuse the two. I just said the article helped me to understand why Cmder has certain problems.

slinzer 8y ago

Too many exclamation marks.

bitcrazed 8y ago
Fixed! Let me know if you prefer the updated version I posted this afternoon. Thanks for the feedback :)

frankohn 8y ago

I like the post, it seems like they are good guys doing a good work on an unrewarding application. It is interesting the insight thet are giving with this article: - MS is improving on Windows Console only because of WSL - the design of the Windows Console was flawed since the beginning and remained unchanged to something like 30 years. Flaws includes: - using Console API instead of sending characters / cannot work remotely - the shell and the terminal are not clearly separated: the OS will open automatically a console for some kind of executables / cannot attach a shell to an arbitrary console It seems to me that it shows a few things. First, unix design was better as it was more flexible and lasted over time and computers evolution. Windows' design was sort of wrong since the beginning but they didn't change anything and developers were left to use one of their horrible APIs. This is similar to the difference between X Window and Win32 GUI API. Second, MS does not care about developers except for the user of their flagship product Visual Studio. They put 30 years of developer effort solely on Visual Studio and nothing else. Compare with Apple, they at least cared of implementing an excellent terminal and contributed greatly to the wonderful LLVM compiler infrastructure. So, okay some improvements might lands on Windows 10 at some moment but I personally don't care. At work we still use Win 7 and I think we will keep using it for a long time. The Windows Console is just horrible to use and propram for and a testament to the MS awful software and APIs that developers are forced to use because of Windows dominance.

ygra 8y ago
I didn't get the impression that they consider the Console API in itself a flaw. An API for this is much more robust than an in-band text API that's part of your output. For example, no Windows console application has to even think about whether printing a user-provided string can be a problem. They do note that it's an impediment for porting software to Windows, as well as the problem that the API isn't able to be implemented by any other application, e.g. ConEmu. Those applications have to rely on scraping a hidden console window to work instead of just being an alternative console implementation. I read it not so much as a testament to the perceived superiority of the Unix model, but rather that with WSL users expect certain things to work more Unix-like, just that they don't work like that right now.
- 8y ago

a-dub 8y ago

Is Microsoft taking a page out of ol' Vladdy Putin's playbook? Why is this upvoted? The Windows console is garbage software on top of garbage software.

logcat 8y ago

There are ways to get much better terminal experience for typical web dev https://blog.ropnop.com/configuring-a-pretty-and-usable-terminal-emulator-for-wsl/ https://blog.ropnop.com/configuring-a-pretty-and-usable-term... (also works for tilix)

cbolton 8y ago

This a very candid and informative look at the Windows console and it comes from Microsoft! I'm impressed. Congrats to the writer and thanks for posting!

sevensor 8y ago
This is of a piece with Microsoft's GitHub acquisition -- seems to be part of a program to win developer mindshare. And it's working; I was impressed by this post, both tone and technical content. Windows having never really been suitable for the server, and rapidly losing its grip on the home user, it seems totally sensible to push the "windows is a good platform for people doing serious work" angle. It's all Windows has left.
bitcrazed 8y ago
Hi. Windows Console PM and Author of the post here :) Thanks for your kind words. Glad you liked it - check our blog often - LOTS more posts coming on this subject!

megaman22 8y ago

Yikes, the anti-Windows crowd is strident today. Yeah, cmd.exe is crap, and if you're expecting to use a Unix workflow rather than learn how things work in Windows, you're going to have a bad time. I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware from fifty years ago is really a great ideal either... But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, or you'll break things in a way that has been historically unacceptable in Redmond.

vetinari 8y ago
> I'm not sure that religiously sticking to the baggage and constraints of obsolete hardware > But you just can't change existing shit willynilly in Windows, with the kind of install base and legacy it has, You do see the irony, right?
- tom_ 8y ago
  I think his (?) point is that if you don't have the backwards-compatibility goals of Windows, you can afford to be - and perhaps should be - a lot more adventurous. Which is something POSIX systems have summarily failed to be in this respect, for all that they've managed to polish that turd to an acceptable shine.
  - vetinari 8y ago
    What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems? I read the above sentences as: 1) the legacy on $SYSTEMS_I_DONT_LIKE is bad 2) the legacy on $SYSTEM_I_LIKE is there for a reason.
    - AnIdiotOnTheNet 8y ago
      > What exactly are backwards-compatibility goals of Windows? Are they that different from backwards-compatibility goals of POSIX systems? I can still run software written for Windows 95, without recompilation, with a pretty high success rate. As far as I'm aware, only Linux has that level of ABI compatibility and unfortunately it's completely broken by userspace. Often you can't even run the same binary on two different distributions without recompilation.

gigatexal 8y ago

They should just replace it with the power shell prompt that wraps the command line.

gigatexal 8y ago
Too many fans of the command line from the 90s. Oh well.

nailer 8y ago

As a nix person who now spends his entire day in the Windows terminal, I wrote a guide to setting up the console and pwsh for maximum productivity: https://github.com/mikemaccana/powershell-profile/blob/master/README.md https://github.com/mikemaccana/powershell-profile/blob/maste...

7kmph 8y ago

Who cares anyway

lagadu 8y ago
Well, you cared enough to post. Now imagine all the people who actually enjoy reading insights about developing software that we've all used.

deejbee 8y ago

One thing I've always missed is tabbed consoles. I've use Cmder (http://cmder.net/ http://cmder.net/ I have no affiliation) for quite a while now and has been totally awesome as it provides a tabbed container window with any mixture of cmd.exe, bash shell, launching as Admin and best of all it persists all your windows after reboot.

neilsimp1 8y ago
Another Cmder lover here. Although when the Windows 10 "Sets" UI comes out and default Powershell/conhost has tabs built in, it may be time to just stick with that. We'll see...
- duncanawoods 8y ago
  Pretty unhappy Cmder user here. Sooo many bugs. Currently have dash.exe crashes on start-up, fatal race conditions generating certain types of error output, performance becomes unusable in git folders with lots of files because of how it updates the auto-text in the prompt and it has the configuration/settings from hell but they just blame ConEmu. I just want a tabbed console that will remember the tab locations and command history between sessions. This would seem obvious thing but no.
  - 1996 8y ago
    I run mosh on windows 10 over bash inside cmder, I have had a few weird issues too. I thought I was the one at fault!!
Serow225 8y ago
https://blogs.msdn.microsoft.com/commandline/2018/04/13/tabbed-console-starts-here/ https://blogs.msdn.microsoft.com/commandline/2018/04/13/tabb...
zadjii 8y ago
Trust us, the pain on not having a tabbed console is felt here in the console team too. It's our most requested feature, but implementing it has always ended up a lot harder than expected. Fortunately we're working with the Tabbed Sets team to help nail that experience for the console.

OliverJones 8y ago

Very interesting. I learned a lot. The author mentions "re-re-re-implementing" command line history as a disadvantage of using shells in a dumb terminal emulator. But, with respect, I think he's wrong about that. Command line history is a valuable productivity enhancer, and tying the details of its operation to the terminal rather than the shell restricts functionality and flexibility. For example, witness the differences between git bash (mingw) and cmd on Windows. Inbuilt OS stuff should be as simple as possible. It doesn't have to be precisely /dev/tty - like, but it should be simple. Partly to avoid bloat, and partly because it's much less flexible than userland stuff. Even when RAM was worth twice its weight in gold, various UNIX shells weren't heavy. Now? not worth worrying about. I admit I came up as a UNIX user so I favor sh-like history. But still, Windows terminal history just isn't as good. (I wish it didn't deduplicate repeated commands and lose them when they're edited.)

laumars 8y ago
There was a few points the other raised which I disagreed with and that was one of them. I completely agree with you that shell history should be managed by the shell itself. I also didn't agree with the points about Console API. I mean sure, he's right that ANSI / VT escape sequences are naff, but they are the standard so we're stuck with them. However as much as I love the idea of a Console API, the fact that they only work on local host is just inexcusable. And I don't say this because "hindsight is 20/20", there was already decades of proven example that remote consoles are worth having before the console API was even written. Why they couldn't have created is a network API (ala rsh) is beyond me. But we are where we are. Some of the examples given about OOP was just plain wrong too. You can't bunch 20 years of object oriented langaues together and say "they all quickly followed". 20 years is not quick; not in real terms and most definitely not in IT terms. What surprised me the most when reading that article is that NT was originally command line driven with a GUI added for release. It's amazing just how bad the console sucks even without taking the evolution of NT into account; and now that I know NT was originally command line oriented, well I'm just shocked. If there was anything good that can be taken from the article, it's that it sounds like they are working on better terminal / shell separation which will enable developers to write better terminal emulators and better alternative shells. Plus potentially allow for a networked shell. My next request after that would be to write a unified way of splitting ARGS because their current method of passing all command line parameters as a single string is just terrible (yes, I get that's DOS legacy and impossible to change due to backwards compatibility, but isn't it about time Windows had a standard API for splitting that ARGS string so, going forward, programs can be written to split parameters in a consistent way meaning command line users know exactly when they can and cannot use quotation marks, spaces and escaped characters, etc.

jscholes 8y ago

Found the article content quite interesting but the tone of the writing (emojis and exclamation marks everywhere) really put me off. Sounded forced and added nothing.

degenerate 8y ago
It reminded me of a very excited Steve Ballmer: https://www.youtube.com/watch?v=HMhrRovP9qA https://www.youtube.com/watch?v=HMhrRovP9qA
bitcrazed 8y ago
Fair comment - I agree and so removed a bunch of !'s and emoji for you, though I did leave a few in to convey some of my (and the team's) excitement - we're genuinely buzzed to be able to massively improve the Console. Hope you find the latest updated version more palatable.

xvilka 8y ago

Hopefully, support for bidirectional text will be added soon. Microsoft needs to lead the way of handling it in console programs. Even in UNIX systems, only a few terminal emulators support bidirectional text properly.

zadjii 8y ago
Could you go submit this to our UserVoice? https://wpdev.uservoice.com/forums/266908-command-prompt-console-windows-subsystem-for-l?category_id=87960 https://wpdev.uservoice.com/forums/266908-command-prompt-con... I'd say that bi-directional text is a pretty low priority at the moment. We just haven't really heard any asks for it, and like you said it's poorly supported on other platforms (if at all).

cryptonector 8y ago

I really like the point that an API-centric console does not remote well (think ssh). In general I prefer the WIN32 object-handle model to the Unix file-descriptor model, and I much prefer the WIN32 security descriptor and access token model to the Unix haphazard security model, but very clearly, the everything-is-a-file model is superior at least for remote access: it's easier to design and implement protocols for that since the protocols don't need to know anything about the remote resources' nature. Thus the Windows console cannot be exported via SSH, not without writing a layer that converts text reads/writes into ioctls, because it's not remotely file-like. That the Windows team had to and did write that layer really is fantastic news.

iforgotpassword 8y ago

Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search? Is this just me? Late to the party? In case this isn't temporary: https://web.archive.org/web/20180717165103/https://blogs.msdn.microsoft.com/commandline/2018/07/10/windows-command-line-inside-the-windows-console/ https://web.archive.org/web/20180717165103/https://blogs.msd...

bitcrazed 8y ago
LOL - nothing nefarious - made a few corrections and improvements to the post - aaaaand managed to bork the publishing process which took a few mins to re-generate and refresh the cache! Ugh! Should be back up and available now!

zaat 8y ago

I'm late to the party, but maybe the console guys are still lurking. If so, than first and foremost I wanted to thank you for the amazing walk you guys took the console so far. That said, as someone who uses your product for hours on daily basis, I have two pain points that I would love to have fixed, if that possible at all: 1. selection of text and deletion - works in PowerShell, doesn't work in cmd. Is this curable? 2. Customizing the console is pain. I don't mind doing it once but it is impossible to save theme and copy it between computers. It is also impossible to export registry keys - not only do they differ for various consoles, the color settings are not saved there. The only way I found so far for achieving this is copying the shortcut for the specific console - the colors are saved to the .lnk file in binary form. Seriously, can we have at least color exportable themes in a format that can be edited with a text editor?

bitcrazed 8y ago
Hey @zaat. Thanks for your kind words :D Alas, deleting text is an operation controlled via the shell. PowerShell's (awesome) PSReadLine does it for PowerShell, but introducing that kind of behavioral change is unlikely to be possible in Cmd because, as pointed out in the posts, Cmd is in maintenance mode, is extremely fragile, and it's key MO is backward compat, which includes behaviors because many tools, and scripts depend on behaviors (even broken ones) as "Features" ;)
- zaat 8y ago
  Thank you for answering. Any chances on number 2, especially color themes?
zadjii 8y ago
I think rich (@bitcrazed) already talked a bit about #1, so I'll share a bit on #2. I agree, the current properties story is INSANE. I don't get how whoever wrote it even came up with it - it's likely a frankencode system that we're stuck supporting for now. I can't tell you how many times I've had to explain how the console settings work, and how your settings can be different depending on how you launch the console. It's been a pain point I've had a particular eye on since I started here. It's a powerful system that is very prone to "you moved my cheese" syndrome - It's REALLY hard to change it into a sane system without breaking someone's workflow. That being said, I have a bone to pick with that system, and I think I might have some spare cycles to finally get to it soon :) PS: While we're on the subject of colors, lemme quick throw out (Colortool)[https://github.com/Microsoft/console/tree/master/tools/ColorTool https://github.com/Microsoft/console/tree/master/tools/Color...]. It can be really helpful for quickly changing the color scheme of the console. It's not great for everything, but I've found it super helpful.