5 ms·

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

by zadjii 8y ago

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 designed and it's incompatible with *nix terminals, so instead of us trying to force our shitty API on them, we'll just adopt theirs. I certainly care about developers. I know everyone on my team does. I know that there's not a tom of goodwill between Microsoft and external developers, but there are a lot of people at Microsoft who are working really hard to try and fix that.

cryptonector 8y ago
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.
- dblohm7 8y ago
  Look up the "universal CRT". It's already happening.
- zadjii 8y ago
  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

by zadjii 8y ago

cryptonector 8y ago

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.

dblohm7 8y ago
Look up the "universal CRT". It's already happening.
zadjii 8y ago
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