The Fundamental Failings of Microsoft Windows r26 (See the current copy)

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.

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

  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.
    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. ...
    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:
    2. Why this behavior can never be removed:
    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.

Quotes