Can't find any substantial writings on this, but it seems likely.
This will have been quite a bit more work than just a POSIX layer, IMO; POSIX defines a bunch of low-level functions that lie just under the C runtime library, but Linux defines a bunch more that expect a certain view of the world - things like clone(2), which lets you selectively choose what the forked process gets to inherit. POSIX only specifies fork(2). Linux implements fork(2) in terms of clone(2). And POSIX defines the API at the level of C; this will have had to implement the Linux ABI, where it differs from Win64. A minor detail of a bunch of assembly stubs, but work nonetheless.
In my experience the differing perception of pleasure, certainly with the Interix-derived Windows NT POSIX subsystem rather than the original one, is usually a result of the toolset being BSD rather than GNU. I don't have much trouble with the BSD toolset, myself, especially when switching between Windows and an actual BSD. (-:
In addition to the fact that a number of the "Does this new subsystem ...?" questions are answerable as "No; but the old POSIX subsystem did." (https://news.ycombinator.com/item?id=11416392) the POSIX subsystem has some stuff that we're simply not going to get with a Linux subsystem that has vanilla Linux binaries including libraries right down to the system call level. There are things that only come by adjusting libraries and binaries, because they are above the raw system call level. The POSIX subsystem integrates the user account database access library routines with the Windows SAM, for example. So "ls -l" shows the actual Windows usernames. The POSIX subsystem also comes with a "service" command that understands and can work with the SCM, for another example.
I'd like to see the POSIX subsystem reintroduced. It's a major reason not to use Windows 10.
SUA is based on an old version of BSD, not GNU. tcsh, csh and sh. The compiler works. There is an old version of lex. For some of the userland, Windows binaries are provided, such as vi. It's better than nothing.
Why did MS remove SUA from Windows 10? What harm would it do to remain an optional add-in as it was in Windows 7?
Why do users have to upgrade to Windows 10 to use Linux binaries? Seems like Microsoft will do _anything_ to get users to upgrade. What are the privacy implications of Windows 10? Microsoft is very untrustworthy.
Will users be able to run their own Linux binaries on Windows?
Windows has never been a "pleasant experience". It's the unpleasantness of it that makes the alternative, UNIX, so appealing.
... but is too outdated to be capable of bootstrapping clang. There's very probably a long chain of bootstraps that would achieve it, but there's not a direct route.
> Will users be able to run their own Linux binaries on Windows?
The answer to that is easily determined from the demo video that Microsoft published. In it, Russ Alexander compiles a program with (Ubuntu binary) GCC and and runs it.
Its implicit int in the declaration of main() was jarring. (-:
Well, it's not like Microsoft made much of an effort to remind people. It was discontinued as a separate project after about Windows XP. It continued to be part of Windows Server[1], but AFAIK, it was no longer present in the client versions.
[1] at least until 2008 or 2008 R2, I didn't check later versions.
Thanks for the info!
If they just implemented all Linux syscalls on top of NT, that would replace a Linux kernel. There would be no Linux kernel running on top. But in that case they would also need to emulate stuff like /proc. (This is the "reverse Wine" scenario.)
So I personally think it is either: - There is no new subsystem, this is just a linux.exe running the Linux kernel as a process, like CoLinux does or - There is a new subsystem. One way to do this is to port Linux to a new "architecture", namely the NT HAL. You'd call into the NT native API from the linux kernel, which would mean you'd have to put the headers with the native APIs you use under the GPL.
Armchair kernel development is fun :-)
$ grep DESC /etc/lsb-release
DISTRIB_DESCRIPTION="Ubuntu 14.04.3 LTS"
$ uname -a
Linux kappa 3.13.0 BrandZ virtual linux x86_64 x86_64 x86_64 GNU/Linux
$ wc -l /proc/cpuinfo
608 /proc/cpuinfo
$ /native/usr/bin/uname -a
SunOS kappa 5.11 joyent_20160204T173314Z i86pc i386 i86pcThey don't run the linux kernel at all. That /proc/cpuinfo is a part of a limited subset from what procfs usually offers. They enter their linux compatible "subsystem" via a bash binary, which could probably be any linux elf binary, since they run them unmodified. So, it looks like they actually implemented most of the syscalls with some of them emulating necessary parts of linux environment, like procfs.
[1] https://sec.ch9.ms/ch9/5db6/8ee786b7-9fc5-45bf-94d0-16ea9176...
It's a lot easier to emulate syscalls than it is to do something like CoLinux. Additionally, I can't imagine Microsoft would EVER let GPL'd Linux code into their kernel.
And this seems to be implemented as an NT subsystem, which makes tons of sense.