Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside the Windows Console

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

221–230 of 259 posts

Re: Inside the Windows Console

#221

Post by delfinom »

zadjii wrote: post #180
oldgradstudent wrote: post #20

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.

I would agree that our perf isn't the best. Almost all of that comes down to our rendering stack - something like 90% of our CPU time is spent rendering the window. This is because at the moment we're stuck with GDI, and IIRC we have to kernel-thunk every row of text we render. It's not a great situation. Stay tuned for updates in this area though. Improving this experience is one of our top priorities.

GDI?!

Throw that bad boy into the abandoned WPF framework and hardware accelerate it! (Without the sandbox shengigans of UWP in the way)

Re: Inside the Windows Console

#222

Post by bitcrazed »

m_st wrote: post #24

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.

Hi there! Author of the post that's the subject of this thread here :)

Two questions:

1. Does your machine use a spinning disk for its system drive, or SSD? If the former, that's slowing you down more any anything else. STRONGLY recommend moving to SSD system drive if so. 2. Have you tried `powershell /noprofile` from Run dialog or Cmd? If you're still seeing PowerShell take > 600ms to load and start, likely something else is up.

If you're expecting PowerShell to load faster than ~600ms, your expectations are likely a little out of whack - Cmd loads so fast because it's tiny and - relatively speaking - as dumb as a stump. PowerShell is a .NET language, and so loads the CLR, so incurs some overhead vs. Cmd, but it does A TON more that'll save you more time and effort over-all than any amount of time saving vs. starting Cmd.

HTH.

Re: Inside the Windows Console

#223

Post by bitcrazed »

bitcrazed wrote: post #222
m_st wrote: post #24

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.

Hi there! Author of the post that's the subject of this thread here :) Two questions: 1. Does your machine use a spinning disk for its system drive, or SSD? If the former, that's slowing you down more any anything else. STRONGLY recommend moving to SSD system drive if so. 2. Have you tried `powershell /noprofile` from Run dialog or Cmd? If you're still seeing PowerShell take > 600ms to load and start, likely somethin…

Oh … and re. Hyper - its awesome and beautiful, but it's an Electron app which means you're first loading and starting Electron base, then Chromium's JS & HTML engines, then loading A TON of JavaScript which has to be tokenized, parsed, compiled and executed every time you run it.

This doesn't come cheap. Electron consumes & fills ~100MB working set just to get rolling, plus several more tens of MB to load, compile and execute.

For example, on my 16GB Core-i7 Surface Pro 4, starting a single Hyper instance connected to Cmd, requires 134MB. Starting Console takes < 1s, and consumes 6MB.

Re: Inside the Windows Console

#224

Post by bitcrazed »

deejbee wrote: post #145

One thing I've always missed is tabbed consoles. I've use Cmder ( 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.

Hi - Windows Console PM and author of the Command-Line posts here.

We hear ya. Tabs are VERY high up our to-do list, but to get there, we had a TON of internal engineering and modernization to do to wrangle the ~30 year old codebase into a shape where we could efficiently and effectively work on UX features.

We're now nearing the completion of the core re-engineering effort and will start to turn to more UX-visible features in the next few releases.

Bear with us - TONS of exciting stuff coming soon!

Re: Inside the Windows Console

#225

Post by bitcrazed »

chungy wrote: post #35

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…

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.

Re: Inside the Windows Console

#226

Post by bitcrazed »

delfinom wrote: post #221
zadjii wrote: post #180

Earlier quoted context omitted.

I would agree that our perf isn't the best. Almost all of that comes down to our rendering stack - something like 90% of our CPU time is spent rendering the window. This is because at the moment we're stuck with GDI, and IIRC we have to kernel-thunk every row of text we render. It's not a great situation. Stay tuned for updates in this area though. Improving this experience is one of our top priorities.

GDI?! Throw that bad boy into the abandoned WPF framework and hardware accelerate it! (Without the sandbox shengigans of UWP in the way)

Hi. Windows Console PM, and @zadjii's whipping boy here :)

LOL :) Nice idea - though it turns out that this won't help. Don't ask me why we know this ;)

We DO, however, (as @zadjii indicates above) have plans afoot to considerably improve Console's text rendering.

Also note that scrolling speed is actually not a good measure of rendering perf! Why? Because at most, scrolling should max-out at around one vertical page every 1/60 of a second. Any more than that and the text tears.

This may or may not be an issue for some, but tearing the text upsets people who're visually looking for a particular text layout-pattern which might get discarded if the Console scrolls faster than one page per refresh.

This said, yes, we're gonna get faster with less CPU ;)

Re: Inside the Windows Console

#227

Post by bitcrazed »

OliverJones wrote: post #151

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 differ…

Hey Oliver - Console PM and author of the above post here.

Glad you learned lots - makes writing it worthwhile ;)

I didn't mean to imply that command history is not a productivity enhancement - it absolutely IS!

What I was saying was that in the absence of a system/terminal-provided command history mechanism, every shell has to implement its own. Cmd needs it. PowerShell needs it. Bash needs it. Zsh … fish … yaddayaddayadda need command-history.

So if every shell (and many apps) need a command history buffer, why not provide command-history as a service from the terminal. There are MANY amazing and valuable things one could do if one could consistently log/store/serialize command-history for later replay, analysis, etc.

I agree 1000% that Windows' command history is FAR from good, but I think there are some pretty awesome things we could do to make it so.

Bear with us on this ;)

Re: Inside the Windows Console

#228

Post by zadjii »

zaat wrote: post #216

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 curabl…

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/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.

Re: Inside the Windows Console

#229

Post by zadjii »

cryptonector wrote: post #197
zadjii wrote: post #183

Earlier quoted context omitted.

We're certainly not improving the console only because of WSL - WSL has highlighted a lot of functionality that we could improve upon, yes, but we're improving the console because the console needs improving. I'd say that we're conceding that the linux commandline application model (having two streams of characters) is more portable and cross-platform compatible. The Windows Console API isn't particularly well design…

So... I think the Windows model is superior in these respects: - object handles >> file descriptors - security descriptors >> {owner, group, mode, [acl]} - access tokens >> [gs]et[e]?[ug]id(), [sg]etgroups(), initgroups() But everything-is-a-file makes things generic, which means they can be remoted (as you put it), which means I/O redirection in shells is trivially transparent to the programs being run , etcetera. T…

Oh I'm certainly not conceeding that Linux as a whole is better than Windows - there are pros and cons to each. But I've found that writing console applications with VT sequences to be a generally preferable experience to the Console API. Now that we've added support for VT sequences, writing a cross-platform commandline application is pretty trivial - just use VT on every platform.

I feel you pain with the CRT, though I agree with the sibling comment, the uCRT is a way better experience. I know there is a team of pretty talented people working on that, but I think way below the level that's able to influence the allocation of developer resources - otherwise the console would have a lot more than 3 people on it :P

Re: Inside the Windows Console

#230

Post by bitcrazed »

laumars wrote: post #189
OliverJones wrote: post #151

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 differ…

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…

Hey Laumars - Console PM and author of the post here:

Fair points in part, though …

Remember that things like Remote Desktop obviated the pressing need for command-line --> remote command-line access for many years. RDP quickly evolved into a very efficient way of remoting the entire desktop experience, not just Command-Line - something that was particularly necessary until PowerShell started to mature due to Windows' heavy GUI tool influence (for better and worse).

Don't despair though - there's a VERY interesting post coming soon on this subject, that I think you'll enjoy! ;)

I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and then, other than research efforts, relatively little until CFront/C++ around '85. After that there was a new variant of C++ or new object oriented language almost every 8-12 months ever since - ObjectBASIC, Modula-2, ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a language explosion.

And, of course NT started as a command-line OS. All new OS' start that way it's the simplest UX to get running. The Windows GUI wasn't slapped on at the end though - it arrived relatively quickly since Microsoft was able to leverage much of the experience of having build Windows 3.x/9x etc. previously.

Command-line args are not all passed as a single string. In Windows, args are separated by space. If you use C/C++ and others, you get argv and argc, or in C# you get an array of space separated values.

Alas, when NT came along it was seen as EXTREMELY important to make it easy to run/port MS-DOS scripts and tools to encourage migration and adoption. By this time, so many tools used so many ways of specifying args and values … / vs. \ vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to both support backward compat while rationalizing usage.

PowerShell, though, has done much to make args MUCH more consistent, self-documenting, etc.

This said, yes, it'd be AWESOME if args could be rationalized and handled in a more consistent manner. Had a fascinating discussion about just this the other day. Stay tuned to our blog ;)

Post reply on HN