Disclaimer: Blogging brings out the worst in my writing.
Every day, millions go about their day using
Microsoft Windows. They don't think about it; everybody they know uses it. Windows is the computer and the computer is Windows. Anybody who questions it is just pushed to the sidelines; after all, they're just weird freaks that don't know what they're talking about. Unfortunately, I have yet to see a good criticism of Microsoft Windows that doesn't delve into the deeply technical, while still not relying on sweeping generalizations. I intend to explain here in a clear and concise way just what
is wrong with Microsoft Windows.
Firstly is the inherent architecture and security built into the operating system kernel. The
Windows NT kernel used in Windows 2000, XP, and Vista, is a close relative of the aged
Virtual Memory System (VMS) operating system that was developed by
Digital Equipment Corporation. VMS was a reasonable system; it had a form of overall structure, it had decent security, a powerful (but excessively verbose) command line, and had a very comprehensive help system. However, process spawning was extremely computationally expensive. This is one trait that Windows NT unfortunately inherited (albeit to a lesser degree), and is one aspect that makes it unsuitable for standard
CGI web servers. Furthermore, Windows NT lacks any overall structure;
Eric S. Raymond phrases this as a lack of an overarching metaphor (such as the
UNIX "everything is a file" architecture). This makes the internals inconsistent and conflicting. Also as a consequence of this flaw, the internals change rapidly, and thus software developers have a moving target. Related problems include a very weak command line that was outdated even in the 1980s and relatively difficult and complex sockets.
File attributes are another area that Windows NT falls short in. Most Windows users never touch file permissions for the very simple reason that they're cumbersome and poorly implemented. Holey, even, given the need for backwards compatibility with Windows 9x programs. This is partially a consequence of the lack of an overall paradigm as mentioned earlier, but also introduces another problem: file execution. Whether or not a file can be run as a program is determined by the file extension, which is often spoofed to fool users in many pieces of malware (one example of this is the use of the .com file extension, which is executable in Windows but is also an internet
TLD). On UNIX-like platforms such as
Linux and
FreeBSD, an executable bit is set within the file attributes. This is a slight inconvenience as when a file is downloaded it has to be explicitly marked as executable by the user, but also preempts security problems such as the infamous security flaw in Microsoft Outlook where an attachment would be run without the user's knowledge. This is also more flexible, as a central database isn't needed to store what file types can be run. While on the topic of file extensions, one final note should be made. Windows relies
entirely on the file extension to know what type of file is within the mishmash of bytes. This is flawed, because file extensions are trivial to spoof. Other operating systems, however, actually read the contents to learn the file type.
One of the more egregious goofs that Microsoft made when designing Windows 95 was the system registry. This is a single database that stores system configuration and user preferences. This was done to avoid clutter and to consolidate the numerous configuration files into a single location for convenience. However, this was a technical decision that continues to plague Microsoft to this day. For one thing, it adds a single point of failure to the system. A single file is easily corrupted--by malicious means or otherwise. In addition, the amount of "data creep" in the Windows Registry is astounding, as every program leaves garbage in the registry. As this happens, it becomes ever slower to access registry keys and thus system performance grinds to a halt. Automated registry cleaning programs can repair most of this damage, but can easily make an error and destroy the system (I have in fact had this happen to me).
EDIT: It seems that
Jeff Atwood has the
same views as me. Read it, folks.
Access control is also a touchy matter in Windows. Historically, Windows has been fundamentally a single-user operating system; no boundaries were present between users, and anybody could trample over anybody else's files. This was partially fixed in Windows NT, but it is still far from being powerful or elegant, and programs are permitted to ignore these for compatibility reasons. This was theoretically fixed in Windows Vista, but granting access to every other program becomes a exercise in frustration and defeats the entire purpose anyway. Compare this behavior to UNIX-like systems, where since the very start, extremely rigid and virtually unbreakable walls have been put in place between users; users are locked into their own
home directory, and write access to any files that they don't own requires entering the password for the owner of the file in question. This access to files can be configured individually for read, write, and execute, and different permissions can be assigned to individually to the owning user, the owning group of users, and to everybody else.
The boundaries between kernel space and the more tightly controlled userland are also somewhat porous in Windows. Parts of the graphical system are built into the kernel, and for performance reasons, even parts of a web server have been built into the kernel. As more and more code becomes privileged and therefore has unlimited access to the system memory, the chances of buffer overflows and even more subtle flaws increase. This limits any chance of overall system security quite severely.
Moving further away from the kernel itself, we run into the prickly problem of
package management. To avoid code duplication and to save drive space, many programs depend on external libraries that provide what the program needs. ...In theory. In practice on Windows, every program comes shipped with its own unique versions of various libraries to avoid the problem of DLL hell, where libraries are installed globally and programs break either because their libraries get overwritten, a new incompatible library is installed, and other such problems. This leads to either a waste of hard drive space and lack of security updates as programs bundle everything they need into their installation directory, or a brittle and easily broken system. Other platforms, such as Mac OS X and many Linux vendors, fix this by including a package management program (such as RPM) that keeps track of what programs installed what files to where, and what programs depend on and conflict with in a central database. Most package managers will prohibit installation or removal of programs that would result in other programs breaking, and will also check to make sure that programs are properly installed and haven't been corrupted for whatever reason. This allows users to keep their system in a state of perfect health and prohibits system bloat as all files related to a package are removed.
Going outside of the operating system, we come to userland programs. Microsoft has a track record of adding features to their programs that make them easier to use, but also compromise security. One famous example is the "feature" in Outlook that would open an email attachment without the user's permission or knowledge. Automatic parsing of embedded HTML in emails is another common source of infection. Microsoft Office also has had its problems--and will continue to have them. Notably, macro viruses are a trouble area for it. Microsoft also has a tendency to have a "one size fits all" solution, where every user uses one program. This gives malware authors a single target, whearas on other operating systems, there are numerous programs available for the same task, and thus propogation of a hypothetical virus would be limited even if one were actually seriously available in the wild.
Software development is one of the best ways I can spend my time, in my opinion. It was, in fact, one of the major reasons I finally bit the bullet and moved away from Windows. In Windows, you can develop software in two ways: you can purchase a technically questionable C++ IDE from Microsoft, or you can struggle with installing a compiler suite ported from another platform (generally MinGW, which is a port of gcc). Development is, to put it simply, a nightmare. Unlike many UNIX-likes distributions such as Mac OS X, FreeBSD, or Linux, the system doesn't ship with a Python interpreter or a C compiler, making development right off the bat difficult. There's no real central location of libraries, making compilation debugging tricky. And Windows NT only has partial POSIX emulation, which makes cross-platform software development difficult, if not impossible.
This blog post only scratches the surface; writing a step-by-step criticism of Microsoft Windows would take many months if not years of research. However, this includes a quick summary of the most egregious problems that plague it, and in all probability, unless Microsoft changes at its very core, will continue to do so. The lack of an overall system paradigm, expensive process spawning, a dearth of powerful and robust file attributes, flimsy file type determination, a single point of failure in system settings storage, weak and porous access control, improper kernel space integration, extremely brittle and bloat-prone software management, an incorrect attitude in software development, and difficult software development, all make Microsoft Windows a questionable competitor in the modern operating system market.
