I’d just like to interject for moment. What you’re refering to as Ubuntu, is in fact, Ubuntu/Windows, or as I’ve recently taken to calling it, Ubuntu plus Windows. Ubuntu is not an operating system unto itself, but rather another free component of a fully functioning Windows system made useful by the NT kernel, system libraries and vital system components comprising a full OS as defined by Microsoft.
Many computer users run a modified version of the Windows system every day, without realizing it. Through a peculiar turn of events, the version of Windows which is widely used today is often called Ubuntu, and many of its users are not aware that it is basically the Windows system, developed by Microsoft.
To join the Church of Notepad, you need only pronounce the Confession of the Faith:
There is no system but Ubuntu, and Windows is one of its kernels.
Using Word is not a sin, it is merely a penance.
Which E are we on now?
Cautiously excited about this! Having a Linux and/or POSIX API as a first-class citizen on NT has always been something I’ve wished for, and that it’s apparently ABI compatible with the Linux kernel is particularly excellent. The original design of NT was always meant to accommodate multiple distinct “environments”, but with the exception of Win32, they’ve always seemed to be second-class citizens. For a while there was OS/2 support, but only for OS/2 1.0 CLI applications, then there was the POSIX API, but while SFU/SUA had potential, it never seemed to get serious attention from Microsoft outside of being a fairly minimal environment with a very ancient toolchain for porting enterprise UNIX applications to Windows.
I’m optimistic that with the signs of a changing culture at Microsoft this incarnation might succeed where the others failed.
This reminds me of an old (and basically defunct) project called coLinux (specifically, it’s andLinux variant). I really liked it when it was around, left me with a nice system for games, and all the linux I needed for programming. Good to see something like it coming around again.
Apple had to do something similar to port OS9 applications to OSX (both having a completely different architecture and, I think, binary format).
It reminds me of MachTen, of which I was an enthusiastic proponent, back when MacOS didn’t mean NextStep.
I remember MachTen! I really wanted to try it out, but could never convince my dad to pony up for it…
Instead, when I went off to college, he let me take an old Sun 3/60 with me (along with my mac), which was at the time simultaneously cooler and less useful than MachTen would’ve been.
Did you use MachTen for work?
Yeah, although more for Emacs and telnet (!) than anything else. On my big old Powermac 8600.
The three options I see are 1. Enhanced Cygwin-like API (it’s still win32, and as such, needs recompile) 2. Linux subsystem for NT (should be transparent - FreeBSD takes this approach) 3. Invisible Ubuntu VM running inside of Hyper-V (apparently discounted)
http://blog.dustinkirkland.com/2016/03/ubuntu-on-windows.html has some more insights, confirming zaphar’s reply
It’s essentially Wine in reverse. All the linux syscalls have been ported and native ubuntu apps run unmodified. So it’s pretty much 2.
Can’t wait for someone to install Wine on Ubuntu on Windows 10, and then Cygwin on Wine. And since it seems possible to do this the other way round, we could finally run Cygwin on Wine on Cygwin on Wine on Ubuntu on Windows. (Bonus point for doing this on Windows on a Mac.)
It’s essentially Wine in reverse.
This makes it sound hacky ;). Windows NT has/had support for multiple what they call ‘personalities’. As far as I understand, from the perspective of the NT kernel Win32 is just another personality. There used to be OS/2 and POSIX personalities as well.
I guess that the new Linux support is implemented as an NT personality.
Does anyone know how they handle fork()? One of the problems for Cygwin was that fork() couldn’t be neatly mapped to a Win32 call, so they basically had to implement non-COW fork(), which is less efficient:
NT itself has had a native COW fork() implementation going back a long time, but it’s not exposed via the Win32 API. You can reach it directly via the Native API NtCreateProcess function (exposed in ntdll.dll) with the right parameters. The problem here though is by going through the Native API there’s a large chunk of process initialisation that is implemented in Win32 that won’t be performed. As I understand it, this makes any such process created by such a method effectively “incompatible” with other Win32 processes on the system. You can find some interesting discussion on this here.
So to circle back to your question, if they’re implementing it via a separate environment subsystem, which it appears they are, they can presumably just use the native NT fork() support, but then there’s a greater question of compatibility with Win32 processes and how NT “Linux” processes can communicate with Win32 processes (and vice versa). Alternatively, I guess they could expose the fork() call via Win32, but this would imply they’re using Win32 processes as well…
I really need to load up the Windows 10 preview with this so I can actually get some concrete answers!
EDIT: One interesting addendum is that per this Ars Technica article there’s definitely several new kernel components involved, in the form of at least two drivers: lxcore.sys and lxss.sys. So there’s clearly more going on than just a separate Linux environment that’s implemented on top of the existing Native API exposed in ntdll.dll. What exactly those provide I’m not sure, but it’s worth noting as best I can remember Interix/SFU/SUA never required any kernel support as they just implemented a separate subsystem on top of what was already exposed in the Native API.
If they want to handle Linux system calls in unmodified binaries, there will definitely have to be at least a small kernel component. Linux binaries make use of the syscall instruction on amd64 and the int 0x80 instruction on i386. If nothing else, they will need to trap those instructions separately from whatever regular Windows processes are doing.
ss stands for “subsystem” in NT component names (e.g. lsass.exe for the Local Security Authority, or csrss.exe for the Client Server Runtime, aka Win32 subsystem support) so lxss.sys would not be an unexpected name for the Linux subsystem kernel component.
Is there a way to flag stories for merging? I think x5qtoh and rskjh4 ought to be merged to this one as well.