I used to think this, but I did more Windows programming and discovered it's not as bad as the Unix viewpoint makes it out to be. It's true that on Windows a f

I used to think this, but I did more Windows programming and discovered it's not as bad as the Unix viewpoint makes it out to be. It's true that on Windows a file descriptor for a socket has different APIs than for a file, but that's only because file descriptors appear to have been implemented as some half-assed Unix compat layer. The Windows API instead uses a "handle" type, and you can wait for events (with a similar API to select() or poll()) on handles of heterogeneous types, including files, sockets, processes (to listen for process death), message loops (to listen for incoming messages), or condition variables. (See the "remarks" section of http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms68... .) It's ultimately sorta similar to how even-driven loops work in the Unix world, but in practice it's actually much harder to do that sort of thing on Unix, where you instead need to e.g. create a wakeup pipe to fudge `SIGCHLD` into a select loop or rely on newer stuff like `FUTEX_FD` to hook a mutex in. (I'm no Windows apologist, and I think some of the APIs like how async IO work are pretty complex and painful, but I do think the superficial "they got file descriptors wrong" claim is wrong.)