201–210 of 259 posts
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…
Earlier quoted context omitted.
Afaik, 10ms is not achievable nowadays, unless you use a very old computer. https://danluu.com/input-lag/
> For desktop results, results are measured from when the key started moving until the screen finished updating When the key starts moving and when the key actually actuates are very different times. Some of this latency could be key travel time. This is also a methodical issue I found with his [keyboard latency test]( https://danluu.com/keyboard-latency/ ).
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.
Earlier quoted context omitted.
Unfortunately it has no effect on the menu in Windows Explorer which also dropped cmd for PowerShell recently.
I tend not to use the file menu in Windows Explorer, but yeah it'd be nice if that option swapped it there too. I found out recently you can just type "cmd" in the Explorer address bar and hit enter and it'll open cmd.exe to the current directory, so long as you're not in a special shell folder or an unmapped network share. That's saved me a bunch of time.
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 regularly use both Windows and Linux, and I can't say that I've ever noticed a performance problem?
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.
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…
Is this just me? Late to the party?
In case this isn't temporary: https://web.archive.org/web/20180717165103/https://blogs.msd...
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…
Earlier quoted context omitted.
I just started turning Quick Edit off because I understood it was responsible for that strange bug where the console sometimes gets stuck until you press return. :-( Is that one on the to do list?
That’s how selection has always worked. It halts console output until you’re done selecting.
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.") 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.
... doesn't exist, of course.