I find it amazing that you can have such a functional Ubuntu environment by translating system calls. Microsoft does have the advantage of Linux being open-source I suppose, while the Wine project had to reverse engineer DLLs. Or have you supply them on your own.
Its ironic (old)microsoft exerted so much effort to put the personalities in place (OS/2, posix etc), then (mid)microsoft systematically destroyed that work under Balmer, and now (new)microsoft are reimplementing the same thing under a (seemingly) completely different system.
More correctly would be to say that Microsoft has advantage of user space libraries used in GNU/Linux distributions being open-source. Linux kernel itself being GPL2 is probably a problem for Microsoft's developers because of possibility to be accidentally exposed to it while researching documentation.
I didn't see any information about whether they do it using direct system call translation, or if they do it using shared library inter-positioning. In either case, its pretty cool!
FreeBSD has been able to do this (with some limitations!) for years:
While it seems like it is worth Microsoft's time to keep people on Windows.
I for one look forward to having all my vulnerabilities in one place... Linux, windows, server, desktop...
Here's the famous Linus Tech Tips 7-in-1 video: https://www.youtube.com/watch?v=LXOaCkbt4lI
The reason WINE went with the library emulation route is because: (a) the Windows kernel doesn't have a stable system call layer, and (b) the Win32 API is massive anyway.
Windows has an easier time emulating Linux at the very lowest levels because Linux has an ABI stable system call layer. If you emulate those, you can run ANY Linux binary.
It also means Microsoft doesn't have to ship or support hundreds of Open Source projects. They ship the syscall layer, and distributions ship the user layer.
Crossover is probably the best you'll get: https://www.codeweavers.com/products/crossover-linux
Otherwise, if you only need Windows to game, I'd highly suggested PCI Passthrough so that you can use your GPU in a Windows VM: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...
Also, you can share directories between the native filesystem and the VM quite easily. And if you're using something like VirtualBox or VMWare there are "unity" windowing modes available.
I was interested in that too, since I write Unix utilities and it is sometimes useful to have them work on Windows as well. I've done that (checked that it worked on Windows) with a few utilities in the past (written in C), that did not use any very Unix specific features that were not present on Windows. And remember reading around that time that Windows (I think it was from NT onwards) had a POSIX subsystem.
Then more recently, as in, a few months ago, I wanted to check that out again, and did. IIRC I read (maybe on a Wikipedia page) that the POSIX subsystem is not present in Windows any more.
And you can also buy $5 USB sound card and have no issues at all. Or spend few bucks more and connect PCI sound card.
This is common in reverse engineering stuff.
It's a Linux syscall translator for Windows. It works well enough to run a Debian userland, although it's got so many holes and rough edges that I would never, ever, ever suggest using it for anything other than a stunt.
It uses Interix to do most of the heavy lifting, so all LBW does is to translate from Linux syscalls to Interix syscalls; so we get a Unix filesystem and user permissions and sockets and fork etc for free. (Interix was great. I'm glad they're bringing it back from the dead.) Unfortunately not all the system calls directly map onto each other; so Interix has a native fork(), but Linux emulates with clone(). I couldn't make threads work.
A few of the biggest problems were:
- the Windows page size is 64kB; the Linux page size is 4kB. The ld.so loader will try to map two bits of executable within the same 64kB boundary, and, of course, this doesn't work on Windows. I crudely hack around it by allocating pages of RAM and copying things. Write-back mapping only works at all if the application lets mmap() pick the address.
- very very very different register usage. glibc on Linux uses gs as a 'pointer' to the current thread's private data area, via a special syscall. Windows resets gs to 0 on every interrupt! I crudely hack around this by intercepting null pointer dereferences, looking at the instruction to see if it was gs, and then reloading it with the right value.
- even then, that syscall sets gs to point at a GTD segment with a size of 2^32; this wraps round the entire address space, which allows very large offsets in gs to be treated as negative numbers. Windows doesn't let you create GTD segments. It only allows LTD segments, and it caps the segment limit to the end of the user address space, so this trick won't work. I crudely hack around this by intercepting segmentation violations, looking at the instruction to see it it's a [gs+negative number] dereference, and then binary patching the executable to use a different instruction.
- glibc is horrible and undocumented. There's a big pile of key-value strings pushed onto the stack above the environment when the process is initialised, containing various magic numbers. ld.so will just crash if you get this wrong. I spent a lot of time reverse engineering the ld.so source code to figure out what these were and how to set them up.
It was all vile and horrible, but it worked surprisingly well (i.e., it worked, which was surprising).
Using the NT kernel's personality system to implement Linux syscalls natively is totally the right thing to do; that's obviously what they're doing here.
I would love to know about the internal Microsoft politics which made releasing this possible. I wonder how long it's been brewing? I did LBW in about a month of evenings; the core logic wasn't hard. I wouldn't be at all surprised if this hasn't been floating about inside Microsoft for years.
"Windows NT was designed from the start to have modular subsystems. It was most infamously used to provide a POSIX subsystem which really only checked boxes on government acquisition forms. :-)"
1) Linux has won the server (web) market. Developers would like to use a Unix box to work on their server code so they typically move to OS X. This could prevent that switch because they can still use Windows to developer their Linux server software.
2) Many projects start out as Linux and stay Linux and are only ported after much time and effort to Windows. Enterprises when faced with a tool that they want to use will also look to switch off Windows. Now rather than the cost of switching they only have to pay to upgrade their windows boxes to use the tool.
3) There is now a major incentive for developers to only build Linux binaries because it will work more places. This might cause a faster drain of developers as they eventually remove all windows specific code and can more easily migrate elsewhere. This feels eerily similar to the OS2 story and no doubt in the next week I expect to see more than a few articles discussing this very thing.
4) It will be much easier for Microsoft to bring much loved Linux tools to Windows so you can expect to see a more rapid increase of tools announced that now work for Windows.
Are there any Windows only server applications that would be useful in a non windows shop? I'm not trying to be snarky, I really can't think of any.
I would expect the most likely users to convert would be those using job specific desktop software.
I tried them – they don’t work at all in KDE.
Arch linux host, KDE as DE, Windows 10 Guest, just leads to a big black box in unified mode, and windows don’t properly occur in the KDE taskbar.
What I expect is integration equal to WINE – automatically putting stored data into the correct folders, easily accessible and mounted, integrating windows with the taskbar, etc.
And yes, this is "just for games" – but try gaming on a multiscreen setup when the game doesn’t show up in your taskbar and you can’t minimize it.
With WINE, everything works fine – but not with UPlay.
So I can run the game, via UPlay in the VM (but not unified mode), or I can pirate it and run it in WINE.
But unified mode, or paid in WINE, doesn’t work.
Apple needs to do a utility that supports this as smoothly as Bootcamp supports multiple boot.
Although, as others have already pointed out, it differs in some very significant ways.
OS/2 2.x providing Win16 binary compatibility was an after-market system providing binary compatibility with applications made for the operating system that shipped "out of the box". Whereas this is the operating system that ships "out of the box" providing binary compatibility with applications made for an after-market operating system.
(Yes, yes. One could buy OS/2 pre-installed, and one can buy Ubuntu Linux pre-installed. The scale of that, in both cases, is nowhere near significant enough to change the basic fact that overall the two situations are the reverse of each other.)
Also: There was not the extent of existing tools available natively on both platforms, in the OS/2 case. The examples being waved around in the news now are things like Apache, Ruby, Node, and so forth. There wasn't the OS/2-and-Win16 analogue of (say) the Ruby developers deciding in the months to come that a Win32 port is too hard to maintain, and dropping it in favour of just running the Linux Ruby on the Windows NT Linux subsystem. Today's analogue of the OS/2 case would be a universe where there was no Win32 Ruby at all, and the Ruby developers deciding not to start making a Win32 version because the Linux one "is good enough for the few Windows users".
I suspect that drawing parallels based upon what happened with OS/2 2.x and Win16 is a mistake, and those thinking that this will mean an outflux of Windows development "because it happened with OS/2 2.x" (which was more like an influx of development that failed to happen) are indulging in wishful thinking.
There's also the minor matter that, during the OS/2 2.x and Win16 time, there was this little thing called Windows NT lying around, promising a route for OS/2 1.x, where the existing tools were, with its OS/2 subsystem. (It is ironic that we are once again looking at a Windows NT subsystem.) That has no equivalent this time around at all; unless one mis-casts UbuntuBSD (https://news.ycombinator.com/item?id=11326457) in that rôle. It doesn't really fit, though. "Look, all you people with Ubuntu Linux application softwares. Forget that minority Windows thing that you ported to a couple of years ago. Come bring your applications to this new FreeBSD instead." (-:
* https://news.ycombinator.com/item?id=11391841
... would you agree with a call for it to be?