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

161–170 of 259 posts

Re: Inside the Windows Console

#161

Post by nickjj »

dagw wrote: post #88
electricEmu wrote: post #40

Earlier quoted context omitted.

I'm not sure how often you start and stop your shells, but start time is seldom a concern. I enjoy you chose Hyper.js, which uses electron. I'm not sure what speed you were expecting there. You might try ConEmu https://conemu.github.io/ .

I love ConEmu, but it's still pretty slow starting up

What's your definition of slow?

ConEmu takes about 1 full second to open a new window. Not too bad.

But oddly enough, opening a new split panel takes about 2 seconds, which IMO is starting to feel slow, but it's not too big of a deal.

Re: Inside the Windows Console

#162

Post by laumars »

JdeBP wrote: post #110
laumars wrote: post #80

Earlier quoted context omitted.

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

Actually, the part that you have addressed is half the story. I wrote about both halves a couple of decades ago. * http://jdebp.info./FGA/capture-console-win32.html

Interesting read. Thank you.

I wonder how many programs are still using low level access these days given that's more a throw over from the DOS days and most languages will have proper frameworks for reading and writing from the NT console. del et al being obvious exceptions because they're just cmd.exe builtins.

Unfortunately I don't have a Windows system to test that assumption but when I think about when I last did my testing, that was only against the cmd.exe builtins so it's possible this bug I was experiencing isn't as widespread as I assumed

Re: Inside the Windows Console

#163

Post by AnIdiotOnTheNet »

Macha wrote: post #148
AnIdiotOnTheNet wrote: post #147

Earlier quoted context omitted.

I think your experience is atypical. I use powershell everyday and I've not noticed any startup time difference between it and cmd. Are you sure you don't have some gigantic import in your profile.ps1? Are you launching the really terrible and definitely slow as balls to launch Powershell IDE? Frankly, given how superior powershell is as a language (both to cmd and bash) it is beyond me why anyone would consider a sm…

I've got no powershell customizations, and an i5-4670k. I've also experienced Powershell having a very noticeably slow startup. It's about on par with my heavily modified zsh setup on a 2015 MBP for startup time (the same zsh setup starts up much faster on the same desktop). It's not a dealbreaker, but it's definitely an annoyance.

Very strange. My work rig is a downright geriatric Core2 Quad @ 2.66Ghz. There has to be some reason for the difference.

Re: Inside the Windows Console

#164

Post by vetinari »

megaman22 wrote: post #124

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…

> 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?

Re: Inside the Windows Console

#165

Post by duncanawoods »

neilsimp1 wrote: post #149
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.

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

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.

Re: Inside the Windows Console

#166

Post by Catfishfinger »

Tarean wrote: post #137
userbinator wrote: post #131

Earlier quoted context omitted.

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

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?

This makes sense, I use Powershell all the time, have loads of PS modules installed and it opens pretty much instantly.

Re: Inside the Windows Console

#167

Post by sevensor »

cbolton wrote: post #120

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!

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.

Re: Inside the Windows Console

#168

Post by pjmlp »

frankohn wrote: post #118
oblio wrote: post #109

Earlier quoted context omitted.

X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.") Besides the fact that the X libs are almost universally reviled and nobody used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that of network part is actively being abandoned right now, see the Wayland ef…

> X Window has a good design? Only because it allowed competing tool kits on top of it ("Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.") Yes only this simple thing made a much better design. It can be used to provide a modern and beautiful desktop environment even 35 years after its creation. > Besides the fact that the X libs are almost universally reviled an…

Even when compared against Amiga toolkits and Win16, Xlib with Athena or Motif were anything but pleasant.

X Windows is the main reason of "The Year of Desktop Linux" failure.

It is quite telling that ChromeOS and Android have ditched it.

Also the only UNIX that was actually a pleasure to code for was NeXTSTEP, guess what, it also didn't care for X Windows other than compatibility purposes.

Re: Inside the Windows Console

#169

Post by repolfx »

ygra wrote: post #102
frankohn wrote: post #97

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

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

The most obvious problem of their design is that there's no serialisation mechanism for their API calls, so apps don't remote over low bandwidth connections. Which is one of the big advantages of terminal apps to begin with.

Microsoft did objects better later on with COM and DCOM: you can imagine a better console API if COM had come first, but even then, DCOM network protocol was not good and had numerous problems that would have meant ssh still beat it. But trying to do OO API in 1989 with their tech stack wasn't a good idea.

Re: Inside the Windows Console

#170

Post by mwcampbell »

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.

Are you using a high-DPI display? In my experience, scrolling in the console is much slower on a high-DPI display.
Post reply on HN