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

191–200 of 259 posts

Re: Inside the Windows Console

#191

Post by cryptonector »

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…

I really don't understand why I would want the terminal to be aware of command-line history. That seems completely wrong. On Unix one can have a terminal used by a non-shell application -- what would a terminal's command-line history mean in that case?

Re: Inside the Windows Console

#192

Post by cryptonector »

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…

Hear hear!

Terminal escapes... you know what, they may seem ridiculous, but they work with a read/write API instead of an ioctl API, and that makes all the difference. And they work with serial ports and terminals. From day 1 terminals were read/write-oriented, not ioctl-oriented, and the concept of escapes originates with the terminal vendors, not with Unix.

Regarding command-line parsing, there are ways to move to a Unix-style argument array in a way that is backwards-compatible. It could just be an attribute of the executable to exec(), that it wants a proper argument vector. Shell escaping in Windows is just not-sane.

Re: Inside the Windows Console

#193

Post by cryptonector »

JdeBP wrote: post #114
gmueckl wrote: post #21

Earlier quoted context omitted.

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

Linux terminal emulators are by no means uniform about this. Scrolling speed, and whether to not re-render for every character, are points of contention amongst the XTerm, Alacritty, and VTE people.

I just set the scrollback history to zero and run tmux. Scrollback speed problem solved.

Re: Inside the Windows Console

#194

Post by cryptonector »

megaman22 wrote: post #119
komali2 wrote: post #34

Earlier quoted context omitted.

Are you able to speak at all to the labor assignment? Microsoft is big, why only put 3 engineers on this project?

Three is probably a good number, if they are decent engineers. Throwing more people at a problem has diminishing results very, very quickly in software, unless the project can be broken down into mostly independent teams. Even then integrating the work into something coherent can easily be more challenging and time consuming than just having a tiny skilled team own the project soup to nuts.

The number of core developers will scale with how well they can separate concerns / components. Three is probably a good number of core developers for this project, but they could probably use a fourth to do things like write tests and do things like test interoperability/compatibility.

Re: Inside the Windows Console

#195

Post by vetinari »

AnIdiotOnTheNet wrote: post #188
vetinari wrote: post #177

Earlier quoted context omitted.

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.

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

The ABI is only part of backward compatibility. From another POV, you can run software designed for VT100 or other terminal in seventies on any Linux or Unix today, (though it may be recompiled. That legacy mentioned in previous post is that terminal is still considered serial device with specific protocol). There are companies, that do exactly that in production. You would be hard pressed to find DOS-era software that bangs on buffer starting at 0xB800:0000 that still works in 64-bit Windows.

Re: Inside the Windows Console

#196

Post by code_duck »

royjacobs wrote: post #159
code_duck wrote: post #134

Earlier quoted context omitted.

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.

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

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?

Re: Inside the Windows Console

#197

Post by cryptonector »

zadjii wrote: post #183
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…

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. This is a very big deal.

Now, not everything is really a file on Unix. There are ioctls for some things -- lots even. And the limited and non-standardized representation of processes as files is obnoxious, but whatever, it works.

The Windows model of console as ioctl-/API-based is simply an utter disaster of calamitous proportions. It's the reason Unix users/devs hate the Windows experience, and it has held Windows back in some ways. The success of Windows as a whole has papered this over, and it's probably the reason that the console got no love from MSFT for thirty years, but the problems are real.

Another thing that is shockingly bad on Windows is the C run-time. The lack of a single C run-time DLL, the fact that the C run-time is statically linked into every DLL, and the total lack of love that MSFT has shown the C run-time, is atrocious. Doing portable code development, where by portable one means "runs on various Unix and Unix-like OSes _and_ Windows", is rather hard, and the hard part is always Windows. Invariably this involves writing C code with lots of #ifdef WIN32 spaghetti. The only good thing about this is that it has forced some memory management discipline on library APIs that might otherwise not have happened.

If there is any chance that you could get MSFT to fund a similar project for revamping the C run-time, that would be fantastic. Because there are so many discrete portions of the C run-time to fix up, such a project could probably scale to more than three developers -- perhaps three core developers, two developers to improve a variety of individual and peripheral functions, and two test engineers. Please mate.

Re: Inside the Windows Console

#198

Post by gmueckl »

zadjii wrote: post #173
slededit wrote: post #41

Earlier quoted context omitted.

He can't say it publicly but the code behind the console is crap. Not just from a modern perspective looking back, the original devs hated it too. The book Show Stopper! Has some colorful words about it. And since it's so core to the system and deeply intertwined you can't just go in and start arbitrarily changing things. Everyone has been too scared to touch it for the last 20 years. This is painstaking careful work…

Oh no, I can say that quite publicly. When I started on the team in 2015, that code was some nightmarish shit. It was hardly componentized, you'd have 70 different places in the code all calling out to GDI to do rendering at seemingly random points in the app's lifecycle. It was painful to get work done in the codebase. After a LOT of refactoring it's finally in a state that's really quite managable, and much more mo…

Ouch. This sounds terrible. I can see how refactoring a bowl of spaghetti like that took a lot of time. I respect you for sticking with it and not throwing in the towel.

Re: Inside the Windows Console

#199

Post by thomastjeffery »

zadjii wrote: post #8
thomastjeffery wrote: post #2

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

That's just flat out wrong: https://i.imgur.com/ae1yyXI.png We added support for TTF fonts a few releases ago.

All I know is that the last time I installed Windows 10, I still had to edit the registry for it to find DejaVu Sans Mono.

If that has changed recently, that's fantastic!

Re: Inside the Windows Console

#200

Post by 1996 »

duncanawoods wrote: post #165
neilsimp1 wrote: post #149

Earlier quoted context omitted.

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…

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!!
Post reply on HN