←back to thread

Ubuntu on Windows

(blog.dustinkirkland.com)
2049 points bpierre | 1 comments | | HN request time: 0.212s | source
Show context
stop1234 ◴[] No.11395293[source]
So wait... you still get the "cmd.exe console"? After all these decades Microsoft Windows still does not provide a decent terminal out of the box?
replies(1): >>11415517 #
1. JdeBP ◴[] No.11415517[source]
Of course, one could phrase the question the opposite way. Many people have, over the years.

> After all these decades, Unix and Linux people are still limited and encumbered by the antique typewriter-mode way of interacting with a computer?

This sword cuts both ways, remember. In many people's minds, the typewriter-oriented way of interacting with computers -- with all of its concomitant problems of multiple incompatible escape code sequence sets, control sequence tearing, terminal mode enquiry from the host end, modal character encodings, modal display, 8-bitness, 7-bitness (!), and of course all of the modem and serial line hoops to jump through -- is something that the world got away from in the 1980s and early 1990s.

The console subsystems in Windows NT, and in OS/2 1.x before it, provided simple manipulation of cursor and attributes without worrying about which escape sequence set to use or without danger of escape sequence tearing. They provided simple enquiry mechanisms for reading characters and attributes back out of the display, and for reading the cursor. There were no worries about "having bit #7 set", or accidentally dropping into "great runes mode". One could use full UCS-2 (this was pre-Unicode 1.1, remember) if one wanted to avoid worrying about code pages. The kernel didn't impose a fixed number of devices or (at least in Windows NT) a low limit on the total number of consoles. The input stream included both keyboard and mouse events in a single machine-readable form, and application softwares didn't have to decode human-readable (sic) protocols for the latter. Keyboard events comprised key press and release information. There were no worries about BPS settings and carrier detect.

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

All of these were 1980s advances on the state of the art with respect to typewriter-oriented interfaces, and from them in the same decade we got a whole range of TUI programs (even on MS/PC/DR-DOS) whose textual user interfaces did things like incorporate the mouse, draw UI widgets with actual box/line/arrow glyphs, react to modifier keys as they were pressed and released (the most memorable perhaps being a press and release of the [ALT] key activating the menu bar), and save and restore what was displayed "behind" a window/dialogue box. So one should understand the non-Unix non-Linux world's amazement at people who bemoan the lack of systems inferior to even that.

And after that in the 1980s, they will tell you, we gave you the ability to have graphics with the text, multiple fonts, more than 16 colours, a cross-application clipboard, a unified message queue, message passing between different programs, and so forth.

There's another "after all these decades" question that could be shot back, as well.

> After all these decades, it's only in 2011 that the Unix and Linux worlds finally got a workable mouse event protocol for their typewriter user interface? The OS/2 MOU subsystem could handle 16-bit row and column positions, without any of these problems and in the same recognition that consoles were no longer 80 by 25, in 1987!

* http://www.edm2.com/index.php/OS2_API:DataType:MOUEVENTINFO

* http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Ex...

* http://superuser.com/a/413835/38062

* https://groups.google.com/d/msg/vim_use/lo6PLRUu2Gg/MDcpLf1P...

* http://leonerds-code.blogspot.co.uk/2012/04/wide-mouse-suppo...

There is no "Microsoft cannot do a decent terminal (like we can)" high ground for you to claim.