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

101–110 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#101

Post by deprave »

ksk wrote: post #94
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…

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.

I'm sorry, who's "we"? You replied to a comment that presented fact. The fact is that Windows use is mostly limited to desktops. As far as you're concerned, I could be entirely illiterate and my argument would still hold because it's based on fact. If you want to claim Windows is superior, please don't point us to design documentation. Show us actual numbers and use cases where Windows outperforms Unix, or is used in critical infrastructure, etc.

(FYI, I've read the "internals" book for a relatively old version of Windows, along with plenty of books about attacking the Windows kernel through its huge attack surface that exists to accommodate various needs of various software vendors...)

Re: How the Windows Subsystem for Linux Redirects Syscalls

#102

Post by xodjoshd »

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.

But this is exactly what made me switch, windows was preventing me from accessing my sound card directly in order to record a remote interview.

I use Linux regularly to record and edit audio, it's free , it works, and I dont have to worry my OS is active reducing the functionality of my equipment.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#103

Post by zxcvcxz »

You should also mention that you're the author of Windows only software that directly exploits certain features specific to Windows. An implementation of python that according to http://pyparallel.org/ out-performs pretty much every other technology. Is that correct? I'm also wondering if anyone has replicated these results? From what I can find not a single person has replicated your tests.

According to your own website pretty much every other technology runs better on Linux than it does on windows (http://pyparallel.org/wrk-rps-comparison2.svg).

It could be said you're a little biased, seeing as your software only targets Windows.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#104

Post by piscisaureus »

bitwize wrote: post #83
tremon wrote: post #63

Earlier quoted context omitted.

But the NT kernel is much more sophisticated and powerful than Linux That does not follow from the example. All it shows is that Microsoft prefers to put a lot of functionality in one interface, while Linux probably prefers low-level functions to be as small as possible, and probably offers things like filtering on a higher level (in glibc, for example). Neither explanation has anything to do with sophistication. I p…

Actually it does, as it mentioned that the extra parameters are for things like async callbacks and partial results. The I/O model that Windows supports is a strict superset of the Unix I/O model. Windows supports true async I/O, allowing process to start I/O operations and wait on an object like an I/O completion port for them to complete. Multiple threads can share a completion port, allowing for useful allocation…

I wrote the windows bits for libuv (node.js' async i/o library), so I have extensive experience with asynchronous I/O on Windows, and my experience doesn't back up parent's statement.

Yes, it's true that many APIs would theoretically allow kernel-level asynchronous I/O, but in practice the story is not so rosy.

* Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented (https://support.microsoft.com/en-us/kb/156932), but asychronous I/O also actually blocks in cases that are not listed in that article (unless the disk cache is disabled). This is the reason that node.js always uses threads for file i/o.

* For sockets, the downside of the 'completion' model that windows is that the user must pre-allocate a buffer for every socket that it wants to receive data on. Open 10k sockets and allocate a 64k receive buffer for all of them - that adds up quickly. The unix epoll/kqueue/select model is much more memory-efficient.

* Many APIs may support asynchronous operation, but there are blatant omissions too. Try opening a file without blocking, or reading keyboard input.

* Windows has many different notification mechanisms, but none of them are both scalable and work for all types of events. You can use completion ports for files and sockets (the only scalable mechanism), but you need to use events for other stuff (waiting for a process to exit), and a completely different API to retrieve GUI events. That said, unix uses signals in some cases which are also near impossible to get right.

* Windows is overly modal. You can't use asynchronous operations on files that are open in synchronous mode or vice versa. That mode is fixed when the file/pipe/socket is created and can't be changed after the fact. So good luck if a parent process passes you a synchronous pipe for stdout - you must special case for all possible combinations.

* Not to mention that there aren't simple 'read' and 'write' operations that work on different types of I/O streams. Be ready to ReadFileEx(), Recv(), ReadConsoleInput() and whatnot.

IMO the Windows designers got the general idea to support asynchronous I/O right, but they completely messed up all the details.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#105

Post by zxcvcxz »

trentnelson wrote: post #90
SwellJoe wrote: post #87

Earlier quoted context omitted.

I have never worked with systems-level Windows programming, so I don't know the answer to this...but, how is what you're describing better than epoll or aio in Linux or kqueues on the BSDs? I'm guessing you're coming from the opposite position of ignorance I am (i.e. you've worked on Windows, but not Linux or other modern UNIX), though, since "setting O_NONBLOCK and buzzing in a select loop, interleaving bits of I/O…

To quote myself: > The “Why Windows?” (or “Why not Linux?”) question is one I get asked the most, but it’s also the one I find hardest to answer succinctly without eventually delving into really low-level kernel implementation details. > > You could port PyParallel to Linux or OS X -- there are two parts to the work I’ve done: a) the changes to the CPython interpreter to facilitate simultaneous multithreading (platfo…

http://pyparallel.org/wrk-rps-comparison2.svg

According to your website pretty much every other technology runs better on Linux than it does on Windows, and of course pyparallel runs better than everything you tested.

How can I run these tests my self? I specifically want to test it against golang.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#106

Post by madez »

tacos wrote: post #100
cbd1984 wrote: post #91

Earlier quoted context omitted.

Audio on Linux works fine in my experience.

Hey everyone, we found him!

I don't want to take sides in this discussion but share an anecdote. Hey, maybe even someone knows a solution for this.

I have a PC connected via on-board HDMI to a Denon AVR solely for the purpose of getting the audio to the amplifier. Windows doesn't let me use that audio interface without extending or mirroring my desktop to that HDMI port. Since there is no display connected to the AVR I don't want to extend the desktop, and mirroring heavily decreases performance of the system.

On Debian Sid the computer by default allows me to use the HDMI audio without doing anything to my desktop display. It seems the system realizes that there is no display connected to the AVR but it's still a valid sink for audio.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#107

Post by jasonm23 »

deprave wrote: post #61
bitwize wrote: post #46

Earlier quoted context omitted.

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.

Since when is kernel complexity a measure of quality...? :)

hmmm...

Usage of the adjective "sophisticated" always precedes an outpouring either ignorance or straight bs.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#108

Post by MarkSweep »

SwellJoe wrote: post #87
bitwize wrote: post #83

Earlier quoted context omitted.

Actually it does, as it mentioned that the extra parameters are for things like async callbacks and partial results. The I/O model that Windows supports is a strict superset of the Unix I/O model. Windows supports true async I/O, allowing process to start I/O operations and wait on an object like an I/O completion port for them to complete. Multiple threads can share a completion port, allowing for useful allocation…

I have never worked with systems-level Windows programming, so I don't know the answer to this...but, how is what you're describing better than epoll or aio in Linux or kqueues on the BSDs? I'm guessing you're coming from the opposite position of ignorance I am (i.e. you've worked on Windows, but not Linux or other modern UNIX), though, since "setting O_NONBLOCK and buzzing in a select loop, interleaving bits of I/O…

I think IO Completion Ports [1] in Windows are pretty similar to kqueue [2] in FreeBSD and Event Ports [3] in Illumos & Solaris. All of them are unified methods methods for getting change notifications on IO events and file system changes. Event Ports and kqueue also handle unix signals and timers.

Windows will also take care of managing a thread pool to handle the event completion callbacks by means of BindIoCompletionCallback [4]. I don't think kqueue or Event Ports has a similar facility.

[1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... [2]: https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 [3]: https://illumos.org/man/3C/port_create [4]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

Re: How the Windows Subsystem for Linux Redirects Syscalls

#109

Post by bigger_cheese »

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…

My biggest pet Peeve about Windows is the way it accesses files I'm not sure if this is a kernel or filesystem issue. But when a remote user has a file open as long as that file is open other users are prevented from updating or replacing the file. It happens all the time at my work and I know of no obvious way to work out who has the file open because as far as I can tell nothing like lsof exists.

This is probably the number one cause of me banging my head against the desk and wishing Windows behaved more like Linux.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#110

Post by rbanffy »

ckaygusu wrote: post #60
bitwize wrote: post #46

Earlier quoted context omitted.

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.

I remember the struct I had to populate to start a new process in 1997 or 1998...
Post reply on HN