Why is “Everything is a File” unique to Unix operating systems?

Everything is a file broke in Unix in the '80s when sockets and X windows came. Original Unix' developers tried (and succeeded, IMO) to fix these problems and created Plan9. In Plan9 all I/O, being regular I/O, GUI applications, networking etc are done through the namespace.

Unix means two things today, one is a useless certification, usually referred as UNIX and the other one is a loose set of tools, ideas and encompassing practices. Mac OS X fits both these definitions.

If the current specifications for UNIX match the original ideologies of Unix is completely different matter.

or linux

For a trivial example, webfs supports REST quite handily without a loss of expressive power (and REST itself is a simple but powerful abstraction), and because things need not be piped through curl, you can, for example, point your image editor at what it believes to just be another file on the filesystem, rather than requiring the image editor to support HTTP.

The other half of this is that abstractions can and are built atop this. The Limbo programming language, for example, provides typed channels (which, as I understand it, also made it into Go) and its standard library provides functions for treating arbitrary files as typed channels. So, the OS need only concern itself with "files" (really, in Plan 9 and Inferno, these are less like files and more like names in the processes' respective namespaces), and whatever complex objects the language concerns itself with are easy to ship around between a process and the outside world without hacks (unless marshalling objects is considered a hack).

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.

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.)