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

91–100 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#91

Post by cbd1984 »

recursive wrote: post #82
zxcvcxz wrote: post #51

Earlier quoted context omitted.

>the NT kernel is much more sophisticated and powerful than Linux Source? It's not sophisticated enough or powerful enough to be the most used kernel on super computers (and in the world). Windows pretty much only dominates the desktop market. Servers, super computers, mainframes, etc, mostly use Linux. A few years ago there was even a bug in Windows that caused degradation in network performance during multimedia pl…

If you're arguing in favor of linux, you probably shouldn't use any arguments that deal with getting audio setups right.

Audio on Linux works fine in my experience.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#92

Post by trentnelson »

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.

You, I like you. You get it.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#93

Post by trentnelson »

UK-AL wrote: post #48
zxcvcxz wrote: post #34

Earlier quoted context omitted.

Can you show me the source so I can check?

Actually there was a leak for 2000, most critics said it was surprisingly good.

There are leaks galore. NT4, 2000, and more recently, the Windows Research Kit. Just google something like 'apcobj.c' and see. (Hah, first link was a github repo!)

Re: How the Windows Subsystem for Linux Redirects Syscalls

#94

Post by ksk »

deprave wrote: post #65
bitwize wrote: post #47

Earlier quoted context omitted.

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.

I appreciate the name-dropping. Dave Cutler's skills aside, Unix predates Windows by decades, and to anyone remotely familiar with kernel development it is clear that the sheer quantity and complexity of subsystems stem from the fact that nobody but Microsoft can actually see, modify, and redistribute Windows' source code. Unless you can actually say "here's why Windows is qualitatively better" and point out specific…

To level the playing field, and if we are to take your opinion seriously, it would be beneficial to know what books or articles or whitepapers you have read to inform yourself about the design of the NT kernel.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#95

Post by xorblurb »

pcwalton wrote: post #89
xorblurb wrote: post #77

Earlier quoted context omitted.

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.

> So even if there was an NT API fork syscall You can do it with NtCreateProcess: https://groups.google.com/d/msg/microsoft.public.win32.progr... (The Win32 userland won't understand what you did, but you can still do it.)

Well, you can do it on some versions of Windows. On Windows 10, and even future version of Windows 10, not so sure...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#96

Post by marvy »

tptacek wrote: post #72
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".

I've heard that Plan 9 doesn't have ioctl. But I guess that doesn't count as mainstream.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#97

Post by CUViper »

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.

midipix is trying to use it, and advertises copy-on-write fork as an advantage over Cygwin, but I don't know how well it works yet. http://midipix.org/#sec-midipix http://midipix.org/git/cgit.cgi/ntapi/tree/src/process

Re: How the Windows Subsystem for Linux Redirects Syscalls

#98

Post by trentnelson »

bitwize wrote: post #46
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.

This is a recurring pattern in Windows development. Unix devs look at the Windows API and go "This syscall takes 11 parameters? GROAN." But the NT kernel is much more sophisticated and powerful than Linux, so its system calls are going to be necessarily more complicated.

Curiosity got the better of me recently when I re-read Russinovich's [NT and VMS - The Rest Of The Story](http://windowsitpro.com/windows-client/windows-nt-and-vms-re...), and I bought a copy of [VMS Internals and Data Structures](http://www.amazon.com/VAX-VMS-Internals-Data-Structures/dp/1...).

Side-by-side, comparing VMS to UNIX, and VMS's approach to a few key areas like I/O, ASTs and tiered interrupt levels are simply just more sophisticated. NT inherited all of that. It was fundamentally superior, as a kernel, to UNIX, from day 1.

I haven't met a single person that has understood NT and Linux/UNIX, and still thinks UNIX is superior as far as the kernels go. I have definitely alienated myself the more I've discovered that though, as it's such a wildly unpopular sentiment in open source land.

Cutler got a call from Gates in 89, and from 89-93, NT was built. He was 47 at the time, and was one of the lead developers of VMS, which was a rock-solid operating system.

In 93, Linus was 22, and starting "implementing enough syscalls until bash ran" as a fun project to work on.

Cutler despised the UNIX I/O model. "Getta byte getta byte getta byte byte byte." The I/O request packet approach to I/O (and tiered interrupts) is one of the key reasons behind NT's superiority. And once you've grok'd things like APCs and structured exception handling, signals just seem absolutely ghastly in comparison.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#99

Post by gpderetta »

Locke1689 wrote: post #85
deprave wrote: post #65

Earlier quoted context omitted.

I appreciate the name-dropping. Dave Cutler's skills aside, Unix predates Windows by decades, and to anyone remotely familiar with kernel development it is clear that the sheer quantity and complexity of subsystems stem from the fact that nobody but Microsoft can actually see, modify, and redistribute Windows' source code. Unless you can actually say "here's why Windows is qualitatively better" and point out specific…

NT's approach to async IO is at least somewhat empirically better as it does not require an extra context switch between receiving a "ready" event and actually performing the IO operation.

Completion notification requires committing a (potentially cache-hot) buffer for an operation that might not complete until some time in the future. With readiness notification you only need to have the buffer ready when you know you will use it.

Also, on an high performance poll/epoll/kevent based system you only need to poll cold fds, while you can do speculative direct read/writes to hot fds, so no need for extra syscalls in the fast case.

That doesn't mean that completion notification doesn't have its advantages, especially when coupled with NT builtin auto-sizing thread pool, but it is not strictly better.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#100

Post by tacos »

cbd1984 wrote: post #91
recursive wrote: post #82

Earlier quoted context omitted.

If you're arguing in favor of linux, you probably shouldn't use any arguments that deal with getting audio setups right.

Audio on Linux works fine in my experience.

Hey everyone, we found him!
Post reply on HN