So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?
Not only that, but since the team was founded we discovered that conhost was not the only console implementation in Windows, though it's the only one available on Desktop. There was a pretty massive undertaking to unify all the separate console implementations on different SKUs under one application, so that all of them would be improved at the same time. It didn't have a terrible lot of impact on the everyday developer, but it was important to help internal engineering efforts.
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 curious about one other thing: the Windows Console is notorious for having extremely bad perfomance when displaying lots of text. Last time I checked I could only get around 100 lines of text per second on Windows while Linux terminal emulations can show more than 10 times that amount. This may seem petty, but some programs are slowed down by this in practice. Can we expect improvements in that area as well?
For all the bad rap it got (some of which was deserved), ME bypassed real-mode MS-DOS (and its config files) at bootup, and loaded its own protected-mode drivers, etc. in IO.SYS. It also loaded the main registry hive only once, and parallelized PnP resolution, significantly improving boot-up time. It also incorporated Windows 2000's networking stack, and added support for UPnP.
In many ways, ME was a stepping stone, getting some users on less-capable hardware onto Windows 2000 class OS features, without requiring a complete hardware upgrade.
Everyone's favorite error message: the Microsoft Installable File System Manager cannot find the helper driver. Please ensure that IFSHLP.SYS has been installed.
This means Windows ME needs a real mode DOS helper for certain file system operations.
I can't remember whether the INT 21h function 55h (Create PSP) was still called as frequently as in earlier Windows and handled in DOS but I betcha.
Its job was to provide 32-bit file access (bypassing 16-bit DOS file IO mechanisms), and ensuring nothing else on the system could intercept INT 21h calls.
ME didn't depend on MS-DOS (though it did provide support for running MS-DOS apps).
* https://superuser.com/a/319187/38062
* http://jdebp.info./FGA/a-command-interpreter-is-not-a-consol...
* http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
> 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?
It's not really something most developers outside the company would have even been aware of honestly. At different points in time, there have been various different teams across Microsoft who had been working on bringing up new pieces of hardware (Xbox, HoloLens, phones, etc) and they found that the existing console didn't work on those minimal Windows OS's. At the time, there was no Console team at all, so whoever was working on that device just implemented their own console that would work on that prototypical device. That prototypical console got re-used and extended for other devices as they were developed, then abandoned as the platforms matured.
Then, in 2014, when the Console team was formed, we found out that not only were we responsible for the desktop console, but these other implementations as well.
> Can we expect improvements in that area as well?
Stay tuned :)
You simply can not attract developers to your platform without a first rate console experience.
Why even bother with Powershell, Linux Subsystem etc without getting this crucial component working perfectly ?
Are you not even slightly aware of the bias and bubble you live in?!
* I'm kidding, but talk to your average IT department head about Linux desktops :)
Not to mention that in the enterprise world Java and .net have an overwhelming market share.
[0] https://insights.stackoverflow.com/survey/2018/#development-...
Apparently the roles were reversed in 2017, when Windows was a platform for 41% and Linux 32.9%: https://insights.stackoverflow.com/survey/2017#technology-pl...
Of course that could all be biased by the demographic composition of StackOverflow users, but it still seems to indicate that Windows is losing importance.
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. I don't think throwing more people at it would really help too much.
My hat is off to you and your team for finally fixing this.
After a LOT of refactoring it's finally in a state that's really quite managable, and much more modernized.
What stands as a HUGE testament to the Console team's effort, however, is the fact that, while re-engineering what was truly a nightmare code-base, apart from a few newly-introduced bugs (most of which were caught before release), the rapidly improving Console didn't break any any existing command-line apps or users' workflows.
The engineering team deserve a medal for pulling this off, quite frankly!
The Windows console really is rubbish, even after all these updates; don't bother with it.
In the same way that the Linux desktop has fast caught up with the Windows desktop, the Windows terminal is fast catching up with the Linux terminal.
The stuff your changing most people will never notice, but you've done more for the console in 3 years than was done in the previous 20 as far as I can tell.
It's getting very close to where I can actually use Vim full time at a DOS prompt - it's actually waiting for Vim to catch up with the 24-bit colour changes that you made [0]. Plus there's the nicety of bold/italic fonts but I'd imagine that might not occur for a while.