Does anybody know how fork() is implemented? This blog post kind of sounds like fork() would do the slow emulation of it through CreateProcess().
fork() is properly implemented by the NT kernel. WSL is not layered above Win32.
How the Windows Subsystem for Linux Redirects Syscalls
41–50 of 274 posts
Re: How the Windows Subsystem for Linux Redirects Syscalls
#42.
Linux Subsystem for Windows could also be misread the same way. Both are ambiguous.
Re: How the Windows Subsystem for Linux Redirects Syscalls
#43> 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.
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...)
Re: How the Windows Subsystem for Linux Redirects Syscalls
#44I 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…
Well I've personally seen Microsoft employees themselves complaining about the state of NT while saying it's "fallen behind Linux".
An old HN commenter once wrote (mrb)
> There is not much discussion about Windows internals, not only because they are not shared, but also because quite frankly the Windows kernel evolves slower than the Linux kernel in terms of new algorithms implemented. For example it is almost certain that Microsoft never tested I/O schedulers, process schedulers, filesystem optimizations, TCP/IP stack tweaks for wireless networks, etc, as much as the Linux community did. One can tell just by seeing the sheer amount of intense competition and interest amongst Linux kernel developers to research all these areas.
>The net result of that is a generally acknowledged fact that Windows is slower than Linux when running complex workloads that push network/disk/cpu scheduling to its limit: https://news.ycombinator.com/item?id=3368771 A really concrete and technical example is the network throughput in Windows Vista which is degraded when playing audio! https://blogs.technet.microsoft.com/markrussinovich/2007/08/...
>Note: my post may sound I am freely bashing Windows, but I am not. This is the cold hard truth. Countless of multi-platform developers will attest to this, me included. I can't even remember the number of times I have written a multi-platform program in C or Java that always runs slower on Windows than on Linux, across dozens of different versions of Windows and Linux. The last time I troubleshooted a Windows performance issue, I found out it was the MFT of an NTFS filesystem was being fragmented; this to say I am generally regarded as the one guy in the company who can troubleshoot any issue, yet I acknowledge I can almost never get Windows to perform as good as, or better than Linux, when there is a performance discrepancy in the first place.
Re: How the Windows Subsystem for Linux Redirects Syscalls
#45Earlier 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…
> `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 directory hard links. (EDIT: For some reason, I forgot that Linux doesn't have these, either. Maybe I was thinking of bind mounts.)
Re: How the Windows Subsystem for Linux Redirects Syscalls
#46> 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.
Re: How the Windows Subsystem for Linux Redirects Syscalls
#47> 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.
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.
Re: How the Windows Subsystem for Linux Redirects Syscalls
#48Re: How the Windows Subsystem for Linux Redirects Syscalls
#49Earlier 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…
A-z drive letter is just a win32 thing.
Symbolic links is supported by NTFS, just not exposed to normal users.
That's just your opinion about powershell...
UAT, and runas?
Re: How the Windows Subsystem for Linux Redirects Syscalls
#50Does Microsoft document all system calls?