> The real NtQueryDirectoryFile API takes 11 parameters<p>Curiosity got the best of me here: I had to look this up in the docs to see how a linux syscall that takes 3 parameters could possibly take 11 parameters. Spoiler alert: they are used for async callbacks, filtering by name, allowing only partial results, and the ability to progressively scan with repeated calls.
>As of this article, lxss.sys has ~235 of the Linux syscalls implemented with varying level of support.<p>Is there a list of these syscalls somewhere? It would be cool to check it against the recent Linux API compatibility paper [0, 1].<p>[0]: <a href="http://oscar.cs.stonybrook.edu/api-compat-study/" rel="nofollow">http://oscar.cs.stonybrook.edu/api-compat-study/</a>
[1]: <a href="http://www.oscar.cs.stonybrook.edu/papers/files/syspop16.pdf" rel="nofollow">http://www.oscar.cs.stonybrook.edu/papers/files/syspop16.pdf</a>
I have installed the current fast ring build and have tried installing several packages on Windows. Some do install and work (compilers, build environment, node, redis server), but packages that use more advanced socket options (such as Ethereum) or that configure a deamon (most databases), still end with an error. Compatibility is improving with every new build, and you can ditch/reset the whole Linux environment on Windows with a single command, which is nice for testing.
<i>Since NT syscalls follow the x64 calling convention, the kernel does not need to save off volatile registers since that was handled by the compiler emitting instructions before the syscall to save off any volatile registers that needed to be preserved.</i><p>Say what? The NT kernel doesn't restore caller-saved registers at syscall exit? This seems extraordinary, because unless it either restores them or zaps them then it will be in danger of leaking internal kernel values to userspace - and if it zaps them then it might as well save and restore them, so userspace won't need to.
I can't think of much that would benefit from this except for, perhaps, headless command line type applications. The one that comes to mind is rsync. Being able to compile the latest version/protocol of rsync on a Linux machine and then running the same binary on a Windows host would be nice but fun seems to end there plus with Cygwin, this is largely a no-brainer without M$ help.<p>What about applications that hook to X Windows or do things like opening the frame buffer device. I've got a messaging application that can be compiled for both Windows and Linux and depending on the OS, I compile a different transport layer. Under Linux heavy use of epoll is used which is very different than how NT handles Async I/O - especially with sockets. So my application's "transport driver" is either compiling an NT code base using WinSock & OVERLAPPED IO or a Linux code base using EPOLL and pthreads.<p>Over all it seems like a nice to have but I'm struggling to extract any real benefit.<p>Can anyone offer up some real good use cases I may be overlooking?
With this feature, if you're a Linux developer, you're automatically a Windows developer as well. Almost like being able to run all Android or iOS apps on Windows phones.[1][2]<p>[1] <a href="http://www.pcworld.com/article/3038652/windows/microsoft-kills-project-astoria-the-tool-designed-to-port-android-apps-to-windows-10.html" rel="nofollow">http://www.pcworld.com/article/3038652/windows/microsoft-kil...</a>
[2] <a href="https://developer.microsoft.com/en-us/windows/bridges/ios" rel="nofollow">https://developer.microsoft.com/en-us/windows/bridges/ios</a><p>Edit: Now I am puzzled as to why this got downvoted?
It's too bad that x86 hardware doesn't do virtualization as well as IBM hardware. You can't stack VMs. That's exactly what's needed here - a non-kernel VM that runs above NT but below the application.
> the Linux fork syscall has no <i>documented</i> equivalent for Windows<p>Emphasis is mine. I wonder if this is something that cygwin could (ab)use. Also I wonder why they would need this undocumented call.
Interesting, I wonder how much overhead is added to syscalls to look up the process type. Does NT still do this check when no WSL processes are running?
Next step is Microsoft basically needs to turn Windows into a flavour of Linux. If they don't, they're under massive pincer threat from Android and Chrome, which are rapidly becoming the consumer endpoints of the future. Windows is about to "do an IBM" and throw away a market that it created. See PS/2 and OS/2.<p>They should probably just buy Canonical. That would put the shivers into Google, properly.
I use to run Linux in a VM on windows and use Chocolatey for package management and cygwin and powershell etc, then I realized I was just trying to make Windows into Linux. Seems to be the way things are going and with the addition of the linux subsystem it kind of proves that Windows really isn't a good OS on it's own, especially not for developers.<p>I wish Windows/MS would abandon NT and just create a Linux distro. I don't know anyone who particularly likes NT and jamming multiple systems together seems like an awful idea.<p>Windows services and Linux services likely won't play nice together (think long file paths created by Linux services and other incompatibilities), for them to be 100% backward compatible they need to not only make Windows compatible with the things Linux outputs, but Linux compatible with the things windows services output, and to keep the Linux people from figuring out how to use Windows on Linux systems they'd need to make a lot of what they do closed source.<p>So I don't see a Linux+Windows setup being deployed for production. It's cool for developers, but even then you can't do much real world stuff that utilizes both windows and Linux. If you're only taking advantage of one system then whats the point of having two?<p>I went ahead and made the switch to Linux since I was trying to make Windows behave just like Linux.
Pretty neat stuff. I think that MS should just create their own Linux Distribution & port all MS products. Get rid of the Windows NT Kernel. I believe it's outdated & doesn't have the same update cycle that the Linux Kernel has.<p>Why run a Linux Application/binary on a windows server OS? When you can just run it on Linux OS and get better performance & stability.