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.
This problem exists primarily in versions prior to Windows 2000. When an application contains bugs or otherwise runs wild, it may 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.
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.
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.
Drivers, for example, should contain driver code. They should offer the OS an API to interface with the underlying hardware. In Windows however a video driver may also contain virtual desktop code and other nonsense. Not only does the presence of user interface code in a hardware driver illustrate the messy nature of the Windows code's organisation, but it also leads to ridiculous issues such as system tray icons disappearing due to a bug in the video card's driver. (Nvidia comes to mind.) In a well-structured OS this would never happen.
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.
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.
Only DLL code can be shared, which makes up only a tiny fraction of the entire OS and application 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.
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.
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) are even more problematic.
The OS is actually 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.
It even deliberately ignores them in favor of proprietary implementations.
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.
It contains a huge amount of sloppy code and kludgy 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!