Live data from Hacker News

Inside the Windows Console

blogs.msdn.microsoft.com

121–130 of 259 posts

Re: Inside the Windows Console

#121
post #98
post #91

Earlier quoted context omitted.

With Core they are even used for new projects running on Linux.

But exactly, that's my point. You no longer even need to be on Windows to use C#.

Technically. But it's not really there yet. Most people writing C# code are still using the 4.5+ full desktop framework on Windows.

Re: Inside the Windows Console

#122

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’ve just run “tree /f” from the root of my drive. It printed huge amounts of text but the scrolling remained instant.

I think your big problem is not necessarily with Windows console, could be with the command-line apps you’re using in it.

Re: Inside the Windows Console

#123
post #64

Earlier quoted context omitted.

I regularly use both Windows and Linux, and I can't say that I've ever noticed a performance problem?

The terminals you use in Linux must either be painfully slow or you must be very insensitive to latency issues because the latency on Windows console is really high. When I type something I expect it to appear immediately ( A lot of basic commands in general run more slowly on Windows but I don't think that's the terminal's fault so much as it's lack of optimisation on the command itself.

Afaik, 10ms is not achievable nowadays, unless you use a very old computer. https://danluu.com/input-lag/

Re: Inside the Windows Console

#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 of install base and legacy it has, or you'll break things in a way that has been historically unacceptable in Redmond.

Re: Inside the Windows Console

#128
post #39
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.

Powershell 5 is slow. Powershell 6 preview is much faster (not as fast as bash but does more)

PS you can download it here

https://github.com/PowerShell/PowerShell/releases

Re: Inside the Windows Console

#129
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…

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

Re: Inside the Windows Console

#130
post #98
post #91

Earlier quoted context omitted.

With Core they are even used for new projects running on Linux.

But exactly, that's my point. You no longer even need to be on Windows to use C#.

You do if you want to use visual studio, which according to Stackoverflow's survey is the second most popular development environment (less than 1% behind visual studio code)[0]

Not to mention that in the enterprise world Java and .net have an overwhelming market share.

[0] https://insights.stackoverflow.com/survey/2018/#development-...

Post reply on HN