
Inside the Windows Console - pmarin
https://blogs.msdn.microsoft.com/commandline/2018/07/10/windows-command-line-inside-the-windows-console/
======
m_st
I tried using PowerShell or Hyper. But these are just so slow to start. So I'm
always coming back to cmd.exe. It is fast and serves my basic needs just
perfect.

When I need more, I just type 'bash'. And bash also starts faster than
PowerShell or Hyper.

So I don't see why they now change WIN+X and Explorer to use PowerShell rather
than cmd.exe.

Keep improving cmd.exe. But please don't make it bloated.

~~~
bitcrazed
Hi there! Author of the post that's the subject of this thread here :)

Two questions:

1\. Does your machine use a spinning disk for its system drive, or SSD? If the
former, that's slowing you down more any anything else. STRONGLY recommend
moving to SSD system drive if so. 2\. Have you tried `powershell /noprofile`
from Run dialog or Cmd? If you're still seeing PowerShell take > 600ms to load
and start, likely something else is up.

If you're expecting PowerShell to load faster than ~600ms, your expectations
are likely a little out of whack - Cmd loads so fast because it's tiny and -
relatively speaking - as dumb as a stump. PowerShell is a .NET language, and
so loads the CLR, so incurs some overhead vs. Cmd, but it does A TON more
that'll save you more time and effort over-all than any amount of time saving
vs. starting Cmd.

HTH.

~~~
romwell
Well, re:

>1\. Does your machine use a spinning disk for its system drive, or SSD?

This really _shouldn 't_ be a question regarding the performance of a
_terminal window_.

If _cmd.exe_ starts fast regardless, then so should Powershell if it is going
to replace it.

And on that note, on a new laptop with an SSD I can see a difference between
Powershell and cmd.exe execution-to-prompt-ready time (however small that
latency is).

As long as that's the case, Powershell simply isn't a viable replacement for
cmd.exe

~~~
bitcrazed
I am not comparing performance of a terminal window - Cmd and PowerShell both
run connected to the same terminal app - Windows Console (conhost.exe) as
discussed ad nauseum in the posts that are the subject of this thread.

But you're comparing a 30+ year old command-line shell that was built in 1989
to primarily provide compatibility with MS-DOS, with a modern object-based
shell that runs atop the .NET CLR and provides VASTLY more power and
capability than the MUCH older, simpler, shell that it supersedes.

It's like comparing startup perf of Notepad and VSCode … and saying that you
won't use VSCode until it starts up as quickly as Notepad, even if VSCode
saves you HOURS more per day/week than using Notepad would.

~~~
romwell
Sure, sure, more functionality.

That's not an excuse for the startup time of a shell not being _instantaneous_
on a modern system.

To harness the power, I write Powershell _scripts_ (yay no more batch files),
but it's just too annoying to experience the startup lag to use the shell for
the simplest tasks (e.g. simply running a console application).

That shouldn't be the case.

PS: "modern object-oriented" was all the hype in the 80-s. It's not an excuse
for a performance hit today :)

~~~
bitcrazed
You mention Hyper. Are you running PowerShell connected to Hyper or Console?

If you're running Hyper, note that this alone takes 6s to (warm) start Cmd on
my 16GB RAM Core-i7 Surface Pro 4.

PowerShell takes ~1.2s to (warm) start connected to Console, while also
starting a half dozen modules and scripts in my PowerShell user profile.

PowerShell takes < .7s to start when run with `-NoProfile`

------
chungy
Technical errors regarding how UTF encodings work:

* UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before Unicode settled on U+10FFFF[1] being the maximal codepoint for backwards compatibility reasons with UCS-2...)

* It says UTF-16 extends UCS-2 (which is correct) by incorporating a 4-bit encoding... which probably was intended to be a "4-byte encoding" instead. The surrogate pairs reserve their first six bits for an additional 10 bits making up half of the codepoint being stored (whose value is later added to by 0x10000 to get the actual codepoint). Also, it provides 16 additional planes to the BMP. 17 total including the BMP.

[1] Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints
on every plane are reserved and declared as noncharacters. Few parsers are
really so strict.

~~~
jwilk
> Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints
> on every plane are reserved and declared as noncharacters. Few parsers are
> really so strict.

This is what Unicode 11.0, §2.4 says:

 _Noncharacter code points are reserved for internal use, such as for sentinel
values. They have well-formed representations in Unicode encoding forms and
survive conversions between encoding forms. This allows sentinel values to be
preserved internally across Unicode encoding forms, even though they are not
designed to be used in open interchange._

It would wrong for a general-purpose parser to reject these codepoints.

~~~
chungy
Hmm, alright. I have seen parsers reject them, presumably from misinterpreting
the standard.

Thanks for the correction :)

------
oldgradstudent
The article seems to ignore the other big problem with the Windows console. It
is painfully slow compare to Linux and Mac terminal programs. Especially when
scrolling large amounts of text.

~~~
GordonS
I regularly use both Windows and Linux, and I can't say that I've ever noticed
a performance problem?

~~~
ShinTakuya
The terminals you use in Linux must either be painfully slow or you must be
very insensitive to latency issues because the latency on Windows console is
really high. When I type something I expect it to appear immediately (<10ms),
not in 20-50ms. I'm just guessing the timings here though but the point is
that there's definitely a difference.

A lot of basic commands in general run more slowly on Windows but I don't
think that's the terminal's fault so much as it's lack of optimisation on the
command itself.

~~~
yoz-y
Afaik, 10ms is not achievable nowadays, unless you use a very old computer.
[https://danluu.com/input-lag/](https://danluu.com/input-lag/)

~~~
half-kh-hacker
> For desktop results, results are measured from when the key started moving
> until the screen finished updating

When the key _starts moving_ and when the key actually actuates are very
different times. Some of this latency could be key travel time. This is also a
methodical issue I found with his [keyboard latency
test]([https://danluu.com/keyboard-latency/](https://danluu.com/keyboard-
latency/)).

~~~
1996
Do you have any recommendation to get at least a decent latency (< 30 ms) on
linux or windows 10?

The least infuriating to me is lxterm. Consoles (no X) used to feel ok several
years ago, but now I use fbuffer it feels slower (and I can't do without
because high screen resolutions make fonts tiny, even with setfont)

------
deejbee
One thing I've always missed is tabbed consoles. I've use Cmder
([http://cmder.net/](http://cmder.net/) I have no affiliation) for quite a
while now and has been totally awesome as it provides a tabbed container
window with any mixture of cmd.exe, bash shell, launching as Admin and best of
all it persists all your windows after reboot.

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

~~~
duncanawoods
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 command
history between sessions. This would seem obvious thing but no.

~~~
1996
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!!

------
nailer
As a nix person who now spends his entire day in the Windows terminal, I wrote
a guide to setting up the console and pwsh for maximum productivity:

[https://github.com/mikemaccana/powershell-
profile/blob/maste...](https://github.com/mikemaccana/powershell-
profile/blob/master/README.md)

------
cryptonector
I really like the point that an API-centric console does not remote well
(think ssh).

In general I prefer the WIN32 object-handle model to the Unix file-descriptor
model, and I much prefer the WIN32 security descriptor and access token model
to the Unix haphazard security model, but very clearly, the everything-is-a-
file model is superior at least for remote access: it's easier to design and
implement protocols for that since the protocols don't need to know anything
about the remote resources' nature. Thus the Windows console cannot be
exported via SSH, not without writing a layer that converts text reads/writes
into ioctls, because it's not remotely file-like. That the Windows team had to
and did write that layer really is fantastic news.

------
OliverJones
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 differences between git bash (mingw) and cmd on Windows.

Inbuilt OS stuff should be as simple as possible. It doesn't have to be
precisely /dev/tty - like, but it should be simple. Partly to avoid bloat, and
partly because it's much less flexible than userland stuff.

Even when RAM was worth twice its weight in gold, various UNIX shells weren't
heavy. Now? not worth worrying about.

I admit I came up as a UNIX user so I favor sh-like history. But still,
Windows terminal history just isn't as good. (I wish it didn't deduplicate
repeated commands and lose them when they're edited.)

~~~
laumars
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 only work on local host is just _inexcusable_. And I don't say this
because "hindsight is 20/20", there was already decades of proven example that
remote consoles are worth having before the console API was even written. Why
they couldn't have created is a network API (ala rsh) is beyond me. But we are
where we are.

Some of the examples given about OOP was just plain wrong too. You can't bunch
20 years of object oriented langaues together and say "they all quickly
followed". 20 years is not quick; not in real terms and most definitely not in
IT terms.

What surprised me the most when reading that article is that NT was originally
command line driven with a GUI added for release. It's amazing just how bad
the console sucks even without taking the evolution of NT into account; and
now that I know NT was originally command line oriented, well I'm just
shocked.

If there was anything good that can be taken from the article, it's that it
sounds like they are working on better terminal / shell separation which will
enable developers to write better terminal emulators and better alternative
shells. Plus potentially allow for a networked shell. My next request after
that would be to write a unified way of splitting ARGS because their current
method of passing all command line parameters as a single string is just
terrible (yes, I get that's DOS legacy and impossible to change due to
backwards compatibility, but isn't it about time Windows had a standard API
for splitting that ARGS string so, going forward, programs can be written to
split parameters in a consistent way meaning command line users know exactly
when they can and cannot use quotation marks, spaces and escaped characters,
etc.

~~~
bitcrazed
Hey Laumars - Console PM and author of the post here:

Fair points in part, though …

Remember that things like Remote Desktop obviated the pressing need for
command-line --> remote command-line access for many years. RDP quickly
evolved into a very efficient way of remoting the entire desktop experience,
not just Command-Line - something that was particularly necessary until
PowerShell started to mature due to Windows' heavy GUI tool influence (for
better and worse).

Don't despair though - there's a VERY interesting post coming soon on this
subject, that I think you'll enjoy! ;)

I summarized 20 years of history: Simula arrived in '68, Smalltalk in '72 and
then, other than research efforts, relatively little until CFront/C++ around
'85\. After that there was a new variant of C++ or new object oriented
language almost every 8-12 months ever since - ObjectBASIC, Modula-2,
ObjectPascal, Delphi, Java, Python, C#, Ruby, etc. It was practically a
language explosion.

And, of course NT started as a command-line OS. All new OS' start that way
it's the simplest UX to get running. The Windows GUI wasn't slapped on at the
end though - it arrived relatively quickly since Microsoft was able to
leverage much of the experience of having build Windows 3.x/9x etc.
previously.

Command-line args are not all passed as a single string. In Windows, args are
separated by space. If you use C/C++ and others, you get argv and argc, or in
C# you get an array of space separated values.

Alas, when NT came along it was seen as EXTREMELY important to make it easy to
run/port MS-DOS scripts and tools to encourage migration and adoption. By this
time, so many tools used so many ways of specifying args and values … / vs. \
vs. - vs. none, /o=foo, /o foo, etc. … that it was practically impossible to
both support backward compat while rationalizing usage.

PowerShell, though, has done much to make args MUCH more consistent, self-
documenting, etc.

This said, yes, it'd be AWESOME if args could be rationalized and handled in a
more consistent manner. Had a fascinating discussion about just this the other
day. Stay tuned to our blog ;)

~~~
laumars
Hi, thank you for taking the time to respond.

Re the command line arguments being a single string, this is what I'm
referring to:

> For better or for worse1, Windows knows about only one command line string
> for each process. Because one string is not terribly useful, libraries
> conspire to provide the illusion of multiple command line arguments: before
> creating a subprocess, a program combines all argument strings into one
> command line string, and the newly-born subprocess, before calling main,
> splits this string into arguments and passes the arguments as argv. In
> principle, each program can parse the command line string differently, but
> most use the convetion that CommandLineToArgvW and the Microsoft C library
> understand. This convention is a good one because it provides a way to
> encode any command line argument as part of a command line string without
> losing information.

> The problem is that there is no ArgvToCommandLineW. How do we construct an
> argument string understood by CommandLineToArgvW?

Source
[https://blogs.msdn.microsoft.com/twistylittlepassagesallalik...](https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-
quotes-command-line-arguments-the-wrong-way/)

Having one command line string is passable if you only handle ASCII characters
and consider whitespace a delimiter (as was the case in the days of DOS). But
the moment you start needing to pass more complex data (as you often need to
when you start writing shell scripts) then you quickly run into pain points.

Another drawback of a single string is you then limit the usefulness of
writing alternative languages which are heavily exec orientated (shell
languages). This is a particular pain point I've experienced with my own
custom shell because I apply escaping rules to quotes and allow for other
methods of quotations (such as proper support for nested quotes). However
since Linux / UNIX treat all parameters as an array at all points in the stack
it means I can consistently parse my own languages syntax and reliably pass
that to the program I'm wishing to call. It means I can drop a variable as a
parameter without having to manually escape / quote it for fear of whitespaces
breaking the syntax (ie using variables like you would in "normal" language).
But that simply does not translate well to Windows.

And finally there is also the painpoint that not all Windows CLI tools read
from ARGV. Some don't even decode the single string parameter correctly.
Theres better articles demonstrating this point so I won't waste more page
space on this issue but suffice to say its a bit of a mess.

Re OOP explosion: I get the point you're making but all language paradigms
have experienced a similar explosion in That time frame. Be it functional,
logical, object oriented, etc. I get the need to emphasize the logic of
Windows as an object oriented OS (a point I don't disagree with myself) but I
just feel your example was a little overreacting - to the extent that you
started undermining the crux of the point you were attempting to make.

Much like how your points about UNIX "everything is a file" was somewhat
mislead. That didn't really become a thing until much later in UNIX's history
(Plan 9 - UNIXs successor - really pioneered that concept and many ideas were
then backported. Eg The /proc example you used isnt even available on UNIX as
it's Linux specific. Plus your example was really more a reporting tool than a
demonstration of file system objects. Theres better examples of your point in
/proc such as the PIDs and their runtime parameters, and kernel setting that
can be read and written to as a filesystem objects).

Re GUI Vs console. My point was really more about how if Microsoft were
dependant on the console anyway to have made it their first GUI application
then it's a great pity they did such a bodge job of it. I get that RDP was a
necessity anyway - and it's fair to say the performance of RDP is really quite
impressive - but back in the 90s I seem to recall most Windows shops still
used to just throw a physical keyboard and mouse into their racks (usually via
KVM) rather than deal with RDP. Where as "Unix" (BSD, Solaris, whatever) would
be wired up via serial on the machines console port for remote access. So for
the best will in the world, remote access still wasn't a popular choice on NT
until it's relatively recent history where as it was the main way of
interacting with UNIX-like systems from the get go. And that is my problem
with how NT was designed. I can take or leave the whole GUI Vs command line
debate - that's purely personal opinion. My issue was until network speeds etc
all really caught up, Windows made it painful to work remotely. To an extent
it still does as you have to wait for the damned RDP service to come up after
a reboot (which would take half an hour _after the reboot had finished_ on one
Windows domain controller I used to manage) where as on Solaris / BSD / Linux
/ etc I can stream it's boot process from the moment the boot menu loads (in
fact I've even installed Linux remotely via serial). Obviously we all now have
OOB management tools like ilo or their respective cloud management tools so
the shortcomings of the RDP service are somewhat mitigated there these days
but how many years of NTs history has it taken us to get to that point where a
_ _server_ _ no longer needs a physical monitor, keyboard and mouse wired up
to it?

All in all it was an interesting read, even if I didn't agree with some of the
specific points you were making. But then life would be dull if we all agreed
on everything all of the time. :)

------
tofflos
I love reading about the work that's being put into old apps like Console and
Notepad. Keep it up!

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

~~~
sevensor
This is of a piece with Microsoft's GitHub acquisition -- seems to be part of
a program to win developer mindshare. And it's working; I was impressed by
this post, both tone and technical content. Windows having never really been
suitable for the server, and rapidly losing its grip on the home user, it
seems totally sensible to push the "windows is a good platform for people
doing serious work" angle. It's all Windows has left.

------
iforgotpassword
_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...](https://web.archive.org/web/20180717165103/https://blogs.msdn.microsoft.com/commandline/2018/07/10/windows-
command-line-inside-the-windows-console/)

~~~
bitcrazed
LOL - nothing nefarious - made a few corrections and improvements to the post
- aaaaand managed to bork the publishing process which took a few mins to re-
generate and refresh the cache!

Ugh!

Should be back up and available now!

------
angelsl
I'm not sure why the author is so excited! But it makes the article a bit
difficult to read!

~~~
zadjii
That's Rich for you - He's pretty passionate about everything we do :)

~~~
Stratoscope
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!

~~~
zadjii
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

~~~
bitcrazed
I'd swear at you in Welsh but I fear I may wear-out my 'l', 'e', and 'u' keys
;)

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](https://twitter.com/richturn_ms)

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

~~~
bitcrazed
Fair comment - I agree and so removed a bunch of !'s and emoji for you, though
I did leave a few in to convey some of my (and the team's) excitement - we're
genuinely buzzed to be able to massively improve the Console.

Hope you find the latest updated version more palatable.

------
zaat
I'm late to the party, but maybe the console guys are still lurking. If so,
than first and foremost I wanted to thank you for the amazing walk you guys
took the console so far.

That said, as someone who uses your product for hours on daily basis, I have
two pain points that I would love to have fixed, if that possible at all:

1\. selection of text and deletion - works in PowerShell, doesn't work in cmd.
Is this curable?

2\. Customizing the console is pain. I don't mind doing it once but it is
impossible to save theme and copy it between computers. It is also impossible
to export registry keys - not only do they differ for various consoles, the
color settings are not saved there. The only way I found so far for achieving
this is copying the shortcut for the specific console - the colors are saved
to the .lnk file in _binary_ form. Seriously, can we have at least color
exportable themes in a format that can be edited with a text editor?

~~~
zadjii
I think rich (@bitcrazed) already talked a bit about #1, so I'll share a bit
on #2.

I agree, the current properties story is INSANE. I don't get how whoever wrote
it even came up with it - it's likely a frankencode system that we're stuck
supporting for now. I can't tell you how many times I've had to explain how
the console settings work, and how your settings can be different depending on
how you launch the console. It's been a pain point I've had a particular eye
on since I started here.

It's a powerful system that is very prone to "you moved my cheese" syndrome -
It's REALLY hard to change it into a sane system without breaking someone's
workflow.

That being said, I have a bone to pick with that system, and I think I might
have some spare cycles to finally get to it soon :)

PS: While we're on the subject of colors, lemme quick throw out
(Colortool)[[https://github.com/Microsoft/console/tree/master/tools/Color...](https://github.com/Microsoft/console/tree/master/tools/ColorTool)].
It can be really helpful for quickly changing the color scheme of the console.
It's not great for everything, but I've found it super helpful.

~~~
zaat
That's look promising. Thank you very much!

------
logcat
There are ways to get much better terminal experience for typical web dev
[https://blog.ropnop.com/configuring-a-pretty-and-usable-
term...](https://blog.ropnop.com/configuring-a-pretty-and-usable-terminal-
emulator-for-wsl/) (also works for tilix)

------
xvilka
Hopefully, support for bidirectional text will be added soon. Microsoft needs
to lead the way of handling it in console programs. Even in UNIX systems, only
a few terminal emulators support bidirectional text properly.

~~~
zadjii
Could you go submit this to our UserVoice?

[https://wpdev.uservoice.com/forums/266908-command-prompt-
con...](https://wpdev.uservoice.com/forums/266908-command-prompt-console-
windows-subsystem-for-l?category_id=87960)

I'd say that bi-directional text is a pretty low priority at the moment. We
just haven't really heard any asks for it, and like you said it's poorly
supported on other platforms (if at all).

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

~~~
bitcrazed
G'ah - PLEASE read the posts about which you're commenting - Cmder is a
terminal/Console, not a shell.

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.

~~~
dvfjsdhgfv
That's quite clear, I have no idea why people assume I confuse the two. I just
said the article helped me to understand why Cmder has certain problems.

------
tempodox
So, MS has finally realized they're 40 years behind the civilized world. I'm
curious to see how long it will take them to catch up.

~~~
gaius
_So, MS has finally realized they 're 40 years behind the civilized world_

Yes they should be emulating a teletype like enlightened folk!

~~~
ziotom78
Very appropriate comment. Last year I was tinkering with the implementation of
a TUI (Text User Interface), and I wanted it to be cross-platform. I started
developing it under Windows, using the Console API (sorely lacking in
features, but at least it is just an API to be called from C). I had to
abandon the project once I realized that it would have been too hard to
harmonize this approach with the weird way you are supposed to program a Unix
console.

Let's consider the difference between calling an hypotetical system API to
change the text color and a raw sequence of bytes encoding. In Unix, to set
the color to be used for writing characters you have to send an ESC character,
some more bytes, and then an ASCII representation of the R, G, and B
components (assuming your virtual terminal supports this), separated by a
colon/semicolon. The terminal will then read this sequence, parse the three
numbers and move the character. This approach is not precisely efficient,
especially if you consider that today it is not unlikely to have full-screen
terminal applications with a large resolution. For a 200x60 terminal like the
one I am using right now, to color every character with a different color
requires sending 500 Kb of data, compared to the 36 Kb required by a 3-byte
representation of each RGB tuples.

And if you are trying to _read_ from a terminal, every time you receive an ESC
key, you are always in doubt whether the user pressed ESC, or if it is the
start of an ANSI sequence. The usual trick here is to check if there is a
character already available immediately after you detect an ESC byte coming
from standard input: if there is, you can assume it's the beginning of a
sequence.

Admittedly the virtual-terminal approach makes remote connections (through
SSH) simpler than an API (you just have to send a bunch of bytes through a
socket), but I wonder why in 2018 we are still relying on the old and quirky
mechanism of "virtual consoles" when real consoles have long disappeared.

Edit: small fixes.

~~~
whatshisface
SSH connections are nearly the most common interface. At the very least,
optimizing for them is a good idea.

------
gmueckl
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?

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

~~~
gmueckl
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 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?

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

~~~
chx
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...](http://retrosystemsrevival.blogspot.com/2018/06/dos-for-windows-
me.html) this -- quite new blog post, just last month, for something this old.

~~~
bitcrazed
Actually, no - Windows ME did not depend on MS-DOS.

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.

~~~
chx
Erm, nope. IFSMGR.VXD depends on IFSHLP.SYS still.

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.

~~~
bitcrazed
IFSHLP.SYS was originally created during the implementation of OS/2 1.2, and
later released in Windows 3.11 running on 32-bit 386 Enhanced Mode.

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

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

~~~
flabbergast
Yeah, this 30 years old code-base.. besides it is questionable only dev's
below 30yr old are working on it (age discrimination, or accidental?), hardly
anything changed. If I want to copy something I still have to do the ancient
mark and copy sequence from the right click menu! What are they working on
then? Still fixing bugs?

~~~
zadjii
Have you tried enabling QuickEdit mode in the Properties (right click on the
titlebar)? Quick edit lets you use the mouse for selecting, and in Insider's
releases we've even added support for Ctrl+Shift+C/V for copy paste (even in
wsl!).

We've been working on not only tons of bugs, but adding plenty of new
features, including support for VT sequences, 256/RGB color, improving our
unicode support, enhanced accessibility support.

The fact that all of our devs are under 30 is merely coincidence :)

~~~
Scramblejams
I just started turning Quick Edit off because I understood it was responsible
for that strange bug where the console sometimes gets stuck until you press
return. :-( Is that one on the to do list?

~~~
tom_
That’s how selection has always worked. It halts console output until you’re
done selecting.

~~~
Scramblejams
It's overeager, then. It's pausing the console even when no selection is made.
Maybe I'm clicking in the window accidentally, but I'm not selecting anything.
I certainly don’t have the problem on Linux.

------
megaman22
Yikes, the anti-Windows crowd is strident today. Yeah, cmd.exe is crap, and if
you're expecting to use a Unix workflow rather than learn how things work in
Windows, you're going to have a bad time. I'm not sure that religiously
sticking to the baggage and constraints of obsolete hardware from fifty years
ago is really a great ideal either...

But you just can't change existing shit willynilly in Windows, with the kind
of install base and legacy it has, or you'll break things in a way that has
been historically unacceptable in Redmond.

~~~
vetinari
> I'm not sure that religiously sticking to the baggage and constraints of
> obsolete hardware

> But you just can't change existing shit willynilly in Windows, with the kind
> of install base and legacy it has,

You do see the irony, right?

~~~
tom_
I think his (?) point is that if you don't have the backwards-compatibility
goals of Windows, you can afford to be - and perhaps should be - a lot more
adventurous. Which is something POSIX systems have summarily failed to be in
this respect, for all that they've managed to polish that turd to an
acceptable shine.

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

~~~
AnIdiotOnTheNet
> 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 different distributions without
recompilation.

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

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

True, though 32-bit editions of Windows still include NTVDM which runs Win16
apps!

Microsoft is pretty fanatical about backward compatibility.

Why? It's the #1 reason most enterprises and many users continue to pay to
install/upgrade to Windows.

Breaking backward compatibility with existing executables (not source-code) is
a violation of the trust that we've earned with customers for the last 40
years or so.

Of course, some products/features/etc. are discontinued on newer OS', etc. but
the core essential platforms are rarely discontinued.

True fact: Windows still runs VB6 apps - millions of them. EVERY DAY!

------
slinzer
Too many exclamation marks.

~~~
bitcrazed
Fixed! Let me know if you prefer the updated version I posted this afternoon.

Thanks for the feedback :)

------
7kmph
Who cares anyway

~~~
lagadu
Well, you cared enough to post. Now imagine all the people who actually enjoy
reading insights about developing software that we've all used.

------
zerr
> The Windows Console code-base is currently (July 2018) almost 30 years old
> ... older, in fact, than the developers who now work on it!

It smells like ageism... Did you lay off the original "old" devs?

EDIT: :)

~~~
zadjii
Lol any original devs retired a long time ago, can you imagine what $MSFT
shares from 1989 are worth now?

~~~
sun41
What the heck is this related to shares? You mean to suggest all original devs
are millionaire, and that being a millionaire means you don't code anymore?
And you, poor guy, missed out?

~~~
erikbye
Early MSFT employees were compensated heavily with stock options. I think it's
also pretty safe to say that few devs from that period are still coders,
they've moved on to other roles or retired.

From Show Stopper!:

Technical preferences aside, the success of Windows was a windfall for Cutler
and colleagues. Most had received sizable stock option grants on joining
Microsoft, partly to compensate for their reduced wages. At other companies
such stock grants might return 10 to 25 percent profit to a grateful employee
over five to ten years. A doubling of value would be a bonanza. But lately
Microsoft's stock had soared-with no limit in sight. Demand for Windows
transformed Microsoft from the leader of the software pack into a giant
looming over the rest of the industry. The company's net profits were
especially impressive; an astonishing 25 percent of sales flowed to the bottom
line. Options granted to Cutler two years earlier, while substantial at the
time, were now breathtaking. And the stock price seemed a cinch to double over
the next few years, given the company's bullish outlook.

Even at the current stock price, Cutler's options now were worth at least
several million dollars. Havens and Perazzoli, meanwhile, were assured of
clearing high six figures. Even the team's rookie programmer, hired fresh from
Princeton the summer before, would reap a few hundred thousand dollars within
three years.

------
gigatexal
They should just replace it with the power shell prompt that wraps the command
line.

~~~
gigatexal
Too many fans of the command line from the 90s. Oh well.

------
frankohn
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 remotely \- the shell and the terminal are not
clearly separated: the OS will open automatically a console for some kind of
executables / cannot attach a shell to an arbitrary console

It seems to me that it shows a few things.

First, unix design was better as it was more flexible and lasted over time and
computers evolution. Windows' design was sort of wrong since the beginning but
they didn't change anything and developers were left to use one of their
horrible APIs. This is similar to the difference between X Window and Win32
GUI API.

Second, MS does not care about developers except for the user of their
flagship product Visual Studio. They put 30 years of developer effort solely
on Visual Studio and nothing else. Compare with Apple, they at least cared of
implementing an excellent terminal and contributed greatly to the wonderful
LLVM compiler infrastructure.

So, okay some improvements might lands on Windows 10 at some moment but I
personally don't care. At work we still use Win 7 and I think we will keep
using it for a long time. The Windows Console is just horrible to use and
propram for and a testament to the MS awful software and APIs that developers
are forced to use because of Windows dominance.

~~~
oblio
X Window has a good design? Only because it allowed competing tool kits on top
of it ("Provide mechanism rather than policy. In particular, place user
interface policy in the clients' hands.")

Besides the fact that the X libs are almost universally reviled and nobody
used them as soon as they could (Motif, Qt, Gtk, etc.). The core concept, that
of network part is actively being abandoned right now, see the Wayland
efforts.

X Window won because its competitors were proprietary, basically. And then it
dragged on because every application was compatible with it.

Win32 is also horrible, but you can kind of get why it was that way: the
hardware was abysmal when it was conceived and backwards compatibility was
super, super important in the early and cutthroat desktop market.

~~~
frankohn
> X Window has a good design? Only because it allowed competing tool kits on
> top of it ("Provide mechanism rather than policy. In particular, place user
> interface policy in the clients' hands.")

Yes only this simple thing made a much better design. It can be used to
provide a modern and beautiful desktop environment even 35 years after its
creation.

> Besides the fact that the X libs are almost universally reviled and nobody
> used them as soon as they could (Motif, Qt, Gtk, etc.).

You are not supposed to use Xlibs directly to program user interface. They
just provide the primitive APIs to create windows, process events and draw on
the screen. It is normal to use a toolkit like Qt that use Xlib as a backend.

I agree that programming Xlib directly is not very sexy but it sort of make
sense and is yet better than Win32 programming.

> The core concept, that of network part is actively being abandoned right
> now, see the Wayland efforts.

The fact that this is a good choice is still to be demonstrated.

> Win32 is also horrible, but you can kind of get why it was that way: the
> hardware was abysmal when it was conceived and backwards compatibility was
> super, super important in the early and cutthroat desktop market.

Yes, you can excuse them for creating Win32 at the time but they have no
excuse for not providing qnything better after 30 years. Oh yes, you can
create beautiful UI if you only use Visual Studio, you get use to all the
warts and limitations, if you forget cross-platform, it will works only on
windows, if you use visual studio installer and ship all the zillions of DLLs
that you may need with the most baroque distribution system.

On windows I am still looking for a decent way of programming UIs without
embracing all the MS bullshit.

~~~
pjmlp
Even when compared against Amiga toolkits and Win16, Xlib with Athena or Motif
were anything but pleasant.

X Windows is the main reason of "The Year of Desktop Linux" failure.

It is quite telling that ChromeOS and Android have ditched it.

Also the only UNIX that was actually a pleasure to code for was NeXTSTEP,
guess what, it also didn't care for X Windows other than compatibility
purposes.

~~~
msla
> X Windows

... doesn't exist, of course.

~~~
pjmlp
Funny guy, everyone understood that I meant _The X Window System™_.

~~~
msla
Well, it goes to demonstrating expertise, doesn't it?

Hard to know something if you don't know what it's called, innit?

~~~
oblio
That’s ridiculous. The full name is super cumbersome and not really intuitive.
Most people just call it X...

~~~
msla
> The full name is super cumbersome and not really intuitive.

... how is X more cumbersome than "X Windows"?

> Most people just call it X

Right. Because that's its name.

