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

191–200 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#191

Post by uudecode »

bitwize wrote: post #187
uudecode wrote: post #184

Earlier quoted context omitted.

"... so its system calls are going to be necessarily more complicated." Are you implying that an increase in "power" can never be achieved through increasing simplicity?

That's the thing. Just by glancing at the API docs, Windows looks more complicated but where the rubber meets the road in terms of real high-performance application development, Windows is way simpler. In Windows you can do in one syscall what would take several in Linux. You can schedule I/O calls across multiple threads in a completely thread-safe manner without having to manage the synchronization yourself -- and…

"It was designed to make it easy to write quick, "one-off" programs in C."

OK, so it just so happens this is what I love to do. I like writing small programs and continually trying to improve them.

So I guess I should be a UNIX user?

Is NT not good for this too?

BTW, I do like VMS. But despite the NT kernel, using NT feels nothing like using VMS.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#192

Post by dhoe »

clevernickname wrote: post #123
zxcvcxz wrote: post #114

Earlier quoted context omitted.

Here's what I don't understand: If IOCP gives us such a great performance boost why don't I see people using it, even on Windows systems? The first thing that comes to mind is that IOCP can likely only maintain high performance under certain edge-cases that aren't pertinent to the real world, second is that the other I/O models are needed not for unix, but for other aspects of the language its self where IOCP is not…

The simplest explanation is that the performance benefit of using Windows and implementing just about any Windows-specific design is outweighed by the cost of the Windows licensing fees, when compared to a measurably worse-performing Linux or FreeBSD solution that costs nothing. So very few bother to treat Windows versions of "backend" software as anything but an afterthought.

It's not even the licencing fees in my opinion. It's that it has had the equivalent of 200 Potterings run amok in it for 30 years. There are so many things that will eclipse any advantage from IO completion ports.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#193

Post by trentnelson »

bitwize wrote: post #182
wahern wrote: post #172

Earlier quoted context omitted.

They're called threads. Overlapped I/O on Windows is based on a thread pool, which is why you can't cancel and destroy your handle whenever you want--a thread from the pool might be performing the _blocking_ I/O operation, and in that critical section there's no way to wake it up to tell it to cancel. Just... like... on... Unix. The difference between Windows Overlapped I/O and POSIX AIO is that on Windows it's a bla…

The difference between Windows Overlapped I/O and POSIX AIO is that on Windows it's a black box, so people can pretend it's magical. No. The difference is that in Windows you can check for completion and set up an overlapped I/O operation in one system call. Requiring multiple system calls to do the same thing means more unnecessary context switches, and the possibility of race conditions especially in multithreaded…

Running out of places to upvote you.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#194

Post by trentnelson »

uudecode wrote: post #191
bitwize wrote: post #187

Earlier quoted context omitted.

That's the thing. Just by glancing at the API docs, Windows looks more complicated but where the rubber meets the road in terms of real high-performance application development, Windows is way simpler. In Windows you can do in one syscall what would take several in Linux. You can schedule I/O calls across multiple threads in a completely thread-safe manner without having to manage the synchronization yourself -- and…

"It was designed to make it easy to write quick, "one-off" programs in C." OK, so it just so happens this is what I love to do. I like writing small programs and continually trying to improve them. So I guess I should be a UNIX user? Is NT not good for this too? BTW, I do like VMS. But despite the NT kernel, using NT feels nothing like using VMS.

I love writing NT-style C-level (no CRT, just pure C and whatever the CNF/Cutler Normal Form style is).

Re: How the Windows Subsystem for Linux Redirects Syscalls

#195

Post by pjmlp »

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.

Also UNIX devs seem to forget how cumbersome the X11, Xlib and Motif APIs are.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#196

Post by tacos »

cbd1984 wrote: post #137
orbifold wrote: post #128

Earlier quoted context omitted.

Well for various definitions of fine I guess.

It works fine as in "I can listen to audio on my laptop from multiple programs at once, with a centralized way to control audio volume on a per-application or per-sound-device basis." I literally cannot imagine any audio system doing better than that given the hardware I have to work with.

https://en.wikipedia.org/wiki/BeOS

Re: How the Windows Subsystem for Linux Redirects Syscalls

#197

Post by ygra »

stordoff wrote: post #165
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…

> 1. The use of drive letters A-Z for file system access. Why is this a problem? As a user, I've always preferred to have drive letters - it makes it immediately clear if, for example, I'm moving files between different physical drives.

Considering mount points, reparse points, and things like subst, I doubt you can ever really know that. Granted, the deviations from the normal scheme are your own making as a user, but so are the places where you mount volumes from different physical drives in a single root hierarchy.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#198

Post by e12e »

zxcvcxz wrote: post #164
trentnelson wrote: post #139

Earlier quoted context omitted.

I haven't actually. Although now I'm kind of curious.

Why did you two have this same conversation 383 days ago? https://news.ycombinator.com/item?id=9584269

Haha. Well, you know what they say, if it is a good idea today, it's a good idea tomorrow too ;-)

Re: How the Windows Subsystem for Linux Redirects Syscalls

#199

Post by e12e »

trentnelson wrote: post #174
zxcvcxz wrote: post #164

Earlier quoted context omitted.

Why did you two have this same conversation 383 days ago? https://news.ycombinator.com/item?id=9584269

I dunno', I don't remember everyone I reply to, certainly not over a year ago.

You and me both.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#200

Post by strcat »

wfunction wrote: post #156
xorblurb wrote: post #84

Earlier quoted context omitted.

You are right, but those points are details. FD under modern Unixes (esp. Linux, but probably others) serves exactly the same purpose (resource management). The FD where read/write can't be used just don't define those (same principle for other syscalls) -- similarly if you try to NtReadFile on an incompatible Handle it will also give you an error back. Both are in a single numbering space per process. NT largely mak…

> You are right, but those points are details. Uh, no, they are very crucial details. For example, it means the difference between letting root delete /dev/null like any other "file" on Linux, versus an admin not being able to delete \Device\Null on Windows because it isn't a "file". The nonsense Linux lets you do because it treats everything like a "file" is the problem here. It's not a naming issue.

Linux has plenty of file descriptor types that do not correspond to a path, along with virtual file systems where files cannot be deleted...

Your example of device files is hardly universal, and the way it works is useful.

Post reply on HN