Why I hate Microsoft

"A personal, lengthy, but highly articulate outburst"

Appendix A: A brief overview of Windows' most serious design flaws

The Windows architecture has many design flaws that no amount of patching or updating can ever remedy. Readers of this paper have indicated the need for a brief summary.
The following list is by no means comprehensive, but only summarizes the most serious structural shortcomings that cripple the Windows operating system.

• Limited memory protection and memory management. When an application contains bugs or runs wild, it may often write to memory locations outside its own memory space, thereby crashing the entire system. Attempts to allocate more memory than is available often generates an exception, causing the application to crash instead of allowing it to recover gracefully. Similarly, out-of-boundary reads are also possible, which potentially compromises security.
• Insufficient process management. The OS relies heavily upon the application to release allocated resources. If an application hogs resources or fails to release them for some reason, either while running or upon termination, the OS often cannot reclaim those resources. Nor does the OS offer an administrator full control over processes and resources.
• No adequate separation between user-level and kernel-level code. An application may install DLLs or drivers. This introduces essentially uncertified, third-party code to the system, that may run at kernel-level, i.e. completely unprotected. Applications may also introduce modifications into the registry without any protection or verification whatsoever, which may cause other applications or even the OS to crash. This seriously compromises the reliability of the entire system. In fact Windows is the only major operating system in the market that may break whenever a user installs an application (essentially a user-level operation). In Windows 2000 and later a simple driver signature system has finally been implemented, but in practice this is not sufficient to guarantee stability.
• Lack of meaningful error messages. Whenever an error message is displayed, it rarely tells you exactly what the problem is. Nor does it give you enough details (e.g. an error or condition number) that would enable a support technician to trace the cause of a problem.
• No maintenance mode. When one or more of the 10,000+ files that make up the OS become corrupted, there is no maintenance mode that allows you to bring up the OS in a controlled state, doing repairs along the way. 'Safe mode' merely swaps configurations but offers little additional control. The OS either runs or crashes. The Windows 2000/XP Repair Console (an external utility on the Windows CD that may be run from the setup routine) does not allow you to run the OS in a maintenance mode, it merely allows you to access the file system of a broken Windows installation. Even finding out which files have been corrupted is often impossible.
• No code sharing. Only DLL code can be shared, which makes up only a tiny fraction of the entire OS and application code.
• No version control whatsoever on DLL code. The OS cannot distinguish one DLL from another one with the same name, even though they may contain entirely different code. Installers can, but generally don't bother with it (beyond warning the user that version x is about to be replaced with version y). The OS however will happily load whatever code is present in the DLL file it happens to find first.
• A very rudimentary and weak security model. Microsoft products have the worst security rating (and track record) in the industry. Their developers seem to have been completely unaware of even basic security issues.
• Rudimentary multi-user support. Being the offspring of a stand-alone, single-user desktop OS, Windows can only be implemented in a LAN (or any other environment where users share computing facilities) by means of cumbersome workarounds and kludges. Multi-user applications (e.g. Citrix, Windows Terminal Server) is even more problematic.
• OS code, application code and user data cannot be maintained separately from the OS and from each other. The OS is even designed to prevent this. Applications need to be "installed" i.e. integrated into the OS, a procedure that adds to or even overwrites part the OS fileset, may overwrite other application files or (registry) settings, and usually requires an OS reboot. The installation of one application may break another application.
• Windows does not follow global protocol standards correctly. It even deliberately ignores them in favor of proprietary implementations.
• Windows' API is only partially documented. Much of the operating system and the API remain essentially a black box to third-party developers. This causes problems during application development that often cannot be traced. Developers are forced to use workarounds, and may even be tempted to circumvent or ignore the API altogether. This, and the fact that nobody outside Microsoft really knows what goes on in the underlying code, leads to application software that won't run correctly (if at all) on updated or new versions of Windows.
• Windows' code is a collection of bad programming practices. It contains a huge amount of sloppy code and kludgey design, which results in an extremely glitchy and buggy end product. (A good example of sloppy programming is buffer access, which is routinely left unchecked in release versions of all Microsoft products. As a result of this amateur approach, Microsoft products are riddled with buffer overrun vulnerabilities. Of course buffer overruns don't only occur in Microsoft products but are also found in other software on other platforms. But the difference is in the numbers.) Bloated code has made Windows' efficiency the lowest in the market, requiring more resources and yielding less performance than any other OS in existence.

Comments? E-mail me!