7 ms·

"Linux geeks can think of it sort of the inverse of "wine" -- Ubuntu binaries running natively in Windows. Microsoft calls it their "Windows Subsystem for Linu

• grandalf 11y ago
  Indeed. Perhaps it will increasingly make sense to design software for Linux and then run it on windows via this method. Over time the Windows system calls that are not needed by the linux overlay can be phased out.
• UK-AL 11y ago
  Windows NT had a POSIX subsystem awhile ago, not sure what happened to it. The NT Kernel was designed to have different personalities like Win32, OS/2, POSIX, etc It could be an updated version.
  • tonymillion 11y ago
    I came here to make the same comment. 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.
    • akiselev 11y ago
      To be fair, this new implementation is very completely different. If we had the same kind of experience with virtualization and hardware with VT-i/x/d or AMD-V when Microsoft was developing personalities, the chips would have landed very differently.
  • vram22 11y ago
    >Windows NT had a POSIX subsystem awhile ago, not sure what happened to it. 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.
  • mpweiher 11y ago
    From elsewhere in this thread: "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. :-)" https://news.ycombinator.com/item?id=11391290 https://news.ycombinator.com/item?id=11391290
    • JdeBP 11y ago
      That makes it seem that the POSIX subsystem only ever did that, which is not true at all. A better explanation is at https://news.ycombinator.com/item?id=11392369 https://news.ycombinator.com/item?id=11392369 , which gives a version number and a time frame for context. The POSIX subsystem was different in later years.
• dec0dedab0de 11y ago
  I would rather have the opposite. I would even pay for an official "Windows on Linux". There is a handful of games I would like to play, but other than that I have no interest in windows.
  • xienze 11y ago
    Totally doable. Use KVM to virtualize Windows and (the important part) make sure your CPU and motherboard support VT-d. Then you can pass a graphics card (separate from the one you run Linux with, naturally) to the VM and get >95% of native performance. There's lots of videos of folks doing this.
    • plexicle 11y ago
      Hi. Do you mind linking one? Thanks. :)
      • xienze 11y ago
        Sure. Here's a guide: https://www.youtube.com/watch?v=w-hOr44oBAI https://www.youtube.com/watch?v=w-hOr44oBAI Here's the famous Linus Tech Tips 7-in-1 video: https://www.youtube.com/watch?v=LXOaCkbt4lI https://www.youtube.com/watch?v=LXOaCkbt4lI
    • wernercd 11y ago
      That's still "VM" not "Native". You aren't running them "side by side"... you are running them "One inside the other". Not exactly an apple-to-apple comparison.
      • xienze 11y ago
        The performance hit is so negligible on modern hardware that the distinction doesn't really matter.
        • geofft 11y ago
• anonymfus 11y ago
  >Microsoft does have the advantage of Linux being open-source 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.
  • digi_owl 11y ago
    Thats why you do it clean room style. One team to document, one team to implement based on that document.
    • vram22 11y ago
      What does "clean room" style mean, exactly? I've heard the term, but only in connection with semiconductor factories, I think. You're talking about software here.
      • TillE 11y ago
        To avoid any hint of copyright infringement, a team reimplementing an API (or similar) must never have looked at the original code. https://en.wikipedia.org/wiki/Clean_room_design https://en.wikipedia.org/wiki/Clean_room_design
      • alcari 11y ago
        The usual term is "Chinese Wall" [1]. [1] https://en.wikipedia.org/wiki/Chinese_wall https://en.wikipedia.org/wiki/Chinese_wall
      • soapdog 11y ago
        means a group check the source and documents. Another group never sees the code, only the documentation, and proceed to implement whatever they need being able to say that they have not used the original code. This is common in reverse engineering stuff.
• drewg123 11y ago
  *BSD and Solaris have done have run linux binaries for years. Doing it on Windows is a bit more impressive, but given that there is a POSIX subsystem, its not all that surprising. 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!
• twic 11y ago
  > I find it amazing that you can have such a functional Ubuntu environment by translating system calls FreeBSD has been able to do this (with some limitations!) for years: https://www.freebsd.org/doc/handbook/linuxemu.html https://www.freebsd.org/doc/handbook/linuxemu.html
• jdub 11y ago
  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. :-) 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.
  • cpach 11y ago
    ”It was most infamously used to provide a POSIX subsystem which really only checked boxes on government acquisition forms.” Ah, so that was the rationale. I always found that subsystem curious.
  • philjohn 11y ago
    IIRC, this is how the Linux binary compat on BSD works.
  • makomk 11y ago
    Also (c) Windows isn't open source so there are licensing issues with Wine shipping actual Windows DLLs. Some of them do work under Wine but the project aims to replace as many of them as possible with emulated versions.
  • JdeBP 11y ago
    This makes it seem that the POSIX subsystem only ever did that, which is not true at all. A better statement is at https://news.ycombinator.com/item?id=11392369 https://news.ycombinator.com/item?id=11392369 .
• david-given 11y ago
  So, uh. I did this! Crudely. In 2010. http://cowlark.com/lbw/ http://cowlark.com/lbw/ 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.
• icefox 11y ago
  Some long term thoughts: 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.
  • JdeBP 11y ago
    > 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. 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 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." (-: