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

Re: How the Windows Subsystem for Linux Redirects Syscalls

#51

Post by zxcvcxz » Wed, Jun 08, 2016, 9:05 PM UTC

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.

>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 playback that was directly connected with mechanisms employed by the Multimedia Class Scheduler Service (MMCSS), this is used on a lot of audio setups. If they can't even get audio setups right how can people consider anything Windows releases "sophisticated"?

It's made to do anything you throw at it I guess, it's definitely complicated, but powerful and sophisticated aren't words I would use to describe NT.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#52

Post by yread » Wed, Jun 08, 2016, 9:05 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…

4. Shift+Right click or CPAU http://www.joeware.net/freetools/tools/cpau/ for command line

Re: How the Windows Subsystem for Linux Redirects Syscalls

#53

Post by jdmichal » Wed, Jun 08, 2016, 9:05 PM UTC

wtallis wrote: post #40

jdmichal wrote: post #22

Earlier quoted context omitted.

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.

I'm not familiar with what you mean by readline compatibility. I see a GNU Readline library with history functions, but I'm not sure what that means being integrated into a shell, and what features you would expect to see.

My experience with tab completion in PowerShell is great. It completes file paths, command names, command parameter names, and even command parameter values if they're an enumeration. Could you describe what else you would expect to see?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#54

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

wtallis wrote: post #40

jdmichal wrote: post #22

Earlier quoted context omitted.

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.

Tab completion works nicely and you can even rotate through the different values a parameter can take. Also, ctrl+space lists all the options (parameters, values, files, folders) available at your cursor's position.

I would call it something more than acceptable scripting language. It is object oriented and it can easily use C# libraries, which is pretty neat.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#55

Post by ygra » Wed, Jun 08, 2016, 9:11 PM UTC

jdmichal wrote: post #53

wtallis wrote: post #40

Earlier quoted context omitted.

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

I'm not familiar with what you mean by readline compatibility. I see a GNU Readline library with history functions, but I'm not sure what that means being integrated into a shell, and what features you would expect to see. My experience with tab completion in PowerShell is great. It completes file paths, command names, command parameter names, and even command parameter values if they're an enumeration. Could you des…

https://github.com/lzybkr/PSReadLine perhaps. Personally I find it nice, but it requires a bunch of tweaking to feel comfortable, but maybe less so to people who are used to readline.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#56

Post by dsp1234 » Wed, Jun 08, 2016, 9:11 PM UTC

mmebane wrote: post #45

jdmichal wrote: post #22

Earlier quoted context omitted.

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…

> `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required. There are several limitations in the Windows/NTFS implementation, however: 1. You have to specify the target type (file or directory) at link creation time. 2. Creating symbolic links requires either being an Administrator user, or having the "Create symbolic links" group policy enabled for your account. 3. No real dir…

3. No real directory hard links. Junction points are close, but still distinguishable from

Windows isn't the only OS that disallows creating directory hard links.

http://askubuntu.com/questions/210741/why-are-hard-links-not...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#57

Post by kevincox » Wed, Jun 08, 2016, 9:12 PM UTC

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

Re: How the Windows Subsystem for Linux Redirects Syscalls

#58

Post by vegabook » Wed, Jun 08, 2016, 9:13 PM UTC

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.

They should probably just buy Canonical. That would put the shivers into Google, properly.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#59

Post by darkengine » Wed, Jun 08, 2016, 9:15 PM UTC

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.

It may be more "sophisticated" (sounds like a more positive synonym of "complex" to me), but I certainly don't think it's more powerful.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#60

Post by ckaygusu » Wed, Jun 08, 2016, 9:15 PM UTC

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.

I think the problem here is not a syscall taking 11 parameters, it's a syscall that merely lists what is inside a directory taking 11 parameters. ataylor_284 explained the reasons (how convincingly, I'd argue) but on the first sight that surely smells bloat.

I'd also object NT kernel being more "powerful". Sure unixy kernels and NT has their differences but I don't think either one is superior.