231–240 of 259 posts
This a very candid and informative look at the Windows console and it comes from Microsoft! I'm impressed. Congrats to the writer and thanks for posting!
Thanks for your kind words. Glad you liked it - check our blog often - LOTS more posts coming on this subject!
Oops! That page can’t be found. It looks like nothing was found at this location. Maybe try a search? Is this just me? Late to the party? In case this isn't temporary: https://web.archive.org/web/20180717165103/https://blogs.msd...
Ugh!
Should be back up and available now!
Found the article content quite interesting but the tone of the writing (emojis and exclamation marks everywhere) really put me off. Sounded forced and added nothing.
Hope you find the latest updated version more palatable.
Earlier quoted context omitted.
I want to work with more people like Rich! Whatever they may lack in English convention, they more than make up for it in enthusiasm!
lol Rich is straight outta Britain English - his English is the most English of any of ours :P edit: Now that I say that, I guess he is Welsh so maybe his english isn't the best... :P
Thanks all - appreciate that some of my enthusiasm came through, though the previous poster had a point about the sheer density of my excitement so I toned it down a little while making a few corrections, clarifications, and improvements in the update I posted this afternoon.
Keep the feedback coming though - you'll also find me on Twitter a lot more than in here: https://twitter.com/richturn_ms
I love Cmder, it's superior to cmd.exe in all possible ways, but from time to time it just stops working. Now I understand better why.
Cmd.exe is a (headless) command-line shell.
A shell accepts input from a terminal/Console and emits text to its connected terminal/Console to be displayed back to the user.
All this is covered in some detail in the posts thus far.
Earlier quoted context omitted.
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.
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!
Earlier quoted context omitted.
As I understand it Windows 3 ran in DOS, Windows 98 had DOS integrated, Windows NT had it emulated and ME was somewhere in between. It wouldn't surprise me if parts from all four have survived til today for compatibility.
ME wasn't between the least. It was DOS based. There is no inbetween. It's either IO.SYS or NTOSKRNL.EXE. It made using the real mode MS DOS even worse by shipping a special MS DOS which skipped CONFIG.SYS and AUTOEXEC.BAT, hidden the files and removed DOS from the boot menu. To fix this, check http://retrosystemsrevival.blogspot.com/2018/06/dos-for-wind... this -- quite new blog post, just last month, for something…
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.
Earlier quoted context omitted.
Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…
I don't use Windows mostly because the console experience is so bad. I'm sure there are many others like me. Your superiors should realize they have lost generations of developers because of this and dedicate the resources needed to fix it. How they haven't realized this yet, astounds me.
Earlier quoted context omitted.
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!
Alas, as one of our dev's says often "Fonts are just files containing collections of lies"!
Some fonts claim to only contain monospace, glyphs, but don't and include non-monospace or irregularly sized chars. Others just lie completely.
But if you have well-formed TTF fonts, that express correct metdata, and ARE monospace, then they should be selectable.