How the Windows Subsystem for Linux Redirects Syscalls • Hacker News Board

Re: How the Windows Subsystem for Linux Redirects Syscalls

#71

Post by xorblurb » Wed, Jun 08, 2016, 9:34 PM UTC

bitwize wrote: post #47

deprave wrote: post #43

Earlier quoted context omitted.

A lot of Microsoft APIs and subsystems are similarly bloated. There are probably tons of factors at play, but I believe being closed-source and having to support many individual use cases is one fundamental reason. (See for example CreateProcess vs. fork...)

When it comes to system call interfaces, it's because Dave Cutler has forgotten more than many modern "kernel hackers" will ever know about how to design an OS.

Well, that's an (unbacked) opinion, and I don't share it. NT design is not too bad (obviously especially in contrast with Consumer Windows), and especially given what was achieved on the first few releases (that was made easier by Cutler serious experience in the area), but now it is far from brillant, and it has it (huge) share of problems every serious users of both Windows and Unix based OS knows.

Now at one point, way in the past, NT was far above Linux, and some Linux fanboys existed that did not even knew what they were talking about, yet had strong opinions of superiority about the kernel they used. Now we are ironically in the opposite situation: Linux has basically caught up on all the things that matters (preemptive kernel, stability, versatility, scalability) and then quickly overtook NT, yet some people like to talk endlessly about the supposed architectural superiority of NT, that did not provide anything concrete in the real world in the long term and widely used, and that MS had to work around and/or redo with an other approach (while keeping vestigial of all the old ones) to do all its modern stuff.

What kernel hackers know to do, is to detect problem in architecture that look neat on paper. Brillant ones are able to anticipate. I don't even have to: history has shown were NT has been hold back by its original design.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#72

Post by tptacek » Wed, Jun 08, 2016, 9:36 PM UTC

ataylor284_ wrote: post #38

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

Overloaded system call entrypoints are a fact of life on all mainstream platforms. Consider for instance "ioctl".

Re: How the Windows Subsystem for Linux Redirects Syscalls

#73

Post by tremon » Wed, Jun 08, 2016, 9:38 PM UTC

sz4kerto wrote: post #24

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…

None of these are kernel-related. You can create hard and soft links. PowerShell is great, just different. UAC is not sudo, but works very well. It's a different OS.

UAC is not sudo, but works very well.

For some values of well. If you logon interactively and start a powershell session, you do not have administrative powers and cannot get them without opening a new shell. If you logon via PS remoting, you have administrative powers by default and cannot lose them.

UAC is a GUI kludge, and is very grating especially in Powershell.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#74

Post by besselheim » Wed, Jun 08, 2016, 9:39 PM UTC

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

You piqued my curiosity - just made one by extracting the syscall dispatch table from lxcore.sys and placing it alongside the Linux syscall list: https://goo.gl/QHGe1U

A lot of coverage there, but interesting to see which ones aren't yet implemented, at least in the recent build 14342.

(I used Filippo Valsorda's work from https://filippo.io/linux-syscall-table as the Linux syscall data source.)

Re: How the Windows Subsystem for Linux Redirects Syscalls

#75

Post by quux » Wed, Jun 08, 2016, 9:39 PM UTC

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?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#76

Post by quux » Wed, Jun 08, 2016, 9:41 PM UTC

emcrazyone wrote: post #69

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. What about applications that hook to…

There are both free and commercial X servers for Windows, and you can get a linux app running under WSL to work with one of those X servers very easily. I played with it a little bit and it worked fine.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#77

Post by xorblurb » Wed, Jun 08, 2016, 9:44 PM UTC

kevincox wrote: post #57

> the Linux fork syscall has no documented equivalent for Windows Emphasis is mine. I wonder if this is something that cygwin could (ab)use. Also I wonder why they would need this undocumented call.

Cygwin is layered above Win32. Win32 has no provision to nicely handle forks. So even if there was an NT API fork syscall (I'm don't think there is on Windows 10, WSL does not use the NT API, there is not any more Posix/SFU/{Whatever Unix NT classic subsys of the day} as far as I know), this would not go anywhere.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#78

Post by wfunction » Wed, Jun 08, 2016, 9:45 PM UTC

kevincox wrote: post #57

> the Linux fork syscall has no documented equivalent for Windows Emphasis is mine. I wonder if this is something that cygwin could (ab)use. Also I wonder why they would need this undocumented call.

It's been tried and failed. See [1].

[1] https://cygwin.com/ml/cygwin-developers/2011-04/msg00036.htm...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#79

Post by wfunction » Wed, Jun 08, 2016, 9:47 PM UTC

l3m0ndr0p wrote: post #16

serge2k wrote: post #10

Earlier quoted context omitted.

> Get rid of the Windows NT Kernel. I believe it's outdated & doesn't have the same update cycle that the Linux Kernel has. Curious why you claim this? What's outdated about the NT Kernel?

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…

> or maybe this is not part of the NT Kernel

> 1. The use of drive letters A-Z for file system access.

Indeed it is not. The kernel sees a single root for the object namespace, not drive letters.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#80

Post by xorblurb » Wed, Jun 08, 2016, 9:51 PM UTC

detaro wrote: post #68

_RPM wrote: post #50

Does Microsoft document all system calls?

They document the WinAPI, but how that talks to the kernel is not documented. You can talk to it directly if you want, but there is nothing from Microsoft on how to do that. So if you see those as the true system calls, they are not documented at all.

Well, tiny parts of the NT API (callable from userspace) are documented, but then often with the caveat that they are not stable (in practice, even some undocumented ones can be considered stable if used by enough programs in the wild, especially if they are simple and standalone and have no Win32 equivalent)

The very precise mechanism, though, is extremely unstable. For example virtually every release of Windows (even sometimes SP) changes the syscall numbers. You have to go through the ntdll, which is kind of a more heavyweight version of the Linux VDSO. (The NTDLL approach was invented way before the VDSO, though)