fwiw, while higher-level stuff doesn't use files (just like dbus or X in *nix) low-level Windows is built around handles. You can do a lot of the same with them as you can files on *nix (open, close, control, and usually send/receive), but you need to be a programmer to see that interface. Whether that's a good thing is a matter of preference.
–
MarkDec 4 '11 at 9:38

8 Answers
8

Typical operating systems, prior to Unix, treated files one way and treated each peripheral device according to the characteristics of that device. That is, if the output of a program was written to a file on disk, that was the only place the output could go; you could not send it to the printer or the tape drive. Each program had to be aware of each device used for input and output, and have command options to deal with alternate I/O devices.

Unix treats all devices as files, but with special attributes. To simplify programs, standard input and standard output are the default input and output devices of a program. So program output normally intended for the console screen could go anywhere, to a disk file or a printer or a serial port. This is called I/O redirection.

Does other operating systems such as Windows and Macs not operate on files?

Of course all modern OSes support various filesystems and can "operate on files", but the distinction is how are devices handled? Don't know about Mac, but Windows does offer some I/O redirection.

And, compared to what other operating systems is it unique?

Not really any more. Linux has the same feature. Of course, if an OS adopts I/O redirection, then it tends to use other Unix features and ends up Unix-like in the end.

The opening paragraph simply isn't true. There were operating systems before Unix, and they had features later found in Unix, including I/O redirection.
–
Patrick S.Dec 3 '11 at 21:14

3

Plan 9 has the same concept Everything is a file concept and has even been called "more unix then unix"
–
WilliamDec 4 '11 at 1:09

2

Windows (since NT) goes a bit futher. There are lots of devices that behave like files, such as serial ports and named pipes. You can write to all using WriteFile. But in addition, there's an even bigger category of "synchronization objects" that includes not just files but also mutexes.
–
MSaltersDec 5 '11 at 10:46

The idea that "everything is a file" came from Multics. The designers of Unix based a lot of their work on predecessors, especially Multics. Indeed, a lot of things in computing are based on predecessors.

You can read up on the late Dennis Ritchie's work in the design of Unix for more. He referenced things that they "copied" from Multics, such as the tree-like file system, the command shell, and non-structuring of files. I'm not implying that the Unix folks stole from the Multics folks. For all intents and purposes, it was the same folks.

Having everything as a file or a device in a known hierarchy means you can use the same set of tools for everything. Plan 9 from Bell Labs takes this further with even hardware devices as files.

More importantly, this allows for two very simple and powerful concepts. Basic utilities that do One Thing Well (tm), which can be strung together with pipes as needed. Want to find something in a text file? Use cat to show it, pass it through grep, and you're cooking with gas. That's the real power of the 'Unix' way - specialised applications working together for massive amounts of flexibility.

Mac OS X also follows the Unix philosophy, but it's better hidden (an 'application' bundle is really a directory full of files), and in fact is a proper, certified Unix, descended from NeXT, which used bits of FreeBSD.

With Windows, there are some binary components such as event viewer and registry since, and there's some speed advantages there, in that particular scenario.

Well, plan 9 is plan 9, it sorta works already. Fuse just allows userspace filesystem expansion in.. interesting ways. I like the one where IRC is treated as a FS.
–
Journeyman Geek♦Dec 3 '11 at 10:57

Hmm - you know, I've been meaning to look it up for ages since finding out through an Eric Raymond book years ago... You've actually finally got me over the "get round to it" hump, I've downloaded the ISO and trying it out.
–
Danny StapleDec 3 '11 at 13:23

1

I believe there's a newer version too, called inferno
–
Journeyman Geek♦Dec 3 '11 at 14:06

Because of the special files. When people say "everything is a file in Unix", common files and directories are not what they have in mind. Special files are unique to Unix-like OSes, of which there are many. So it is not unique to the Unix.

Special files serve many purposes. There are e.g. pipes, sockets and, most notably, device files. Pipes and sockets are communication streams between processes.
Much of the functionality of the subsystems is made available to the user space through device files.

Pipes and Sockets

Programs use them just as they'd use ordinary files. In fact, most of the time they don't even care what type of file they use. That's why Unix commands can be so manifoldly combined to form powerful new systems. (See I/O redirection in sawdust's answer)

Device Files

As previously mentioned these act like interfaces for the user space.
For example, in order to eject the cd tray, a programmer would at first open the corresponding device file. Another example: you want your program switch the virtual terminal. Open /dev/console first.

What happens next is not sending mere characters to those files, but issuing ioctl()'s on them. The individual ioctl's you can issue depend on the device. E.g. the console is documented in console_ioctl(4)

When people say "In Unix, everything is a file" what they mean is that also things which are not files are treated as files.

Of course most operating systems work with files. Text files, image files, sound files. But not all operating systems treat devices as files. That's an important difference. If I list the content of my /dev/ folder in my Ubuntu operating system (which is Unix based), I get a list of more than 200 devices. Some of those devices are hardware, but are shown inside a folder. For example hard drives, USB ports, mouse and keyboard, audio devices and printers among others. Some of the devices are virtual, for example /dev/urandom, which behaves as an infinite file full of random numbers. It's not a real file on my hard drive.

All of those devices are treated as files. I can read data from and/or write data into those devices. Here there are examples of copying data from different devices into the audio device. This is possible because they are treated as files. The (geeky) result is the ability to listen to the content of the hard drive, the mouse motion, the computer memory or the pixels of an image. This would be much harder to achieve if devices were not treated as files, because each device would require different methods for reading and writing data.

That being said, what "everything" means varies from system to system. For example, OS X is based on Unix, but does not have a /dev/audio device. It uses a proprietary audio system called CoreAudio. So in this case one might say "almost everything is a file". Then, in systems like Windows, where "everything is not a file", you could still do things like copy the content of a file to printer port (typing something like copy mydocument.txt >lpt1:), which is similar to copying a document to the printer device in Unix systems.

Do other operating systems such as Windows and OS X not operate on files? Yes they do. Windows and OS X operate on files, but Windows does not treat devices as files, which is part of what "everything is a file" means.

I see Multics cited as the source of "everything is a file", but I think you have to look a bit deeper than just device files, named pipes, regular files, etc etc. You have to look at file naming syntax. That makes a big difference even when AUX, CON and LP "magic file names" exist.

See "The Hideous Name" by Rob Pike. It compares Unix file-naming syntax with a couple of other syntaxes, most notably VMS. Note that the mainframe OSes of the late 60s/early 70s, when Unix originated, had what the modern mind would consider extraordinarily rococo file naming syntax. It's been years since I've used VM/CMS, or NOS or NOS/VE, and I've only looked over the shoulder of someone using a Univac OS, but suffice it to say the quirks outnumbered the regularities.

I've never even seen Multics run, but you can see a paper on its file system. It appears that the original Unix took the "everything is a file" a bit further than Multics did, but your mileage may vary.

I am probably going to get reamed for saying this, but I think that saying that everything is a file in Unix is, in fact, a long standing fallacy. What it is really is two things.

Files and devices and a lot of other stuff are objects that can be modeled by an interface that comprises of open, close, read, write, and control functions. Don't even get people started on how ioctl (for control functions) is a untyped kitchen sink. Additionally, the handles to these objects (fds) are candidates for a common class of I/O related behavior, like blocking / non-blocking, async, signals and other.

The namespace for these objects (files, devices, other stuff) is hierarchical. The implementation happens to be called the filesystem, because that's what the majority of the objects are.

There is, of course, no harm in just calling everything files. But in reality, files are these more generic objects, like other things (like devices). From this perspective, this idea is not unique to Unix at all. A lot of other OSes implement such objects with similar interfaces.

Please note that even Linus Torvalds disagrees with that "everything is a file." If you search for "

everything is a bytestream

" you will find interesting philosophies how we mean that everything is not a file for instance an abstract data structure in the memory or a pointer is surely not a file, OK surely anything can be represented as a file but representing and being are 2 different actions.