An interesting discussion of how Window NT's lack of everything-is-a-file and standard command line tools metastasizes into a security and configuration nightmare. It gives an idea of how important unix's the unifying metaphors are for creating a good operating system.
The BSD people in the '80s forgot this fundamental abstraction and introduced sockets, then X came, again neglecting 15 years of good practice and introduced a completely incompatible model to do I/O.
Rob Pike, Ken Thompson and other Unix people were dissatisfied with this and created Plan9, a Unix descendant where truly all I/O happens by operating on the namespace and without an ioctl(2) system call.
Many, including myself, believe Unix took a very wrong path in the 80s and that modern Unix is more clumsy and inconsistent than the systems it was designed to replace, but architecturally speaking Windows NT is pretty much the same as modern Unix.
/edit:
I've seen both in the cited article and in OPs link that people confuse files with files descriptors.
> at least in NT NICs are real devices in the namespace.
In Windows you'd use a networking API as well, but the networking API is a convenience layer over file based I/O.
The difference between Windows NT and Plan9 is that Windows NT device I/O is IOCTL based, not composable, not replaceable and not exportable, but it's just how you'd do things in Unix v7.
Compare that to using specialized APIs for different type of I/O, for example using the socket API to do networking, or to use special X libraries to do graphics programming, or to hide another API inside ioctl(2).
Namespaces in Plan9 are not global, each process has a private namespace (though many processes share most of it) allowing the composition of interfaces. (/dev/tty in Unix is different for each process as well). Each graphics program on Plan9 writes to /dev/draw and reads from /dev/mouse and /dev/console, but those are synthetic files implemented by the window manager by multiplexing the framebuffer, mouse and console. As you can see even though the files are synthetized the names in the namespace are the same because namespaces are private for each application and the window manager binds the synthetic files to those names.
/edit:
Ah, and one more thing, file-based I/O means shell scripts can do everything a compiled program could do, like networking.
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/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.)