>
It behooves one not to make egregious mistakes when talking about the mistakesAdmittedly it's been a little while since I last played around with custom shells and terminals on Windows and I had also rushed my post so you're right that some details were wrong but you're just as far off with your corrections as the points you were criticising so you're really not in a position to be making platitudes about egregious mistakes.
I didn't say cmd.exe was a terminal emulator, I said it was multiple layers including the terminal emulator but not exclusively the terminal. Ok, techically it's conhost.exe that provide the terminal emulation, I'd lazilly lumped that together with cmd.exe because cmd.exe depends on conhost.exe when not run headless. The former requires the latter so you can't just drop cmd.exe into another terminal emulator and run it (other people have tried and there's extensive blog posts about the hacks they've had to do to get it to work, like running conhost.exe off screen).
If you want to be 100% technically accurate then cmd.exe is actually not like any of those things we've described. It's certainly not equivalent to Korn or other language REPLs as you stated. In fact the "language" part of cmd.exe is barely a macro language (again, due to it's DOS heritage). Plus shells orchestrate with byte streams where as NT's streams work very differently and cmd.exe doesn't even behave correctly when used as a CLI tool (which I'll get into below).
You're right that cmd.exe itself doesn't make DOS syscalls, as said aboveI was rushing my post which caused me to conflating two points. What I really meant to say was:
1. cmd.exe builtins read from the NT console API's stdin. Which means you cannot fork out to cmd.exe as a CLI command because any prompts ("Are you sure you wish to delete" type things) just whiz straight past without pausing for input. This was highly annoying when I was developing my alternative Windows shell and wanted to make use of rm, copy, etc rather than having to write those commands all over again.
2. Windows, and cmd.exe by extension, supports running other console applications which don't use NT's console streams because they favour some of the other hacks used in the DOS days. This means those applications also don't work with alternative shells let alone alternative terminal emulators.
Also I think it's disingenuous citing your own blog post as a source. I could link you to the Github repository where I've had to put in numerous workarounds for the shell I've written to work with Windows. But instead I'll link to something a little more recognised:
https://devblogs.microsoft.com/commandline/windows-command-l...
(I did have a hunt around for the blog posts from other developers building console solutions for Windows and the similar problems they've ran into but since it was around 5 years ago when I gave up first party Windows support, those blogs are now lost in the mists of the ether).