Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the Windows Subsystem for Linux Redirects Syscalls

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

31–40 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#31

Post by zxcvcxz »

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.

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.

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.

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?

I went ahead and made the switch to Linux since I was trying to make Windows behave just like Linux.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#32

Post by ygjb-dupe »

_khhm wrote: post #29
Maarten88 wrote: post #27

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…

They've said the initial intent is for developers to use it, not for running servers / etc (which is why they only target Windows 10 client and not Windows Server OSs).

There is "running servers" in production and there is "running servers" in dev.

If I can't run the entire stack I use for dev under the subsystem then I will go the other route, which is to continue using VMs. I am excited about the initial release, and the prospect of being able to use Windows for all of the regular things I do, but it's clear that this isn't ready for primetime even as a dev tool.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#33

Post by besselheim »

coverband wrote: post #18

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] [1] http://www.pcworld.com/article/3038652/windows/microsoft-kil... [2] https://developer.microsoft.com/en-us/windows/bridges/ios Edit: Now I am puzzled as to why this got downvoted?

If you disassemble lxcore.sys you can still see hints of the Android subsystem project that it grew from: the \Device\adss and /dev/adss devices, the application name Microsoft.Windows.Subsystem.Adss, various function names containing "Adss", and some other textual references to Android.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#34

Post by zxcvcxz »

jjtheblunt wrote: post #26
l3m0ndr0p wrote: post #9

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. 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.

What makes you believe it's outdated?

Can you show me the source so I can check?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#35

Post by pcwalton »

zxcvcxz wrote: post #31

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. I wish Windows/MS would abandon NT and just create a Linux distro.…

> 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.

I do. The NT kernel is pretty clean and well architected. (Yes, there are mistakes and cruft in it, but Unix has that in spades.) It's not "jamming multiple systems together"; an explicit design goal of the NT kernel was to support multiple userland APIs in a unified manner. Darwin is a much better example of a messy kernel, with Mach and FreeBSD mashed together in a way that neither was designed for.

It's the Win32 API that is the real mess. Having a better officially supported API to talk to the NT kernel can only be a good thing, from my point of view.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#36

Post by [deleted] »

zxcvcxz wrote: post #31

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. I wish Windows/MS would abandon NT and just create a Linux distro.…

[deleted]

Re: How the Windows Subsystem for Linux Redirects Syscalls

#38

Post by ataylor284_ »

> The real NtQueryDirectoryFile API takes 11 parameters

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.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#39

Post by xorblurb »

luchs wrote: post #14

>As of this article, lxss.sys has ~235 of the Linux syscalls implemented with varying level of support. Is there a list of these syscalls somewhere? It would be cool to check it against the recent Linux API compatibility paper [0, 1]. [0]: http://oscar.cs.stonybrook.edu/api-compat-study/ [1]: http://www.oscar.cs.stonybrook.edu/papers/files/syspop16.pdf

A list of (at least partly) supported syscalls is here: https://msdn.microsoft.com/en-us/commandline/wsl/release_not...

Not details on which one are fully or partly supported, though.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#40

Post by wtallis »

jdmichal wrote: post #22
l3m0ndr0p wrote: post #16

Earlier quoted context omitted.

Here are some, or maybe this is not part of the NT Kernel... 1. The use of drive letters A-Z for file system access. 2. Creating symbolic links to files and folders, like you can in Unix/Linux. You have to set a setting somewhere to enable this, but there's a security risk. 3. Standard functional/usable non-gui terminal application like Unix/Linux ssh. PowerShell doesn't come close. 4. Ability to SUDO or su Admin lik…

1. The use of a multi-root hierarchy vs. a single root hierarchy is pretty arbitrary. Drive letters in turn are just an arbitrary way to define the multi-root hierarchy. 2. `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required. 3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks. 4. This…

> 3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks.

Powershell is an acceptable scripting language. It's a horrible interactive shell. They shoudn't have made "shell" part of its name if they weren't going to at least include basic interactive features like readline compatibility and usable tab completion.

Post reply on HN