The Fundamental Failings of Microsoft Windows

Why Microsoft Windows Can Never Be Fixed

Microsoft Windows is a poorly designed system. Most people would agree with this statement and cite implementation issues such as poor security, poor performance, and poor support systems. However, these are The Superficial Failings of Microsoft Windows and can be addressed and solved over time. Microsoft Windows however, will always be a poorly designed system due to fundamental flaws in its design. These flaws are so fundamental that most Microsoft Windows administrators and users do not even understand that they are flaws at all -- instead they think of the limitations as features or do not think of them at all, and just accept them as the way things are.

  1. Drive Letters
    1. Why they are a failure:
      1. Drive letters are a very distinctive feature of Microsoft Windows -- no other modern operating system uses them. There is a reason for that. Drive letters are a failure.
      2. They do not add value and they provide an artificial constraint on path names. Consider the path "A:\WINDOWS\SYSTEM32", the "A:" portion is the drive letter specifier and it contains only information we do not care about (i.e., information related to the physical hardware of the system which we would like to be abstracted away).
      3. Using drive letters reduces the namespace for initial component of path names to a meaningless (to the user) component that the system has assigned very special meaning and semantics to.
      4. Drive letters are a conflation of the logical (path names) and the physical (disks) into a single unit of information that is necessarily a brittle pointer.
    2. Why they can never be removed:
      1. Well, they actually CAN be removed as they have been Microsoft Windows CE and Microsoft Windows Mobile. It would take a lot of reworking, especially of mounting network volumes (which are typically done with the scope of a particular session), and the end result would be unrecognized by users.
    3. Give me an example:
      1. Say you have a Microsoft Windows Server with 8 drive letters corresponding to several partitions on several drives. This is obviously not ideal, but as it was configured this way reconfiguring it will require reconfiguring every application that points to a drive letter other than the one where Microsoft Windows Server itself is installed. This machine suffers a hardware failure and dies. To restore it from backups you must configure a new machine also with 8 partitions and with enough space on each one to accommodate the files and expected growth for each separate division. You do not know from the backups how much data each partition stored. This is obviously not space efficient.
    4. Notes:
      1. Some have argued that it is possible to overcome this limitation by treating "C:" as the root node. This is apparently not possible to do due to the way network shares are handled.
  2. Different Types of Executables
    1. Why they are a failure:
      1. On the surface, having different types of executables to represent fundamentally different tasks seems like a good idea. Why include code for a Windows GUI in a binary that will only ever run as a service (or daemon) after all ? The answer is simple. You don't. But with the solution Microsoft Windows has implemented, you don't get the choice. If you want to provide a Microsoft Windows application that is a regular application, some user cannot treat it as a daemon later on without either modifying the source or wrapping it in another application to manage the Service Control Manager interface. Neither solution is ideal. This is actually a few different problems:
        1. Microsoft Windows GUI applications can't be run in text application
        2. Microsoft Windows text applications can't be run as a GUI application
        3. Microsoft Windows text applications can't be run as a service
      2. Confused yet ? This is merely explicitly stating what was said before -- Microsoft Windows applications can only used as the class of application they were compiled for.
      3. So what ? Who wants to run Microsoft Windows text applications as a GUI application ? Well, I do. I use scripting languages, which are single binaries that sometimes need to be in text mode and sometimes in GUI mode depending on the data (script) being processed.
      4. So what ? Who wants to run Microsoft Windows text application as a service ? Well, again I do. I often times want to take some random process and have it run the entire time the system is running. It's somewhat possible to get this effect using the "Scheduled Tasks" system, but not very easily.
    2. Why they can never be removed:
      1. Doing so would require guess-work on part of the (now unified) interpreter/loader for executables. Since the windowing system is guaranteed to be available, you can't use implicit context to determine how to run the application either.
    3. Notes:
      1. Graphical versus Service versus Text Mode
      2. Makes it impossible to have one executable to execute in different manners according to context, further you can't just take an arbitrarily long-running process and make it into a daemon (however a service can be turned into an arbitrarily long-running text-mode process if written so).
  3. Open Files may not be Deleted
    1. Why this behavior is a failure:
      1. This problem is the most common fundamental failing that non-Administrators will experience. This functionality is fundamental because it is the basis for many high level concepts that the Microsoft Windows operating systems provides to applications (e.g., GetModuleFileName(), ...). It is a failure because it limits what the user can do artificially.
    2. Why this behavior can never be removed:
      1. Far too many Microsoft Windows applications rely on this behavior being present.
    3. Notes:
      1. This is just retarded -- there's no reason not to allow this operation.

Microsoft Windows users are the real prisoners as described in the UNIX-HATERS Handbook.

Why Should I Care ?

I used to think that Microsoft Windows was benign -- a problem that, while a lot of other people had it, was a problem for other people.

Recently I became a system administrator for a small (around 20) group of Microsoft Windows Server systems. This experience caused me to realize how much less efficiently problems are solved by users and administrators of Microsoft Windows systems due to limitations of that platform.

It is during this time that I came to understand that when people that I interact with use Microsoft Windows it is bad for me, even if I do not use it myself.

Quotes