Hacker News Reader

Comment by tombert | Hacker News Reader

I agree that networking stuff feels pretty frustrating on Windows compared to POSIXey stuff; for the most part using a good networking library like (as mentioned above) ZeroMQ or even some of the built-in JVM socketing stuff will help abstract it, but Unix sockets are simply better out of the box.

Even a simpler example though; the fact that there wasn't really a built-in analog for the "pipe" until PowerShell sort of boggles the mind. Yes, I'm aware that Windows isn't command-line focused, but it baffles me that software engineers didn't really see a need in Windows to compose programs together. (Someone, please correct me if I'm wrong on this point, I haven't touched Windows in any serious capacity in almost a decade).

View on HN

Windows IO model - including network - is arguably much more well designed than anything POSIX, thanks not least to Dave Cutler and his team.

From the get-go Windows NT (Win32) had a common model for overlapped IO (async IO in today's parlance). This async capability permeated everything from disk IO to network IO, and works well today with USB, Thunderbolt etc. Mind you, this model has not changed while Unix/Linux/POSIX still have not found a common model that works for all. See for instance https://stackoverflow.com/questions/13407542/is-there-really...

Under the hood Windows was also designed with a completion-oriented model (IO completion ports) which scales better in most instances than the Linux readiness-oriented approach (I believe that MacOS uses a completion approach as well, so the readiness approach is not universal *nix). Basically, windows saves at least one context switch for every basic IO operation. Windows supports the Berkeley sockets API with some optional extensions to make socket operations overlapped/async as well, essentially supporting both the straight socket model as well as the completion oriented extensions.

You appear to understand this stuff better than me, so you've gotten me a bit curious; how did something like Java NIO work before kernel 5.1?

This is a very enlightening post, thank you. I don't often develop cross platform to this depth, and I think it is a wise reminder that Microsoft actually knows a thing or two about operating systems, contrary to popular opinion. It's almost like the application teams sabotage the OS teams...

You could always pipe commands, there just weren’t any worthwhile to pipe to. I often consulted this site often twenty years ago:

https://ss64.com/nt/syntax-redirection.html

And half the time you’d have to use the “for” cli monstrosity. I looked up the instructions every single time I used it for decades, that’s how bad it was/is.

Windows has many ways to compose programs together, but usually the applications need to be designed to be composed together. The idea wasn't just to shuffle text around, but entire binary objects and shared state.

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

This is definitely getting deep into the Windows world, and if you didn't do a lot of highly Windows focused software development its probably easy to miss it. COM is a big giant complicated beast and definitely not a complete darling to work with but it had (has?) a lot of really cool concepts. Very different from the everything is a stream of text basis in Linux. And even now with things like Powershell, you're not sending text to the things you're piping to, you're passing .NET objects around.

socketing stuff will help abstract it, but Unix sockets are simply better out of the box

Can you elaborate? Do you mean performance? Because the on the C level both use (apart from some minor differences, which aren't enough to call one 'simply better' than the other) the same berkeley socket API.

Again, haven't touched Windows in years so it's entirely possible that I'm wrong or out of date, but the last time I did any kind of networking on Windows was with the WinSock API, which if I recall correctly, didn't have any support for any kind of IPC out of the box, and I had to do everything with TCP.

I might have been too harsh on Windows there, I've never paid to do any direct socket-level programming within Windows.

Do you mean Unix domain sockets by "IPC"? TCP sockets are also a perfectly valid IPC mechanism, as are many others. Win32 generally promotes pipes (named, if needed) for this purpose. For sockets, if you insist on them, it offers some optimizations for local/local TCP connections. Win10 eventually added Unix sockets, mostly for WSL integration (https://devblogs.microsoft.com/commandline/af_unix-comes-to-...). In the end, it's all just byte streams, so it doesn't matter much once you get past establishing connection.

The biggest annoyance with Windows sockets is that they aren't really unified with files - as in, a socket file descriptor cannot be passed to file APIs that work on FDs, like read() and write(); you have to use send/recv(). This makes it harder to write generic code in C, since you need an abstraction layer for code that deals with I/O streams. But most frameworks already offer such an abstraction layer - e.g. a .NET API would just use Stream (and if it's a socket, it would be a NetworkStream instance).

It hasn't changed! Except for PowerShell, but that's... oy.

I have PowerShell, Git Shell and Cygwin running on my windows Dev box and all three make me cry on a weekly basis because I have to switch between them to do different things. I suppose one day I will sit down to fix my Windows dev environment, but it makes me feel so bloody frustrated that my muscle-memory shell is so ... perverted by windows implementations.

MS is bringing Bash to windows natively. I don't know how that is going to work since piping just isn't there, but I've got my fingers crossed that I'll only have to deal with ONE shell for windows!!!

"Bash for Windows" is just WSL2 (forget WSL1 existed, as a proof of concept market validator it was good, but it has real issues because bridging NT -> Linux syscalls is hard.).

It's not a native Bash experience but it's pretty close. I say "not native" because it's actually running a VM under the hood and bridging the file systems via 9P network protocol.

I know people who are using it and love it. I have not switched yet, but I am definitely going to investigate it at some point.

I came from the Windows world to Linux. Especially when it comes to Enterprise, my experience is that Windows Admins are more likely to know network basics then Linux admins.

However, Linux admins who know networking usually have a deeper understanding.

Reply on news.ycombinator.com