Ubuntu on Windows

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

Windows NT was designed with multiple "personality" subsystems right from the start. The filesystem that any given "personality" sees is not the underlying system that is seen via the "Native API". They are all reinterpreted views of the NT Object Manager's namespace.

* The Win32 subsystem presents a view where C:\ in a Win32 name is mapped to \DosDevices\C:\ in a Native NT name.

* The POSIX subsystem (at least in the later SFU/SFUA) presents a view where /dev/fs/c/ in a POSIX name is mapped to \DosDevices\C:\ in a Native NT name.

* This Linux subsystem (reportedly) presents a view where /mnt/c/ in a Linux name is mapped to \DosDevices\C:\ in a Native NT name.

\DosDevices\C: is, in turn, a Object Manager symbolic link that points to somewhere else in the Object Manager namespace. (There's also a whole mechanism of "per-login" and "global" symbolic links that I'm glossing over.)

Win32 names relative to \ , D:., and . , and POSIX names relative to \ and . , are also things that are handled within the subsystem (sometimes within a set of conspirator language runtime libraries, in fact) that are mapped by that to the NT Object Manager's namespace.

* The Win32 subsystem itself only supports one current directory, the current directory on the current drive. The Win32 subsystem keeps a handle to that current directory open per Win32 process (and stores the handle value in the Process Environment Block in the process' address space) and remembers what string, including drive letter, it was set to.

* The current directory on another drive is a fiction maintained by conspiring Win32 language runtime libraries, using a set of otherwise hidden environment variables. A Win32 name with D:. is mapped using the value of an "=D:" environment variable. See http://unix.stackexchange.com/a/251215/5132 for how this can make a mess with the (Win32) Bourne Again shell running on Cygwin.

* Win32 names relative to a driveless \ use a Win32-subsystem-maintained idea of a current drive letter, derived from the Win32 "current directory" string that is set, and then go through the mapping to \DosDevices\C:\ (or whatever drive letter).

* The (SFU/SFUA) POSIX subsystem doesn't need such conspiracy, as the POSIX model is to have only one current directory, too. So the POSIX subsystem keeps a handle to the current directory open per POSIX process.

* This Linux subsystem (reportedly) presents a view where / in a Linux name is mapped to \DosDevices\C:\Users\Kirkland\AppData\Local\Lxss\rootfs\ in a Native NT name.

* Presumably, this Linux subsystem similarly keeps a handle to the current directory open per Linux process, and remembers its string. After all, it has to present /proc/self/cwd to Linux programs.

Every Windows NT subsystem has filename mapping mechanisms, and they all present their own "views" of the actual native namespace of the NT operating system kernel. This is not a new filesystem. It's another NT subsystem with its own view of the NT Object Manager's namespace, just as the other subsystems have.

This has been up since the turn of the century:

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/ca...

The demonstrators in the Microsoft video do warn that they will be avoiding some of the holes of the system in their demonstration. One is very briefly visible at 08'13", before the demonstrator rapidly clears the screen (again), when they run apt-get to install git:

  E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such file or directory)

The old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) has pseudo-terminals with both BSD and System 5 access semantics, in comparison.

* https://technet.microsoft.com/en-gb/library/bb497016.aspx

* https://technet.microsoft.com/en-gb/library/bb463219.aspx

Moreover, a Windows console window that is the controlling TTY of a POSIX program in that subsystem has the POSIX cooked input mode with local echo, and generates escape sequences for extended keys.

* https://news.ycombinator.com/item?id=11391961

* https://blogs.windows.com/buildingapps/2016/03/30/run-bash-o...

I strongly suspect that you will never see systemd working on the Windows NT kernel. Getting systemd to work doesn't just involve supporting the Linux kernel system calls, but also involves getting what those system calls do to work as well. It's all very well supporting open(2), but if one cannot open (say) /proc/self/mountinfo or all of the stuff under /sys or many other things (some listed at http://0pointer.de/blog/projects/the-biggest-myths.html), then systemd might load but it won't run and work.

The same goes for upstart. For example: upstart uses pseudo-terminals for logging. The Windows NT Linux subsystem, according to the Microsoft demo video, doesn't implement pseudo-terminals and returns ENOENT when a program attempts to obtain one.

* http://upstart.ubuntu.com/cookbook/#console

* https://news.ycombinator.com/item?id=11415843

Then there's the fact that the Windows NT Linux subsystem doesn't run Linux programs as the first process in the entire system. That honour goes, of course, to Windows NT's own Session Manager. Both systemd and upstart have "Am I process #1?" checks, and operate in a non-system mode if they aren't process #1.

Which brings us on to the fact that Windows NT already has a mechanism for launching daemons. It already has a Service Control Manager that supervises daemons and that talks LPC to control utilities. It already has a Session Manager that handles initialization, shutdown, and sessions. Ironically, it has had some of the things that are "new" in systemd for roughly a quarter of a century. (But some of those "new" things aren't even new in the Linux and Unix worlds, really.)

It's worth observing that the approach taken by the old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one) is to run daemons under Windows NT's own Service Control Manager. There is a small shim (psxrun.exe) for ensuring that the Service Manager could run and control the POSIX program, doco on what environment a POSIX program should expect when run under the Service Manager, and an Interix version of the service(1) command that understands Windows NT service management and how to speak to it.

* https://technet.microsoft.com/en-us/library/bb463219.aspx#EH...

* http://systemmanager.ru/svcsunix.en/extfile/portapps/service...

It would be interesting to see how some of the daemontools family of service management toolsets -- such as nosh, runit, perp, daemontools-encore, and s6 -- fared on the Windows NT Linux subsystem. I suspect that one would trip over unexpected holes in the Windows NT Linux subsystem (like setuidgid not working because the underlying system calls return EPERM, perhaps). But I also suspect for several reasons that quite a lot would work. The daemontools family uses FIFOs and ordinary files as the control/status API; is composable and loosely coupled and so doesn't lock everything in to Linux-specific stuff (like specific files in /proc, /dev, or /sys) even if one tool in a toolset might need such stuff and permits that one tool to be replaced or otherwise worked around; and can do service management without demanding to be process #1.

So one could spin up svscan, or service-manager, or perpd, or runsvdir; stub out or comment out invocations of setuidgid or runuid with a dummy program if the Windows NT Linux subsystem didn't support that; similarly stub out or comment out invocations of jexec (for nosh service bundles that use BSD jails) and whatever of ionice, chrt, and numactl (for nosh service bundles that use those) don't work; and probably get quite far.

But the big deal would be spinning service management up outwith a Windows NT login session, so that daemons are actually daemonized. The old Windows NT POSIX subsystem actually has an init process (and an inetd) that can spin up other stuff. I strongly doubt, given the very clearly stated aims, that the new Windows NT Linux subsystem has (or will have) anything similar.