Why I hate Microsoft

"A personal, lengthy, but highly articulate outburst"


Table Of Contents | Previous chapter | Next chapter

2. The not-so-good, the bad and the ugly

"... it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words ... their fundamental design flaws are completely hidden by their superficial design flaws."

-- The Hitchhiker's Guide to the Galaxy, on the products of the Sirius Cybernetics Corporation.

Let's be honest: there's no such thing as bug-free software. Initial versions of programs may occasionally crash, fail to de-allocate memory, or encounter untested conditions. Developers may overlook security holes, users may do things nobody thought of, and not all systems are identical.
All software developers are human, and they make mistakes now and then. It happens. But of all software vendors, Microsoft has the worst record by far when it comes to the quality of their products in general.

Microsoft boasts a rather extensive product range, but in fact there's less here than meets the eye. Microsoft has forever been selling essentially the same software over and over again, in a variety of colorful new wrappers.
Microsoft products can be divided into three categories: applications, operating systems, and additional server products. The applications include the Microsoft Office suite, but also Internet Explorer, Media Player, Visio, Frontpage, etc. The operating systems involve desktop and server versions of Windows. On the desktop we find Windows 9x/ME, NT Workstation, Windows 2000 and Windows XP, and on the server end we have Windows NT Server and Windows 2000 varieties such as Windows 2000 Datacenter. The additional server products, e.g. Internet Information Server (IIS) and SQL Server, run on top of one of the Windows server products. They add services (e.g. webserver or database server functions) to the basic file, print and authentication services that the Windows server platform provides.
Windows on the desktop comes in two flavors: the Windows 9x/ME product line, and the Windows NT/2000/XP product line. The different versions within one product line are made to look a bit different, but the difference is in the details only; they are essentially the same. Windows '95, '98 and ME are descended from DOS and Windows 3.x, and contain significant portions of old 16-bit legacy code. These Windows versions are essentially DOS-based, with 32-bit extensions. Process and resource management, memory protection and security were added as an afterthought and are rudimentary at best. This Windows product line is totally unsuited for applications where security and reliability are an issue. It is completely insecure, e.g. it may ask for a password but it won't mind if you don't supply one. There is no way to prevent the user or the applications from accessing and possibly corrupting the entire system (including the file system), and each user can alter the system's configuration, either by mistake or deliberately. The Windows 9x/ME line primarily targets consumers (although Windows '95 marketing was aimed at corporate users as well).
The other Windows product line includes Windows NT, 2000 and XP, and the server products. This Windows family is better than the 9x/ME line; at least these versions use new (i.e. post-DOS) 32-bit code. Memory protection, resource management and security are a bit more serious than in Windows 9x/ME, and they even have some support for access restrictions and a secure filesystem. That doesn't mean that this Windows family is as reliable and secure as Redmond's marketeers claim, but compared to Windows 9x/ME its additional features at least have the advantage of being there at all. But even this Windows line contains a certain amount of 16-bit legacy code, and the entire 16-bit subsystem is a direct legacy from Microsoft's OS/2 days with IBM. In short, all 16-bit applications share one 16-bit subsystem (just as with OS/2). There's no internal memory protection, so one 16-bit application may crash all the others and the the entire 16-bit subsystem as well. This may create persistent locks from the crashed 16-bit code on 32-bit resources, and eventually bring Windows to a halt. Fortunately this isn't much of a problem anymore now that 16-bit applications have all but died out.
Of course Windows has seen a lot of development over the years. But in fact very little has really improved. The new features in new versions of Windows all show the same half-baked, patchy approach. For each fixed problem, at least one new problem is introduced (and often more than one).
Windows XP for example comes loaded with more applications and features than ever before. While this may seem convenient at first sight, the included features aren't as good as those provided by external software. For example, XP insists on supporting DSL ("wideband Internet" networking, scanners and other peripherals with the built-in Microsoft code instead of requiring third-party code. So you end up with things like DSL networking that uses incorrect settings (and no convenient way to change that), scanner support that won't let you use your scanner's photocopy feature, or a digital camera interface that will let you download images from the camera but you can't use its webcam function. Also, applications (e.g. Internet Explorer and Outlook) are integrated in the system more tightly than ever before, and more formerly separate products have been bundled with the operating system.

All versions of Windows share a number of structural design flaws. Application installation procedures, user errors and runaway applications may easily corrupt the operating system beyond repair, networking support is poorly implemented, inefficient code leads to sub-standard performance, and both scalability and manageability leave a lot to be desired. (See also appendix A.) In fact, NT and its successors (or any version of Windows) are not really comparable to the functionality, robustness or performance that the UNIX community has been used to for decades. They may work well, or they may not. On one system Windows will run for weeks on end, on another it may crash quite frequently. I've attended trainings at a Microsoft Authorized Education Center, and I was told: "We are now going to install Windows on the servers. The installation will probably fail on one or two systems [They had ten identical systems in the classroom] but that always happens - we don't know why and neither does Microsoft." I repeat, this from a Microsoft Authorized Partner.
Be that as it may... Even without any installation problems or serious crashes (the kind that require restore operations or reinstallations) Windows doesn't do the job very well. Many users think it does, but they generally haven't experienced any alternatives. In fact Windows' unreliability has become commonplace and even proverbial; the dreaded blue screen has featured in cartoons, screen savers and on t-shirts, it has appeared on airports and buildings, and there has even been a Star Trek episode in which a malfunctioning space ship had to be switched off and back on in order to get it going.
And even if Windows stays up it leaves a lot to be desired. On a fairly serious desktop PC (e.g. a 450MHz PII CPU with 256MB RAM, something we could only dream of a few years ago) four or five simultaneous tasks are enough to tax Windows' multitasking capabilities to their limits, even with plenty of core memory available. Task switches will start to take forever, applications will stop responding simply because they're waiting for system resources to be released by other applications (which may have crashed without releasing those resources), or kernel and library routines lock into some unknown wait condition. Soon the whole system locks up entirely or becomes all but unusable. In short, Windows' process management is as bad a joke as its memory protection and resource management is, and an operating system that may crash entirely when an application error occurs should not be sold as a serious multi-tasking environment. Granted, it does run several processes at once - but not very well. Recent versions of Windows (i.e. 2000 and XP) are a little better in this respect than their predecessors, but not much. Although they have been kludged up to reduce the impact of some of the most serious problems, the basic flaws in the OS architecture remain; a crashing application (e.g. a video player) can still lock up the system or throw it into a sudden and spontaneous warm reboot.

Windows is quite fragile, and the operating system can get corrupted quite easily. This happens most often during the installation of updates, service packs, drivers or application software, and the problem exists in all versions of Windows so far. The heart of the problem lies in the fact that Windows can't (or rather, is designed not to) separate application and operating system code and settings. Code gets mixed up when applications install portions of themselves between files that belong to the operating system (occasionally replacing them in the process). Settings are written to a central registry that also stores vital OS settings. The registry database is basically insecure, and settings that are vital to the OS or to other applications are easily corrupted.
Even more problems are caused by the limitations of Windows' DLL subsystem. A good multi-tasking and/or multi-user OS utilizes a principle called code sharing. Code sharing means that if an application is running n times at once, the code segment that contains the program code (which is called the static segment) is loaded into memory only once, to be used by n different processes which are therefore instances of the same application. Apparently Microsoft had heard about something called code sharing, but obviously didn't really understand the concept and the benefits, or they didn't bother with the whole idea. Whatever the reason, they went and used DLLs instead. DLL files contain Dynamic Link Libraries and are intended to contain libary functions only.
Windows doesn't share the static (code) segment - if you run 10 instances of Word, the bulk of the code will be loaded into memory 10 times. Only a fraction of the code, e.g. library functions, has been moved to DLLs and may be shared.
The main problem with DLL support is that the OS keeps track of DLLs by name only. There is no adequate signature system to keep track of different DLL versions. In other words, Windows cannot see the difference between one WHATSIT.DLL and another DLL with the same name, although they may contain entirely different code. Once a DLL in the Windows directory has been overwritten by another one, there's no way back. Also, the order in which applications are started (and DLLs are loaded) determines which DLL will become active, and how the system will eventually crash.
So there is no distinction between different versions of the same DLL, or between DLLs that come with Windows and those that come with application software. An application may put its own DLLs in the same directory as the Windows DLLs during installation, and may overwrite DLLs by the same name if they exist.
What it boils down to is that the application may add portions of itself to the operating system. (This is one of the reasons why Windows needs to be rebooted after an application has been installed or changed.) That means that the installation procedure introduces third-party code (read: uncertified code) to the operating system and to other applications that load the affected DLLs. Furthermore, because there is no real distinction between system level code and user level code, the code in DLLs that has been provided by application programmers or the user may run at system level, i.e. unprotected. This corrupts the integrity of the operating system and other applications. A rather effective demonstration was provided by Bill Gates himself who, during a Comdex presentation of the Windows 98 USB Plug-and-Play features, connected a scanner to a PC and caused it to crash into a Blue Screen. "Moving right along," said Gates, "I guess this is why we're not shipping it yet." Nice try, Mr. Gates, but of course the release versions of Windows '98 and ME were just as unstable, and in Windows 2000 and XP new problems have been introduced. These versions of Windows use a firmware revision number to recognize devices, so an update of a peripheral's firmware may cause that device to be 'lost' to PnP.
Another, less harmful but mostly annoying, side-effect of code confusion is that different language versions of software may get mixed up. A foreign language version of an application may add to or partially overwrite Windows' list of dialog messages. This may cause a dialog window to prompt "Are you sure?" in English, followed by two buttons marked "Da" and "Nyet".
Peripheral drivers also use a rather weak signature system and suffer from similar problems as DLL's, albeit to a lesser degree. For example, it's quite possible to replace a printer driver with a similar driver from another language version of Windows and mess up the page format as a result. Printer drivers from different language versions of Windows sometimes contain entirely different code that generates different printer output, but Windows is unaware of the difference. This problem has been addressed somewhat with the release of Windows 2000, but it's still far from perfect.

Designing an OS to deliberately mix up OS and application code fits Microsoft's strategy of product bundling and integration. (See below.) But the results are obvious: each file operation that involves executable code puts the entire OS and its applications at risk, and application errors often mean OS errors (and crashes) as well. This leads to ridiculous 'issues' such as Outlook Express that may crash Windows NT 4.0, if NT is a 'high encryption' version with the locale set to 'France'; replying to a message may crash the entire system, a problem which has been traced to one of the DLLs that comes with Outlook. (Are you still with me?)
In a well-designed and robustly coded OS something like this could never happen. The first design criterion for any OS is that the system, the applications, and (in a multi-user environment) the users all be separated and protected from each other. Not only does no version of Windows do that by default, it actively prevents you from setting things up that way. The DLL fiasco is just the tip of the problem. You can't maintain or adequately restore OS integrity, you can't maintain version control, and you can't prevent applications and users from interfering with each other and the system, either by accident or on purpose.

Then there's Windows' lack of an adequate repair or maintenance mode. If anything goes wrong and a minor error or corruption occurs in one of the (literally) thousands of files that make up Windows, often the only real solution is a large-scale restore operations or even to reinstall the OS. Yes, you heard me. If your OS suddenly stops working properly and the files which you need to restore are unknown or being locked by Windows, the standard approach to the problem (as recommended by Microsoft) is to do a complete reinstallation. There's no such thing as single user mode or maintenance mode to do repairs, nor is there a good way to find out which file has been corrupted in the first place, let alone to repair the damage. (The so-called 'safe mode' merely swaps configurations and does not offer sufficient control for serious system repairs.)
Windows has often been criticized for the many problems that occur while installing it on a random PC, which may be an A-brand or clone system in any possible configuration. This criticism is not entirely justified; after all it's not practically feasible to foresee all the possible hardware configurations that may occur at the user end. But that's not the point. The point is that these problems are often impossible to fix, because most of the Windows operating system is beyond the users' or administrators' control. This is of course less true for Windows 9x/ME. Because these are essentially DOS products, you can reboot the system using DOS and do manual repairs to a certain degree. With Windows NT this is of course completely impossible. Windows 2000 and XP come with an external repair console utility on the CD, that allows you to access the file system of a damaged Windows installation. But that's about it.
This leads to ridiculous situations. For example, I tried to install a bugfix from Microsoft for Windows NT, which included a DLL that replaced a previous version in the system directory. However, since Windows keeps this DLL open and locked, this cannot be done while the operating system is running. The README that came with the patch blithely suggested that I reboot my computer using DOS, and manually replace the DLL from the DOS prompt. Apart from the fact that NTFS system partitions cannot be accessed from DOS, which I will ignore for the moment, this inability to allow for its own maintenance is a good demonstration of Windows' immaturity.
The inability to make repairs has been addressed, to a certain degree, in Windows XP. XP comes with a 'System Restore' feature that tracks changes to the OS, so that administrators may 'roll back' the system to a previous state before the problem occurred. Also, the 'System File Check' feature attempts to make sure that some 1000 system files are the ones that were originally installed. If a "major" system file is replaced by another version (for example if a Windows XP DLL file is overwritten by a Windows '95 DLL with the same name) the original version will be restored. (Of course this also prevents you from removing things like Outlook Express, Winfile.exe or Progman.exe, since the specification of what is an important system file is rather sloppy.)
These workarounds are automated processes, and they are largely beyond the user's control. Disabling System File Check requires major surgery, and neither feature can be stopped from undoing modifications that it thinks are incorrect but that may be intentional. There's still no maintenance mode. Even so this may be an improvement over the previous situation: a certain amount of recovery is now possible. On the other hand, this illustrates Microsoft's kludgey approach to a very serious problem: instead of implementing changes in the architecture to prevent OS corruption, they perpetuate the basic design flaw and try to deal with the damage after the fact. They don't fix the hole in your roof, they sell you a bucket to put under it instead.

The inefficiency of Microsoft's program code is of course disastrous to Windows' performance figures. (Where did you think the name 'Windoze' comes from?) Today you need at least a 600 MHz Pentium III to do the same kind of typical office work job under Windows XP that you used to do on a 12 MHz 286 under DOS... in about the same amount of time. Productivity has only been fractionally increased at a hugely inflated Total Cost of Ownership. Can you say "Return On Investment"?
Try this for a laugh: start the performance monitor in NT 4.0 SP3 and have it keep track of the CPU load. Now open the Control Panel. Don't do anything, just open it and leave it there... and enjoy your constant CPU load of 100% on your production server or work station. (To be honest, this doesn't always happen. This 'issue' of CPU cycles being used up somewhere is caused by a combination of factors that MS has never been able to explain. Other applications have been known to trigger this bug as well.) There are also many other ways to waste CPU cycles and other resources on a Windows system. For example, check your system's performance before and after you install Internet Explorer 5.x or later. You don't have to run it, you don't have to make it your default browser... just install it. And watch your performance plummet.
Only 32 kilobytes of RAM in the Apollo capsules' computers was enough to put men on the moon. The Voyager deep space probes have on-board computers based on a 4-bit CPU. An 80C85 CPU with 176 kilobytes of PROM and 576 kilobytes of RAM controlled the Sojourner rover that drove across the surface of Mars and sent us a wealth of scientific data and high-resolution images in full-color stereo. Today I have a 233MHz Pentium II with 64 Megabytes of RAM and 15 Gigabytes of disk space, but if I try to type a letter to my grandmother using Windows and Office XP, the job will take me forever because my computer is underpowered!!
Server-based or network-based computing is no solution either, mainly because Windows doesn't have any real code sharing capability. If you were to shift the workload of ten 450MHz/512MB workstations to an application server (using Windows Terminal Server, Cytrix Server or another ASP-like solutions) you would need a theoretical 4.5GHz CPU speed and 5GB of RAM at the server end to maintain the same performance, not counting the inevitable overhead which could easily run up to 10 or 20 percent.
And then there's the incredible amount of inefficient, or even completely unnecessary code in the Windows file set. Take the 3D Pinball game in Windows 2000 Professional and XP Professional, for example. This game (you'll find it under \Program Files\Windows NT\Pinball) is installed with Windows and takes up a few megabytes of disk space. But most users will never know that it's sitting there, wasting storage and doing nothing productive at all. It doesn't appear in the program menu or control panel, and no shortcuts point to it. The user isn't asked any questions about it during installation. In fact its only conceivable purpose would be to illustrate Microsoft's definition of 'professional'. No wonder Windows has needed more and more resources over the years. A few megabytes doesn't seem much, perhaps, but that's only because we've become used to the enormous footprints of Windows and Windows applications. Besides, if Microsoft installs an entire pinball game that most users neither need nor want, they obviously don't care about conserving resources (which are paid for by the user community). What does that tell you about the resource-efficiency of the rest of their code? Let me give you a hint: results published in PC Magazine in April 2002 show that the latest Samba software surpasses the performance of Windows 2000 by about 100 percent under benchmark tests. In terms of scalability, the results show that Unix and Samba can handle four times as many client systems as Windows 2000 before performance begins to drop off.
Paradoxically, though, the fact that Microsoft products need humongous piles of hardware in order to perform decently has contributed to their commercial success. Many integrators and resellers push Microsoft software because it enables them to prescribe the latest and heaviest hardware platforms in the market. Unix and Netware can deliver the same or better performance on much less. Windows 2000 and XP however need bigger and faster systems, and are often incompatible with older hardware and firmware versions (especially the BIOS). This, and the fact that hardware manufacturers discontinue support for older hardware and BIOSes, forces the user to purchase expensive hardware with no significant increase in return on investment. This boosts hardware sales, at the expense of the "dear, valued customer". Resellers make more money when they push Microsoft products. It's as simple as that.

Apart from the above (and other) major flaws there's also a staggering amount of minor flaws. In fact there are so many minor flaws that their sheer number can be classified as a major flaw. In short, the general quality of Microsoft's entire set of program code is sub-standard. Unchecked buffers, unverified I/O operations, race conditions, incorrectly implemented protocols, failures to deallocate resources, failures to check environmental parameters, et cetera ad nauseam... You name it, it's in there. Microsoft products contain some extremely sloppy code and bad coding practices that would give an undergraduate some well-deserved bad marks. As a result of their lack of quality control, Microsoft products and especially Windows are riddled with literally thousands and thousands of bugs and glitches. Even most of the error messages are incorrect!
Some of these blunders can be classified as clumsy design rather than as mere sloppiness. A good example is Windows' long filename support. In an attempt to allow for long filenames, Microsoft deliberately broke the FAT file system. They stored the extension information into deliberately cross-linked directory entries, which is probably one of their dirtiest kludges ever. And if that wasn't enough, they made it legal for filenames to contain whitespace. Because this is incompatible with Windows' own command line parsing (it still assumes the old FAT notation) another kludge was needed, and whitespace had to be enclosed in quotation marks. This confuses (and breaks) many programs, including many of Microsoft's own that come with Windows.
Another good example is Windows' apparent case-sensitivity. Windows seems to make a distinction between upper and lower case when handling filenames, but the underlying software layers are in fact case-insensitive. So Windows only changes the case of the files and directories as they are presented to the user. The names of the actual files and directories may be stored in uppercase, lowercase or mixed case, while they are still presented as capitalized lower case files. Of course this discrepancy causes no problems in a Windows-only environment. Since the underlying code is essentially case-insensitive, case is not critical to Windows' operation. However as soon as you want to incorporate Unix-based services (e.g. a Unix-based webserver instead of IIS) you discover that Windows has messed up the case of filenames and directories.
But most of Windows' errors and glitches are just the result of sloppy work. Of course there is no such thing as bug-free software, but the amount of bugs found in Windows is, to put it mildly, disproportionate. For example, Service Pack 4 for Windows NT 4.0 attempted to fix some 1200 bugs (yes, one thousand two hundred). But there had already been three previous service packs at the time! Microsoft shamelessly admitted this, and even boasted about having "improved" NT on 1200 points. Then they had to release several more subsequent service packs in the months that followed, to fix remaining issues and of course the additional problems that had been introduced by the service packs themselves.
An internal memo among Microsoft developers mentioned 63,000 (yes: sixty-three thousand) known defects in the initial Windows 2000 release. Keith White, Windows Marketing Director, did not deny the existence of the document, but claimed that the statements therein were made in order to "motivate the Windows development team". He went on to state that "Windows 2000 is the most reliable Windows so far." Yes, that's what he said. A product with 63,000 known defects (mind you, that's only the known defects) and he admits it's the best they can do. Ye gods.

All these blunders have of course their effects on Windows' reliability and availability. Depending on application and system load, most Windows systems tend to need frequent rebooting, either to fix problems or on a regular basis to prevent performance degradation as a result of Windows' shaky resource management.
On the desktop this is bad enough, but the same flaws exist in the Windows server products. Servers are much more likely to be used for mission-critical applications than workstations are, so Windows' limited availability and its impact on business become a major issue. The uptimes of typical Windows-based servers in serious applications (i.e. more than just file and print services for a few workstations) tend to be limited to a few weeks at most. One or two server crashes (read: interruptions of business and loss of data) every few months are not uncommon. As a server OS, Windows clearly lacks reliability.
Windows server products aren't even really server OSes. Their architecture is no different from the workstation versions. The server and workstation kernels in NT are identical, and changing two registry keys is enough to convince a workstation that it's a server. Networking capabilities are still largely based on the peer-to-peer method that was part of Windows for Workgroups 3.11 and that Microsoft copied, after it had been successfully pioneered by Apple and others in the mid-eighties. Of course some code in the server products has been extended or optimized for performance, and domain-based authentication has been added, but that doesn't make it a true server platform. Neither does the fact that NT Server costs almost three times as much as NT Workstation. In fact we're talking about little more than Windows for Workgroups on steroids.
In November 1999, Sm@rt Reseller's Steven J. Vaughan-Nichols ran a test to compare the stability of Windows NT Server (presumably running Microsoft Internet Information Server) with that of the Open Source Linux operating system (running Samba and Apache). He wrote:

Conventional wisdom says Linux is incredibly stable. Always skeptical, we decided to put that claim to the test over a 10-month period. In our test, we ran Caldera Systems OpenLinux, Red Hat Linux, and Windows NT Server 4.0 with Service Pack 3 on duplicate 100MHz Pentium systems with 64MB of memory. Ever since we first booted up our test systems in January, network requests have been sent to each server in parallel for standard Internet, file and print services. The results were quite revealing. Our NT server crashed an average of once every six weeks. Each failure took roughly 30 minutes to fix. That's not so bad, until you consider that neither Linux server ever went down.

Interesting: a crash that takes 30 minutes to fix means that something critical has been damaged and needs to be repaired or restored. At least it takes more than just a reboot. This happens once every six weeks on a server, and that's considered "not so bad"... Think about it. Also note that most other Unix flavors such as Solaris, BSD or AIX are just as reliable as Linux.
But the gap between Windows and real uptime figures is even greater than Vaughan-Nichols describes above. Compare that half hour downtime per six weeks to that of Netware, in the following article from Techweb on 9 April 2001:

Server 54, Where Are You?
The University of North Carolina has finally found a network server that, although missing for four years, hasn't missed a packet in all that time. Try as they might, university administrators couldn't find the server. Working with Novell Inc. (stock: NOVL), IT workers tracked it down by meticulously following cable until they literally ran into a wall. The server had been mistakenly sealed behind drywall by maintenance workers.

Although there is some doubt as to the actual truth of this story, it's a known fact that Netware servers are capable of years of uninterrupted service. I recently brought down a Netware server at our head office. This is a Netware 5.0 server that also runs software to act as the corporate SMTP/POP3 server, fax server and virus protection for the network, next to regular file and print services for the whole company. It had been up and running without a single glitch for more than a year, and the only reason we shut it down was because it had to be physically moved to another building. Had the move not been necessary, it could have run on for years and years - after all there's no reason why its performance should be affected, as long as nobody pulls the plug or rashly loads untested software. The uptimes of our Linux and Solaris servers (which act as mission-critical web servers, database servers and mail servers, and also run basic file and print services) are measured in months as well. Uptimes in excess of a year are not uncommon for Netware and Unix platforms, and uptimes of more than two years are not unheard of either. Most OS updates short of a kernel replacement do not require a Unix server to reboot, as opposed to Windows that needs a complete server reboot whenever a DLL in some subsystem is replaced. But see for yourself: check the Netcraft Uptime statistics and compare the uptimes of Windows servers to those of Unix servers. The figures speak for themselves.
Microsoft promises 99.999% availability with Windows 2000. That's a little over 5 minutes of downtime per year. Frankly I can't believe this is a realistic target for Windows. Microsoft products have never even approached such uptime figures. Even though most of the increased availability of Windows 2000 must be provided through third-party clustering and redundancy solutions (something that the glossy ads neglect to mention) it's highly unlikely that less than five minutes of downtime per year for the entire Windows cluster is practically feasible.
Perhaps even more serious is the fact that, short of clustering, there is no adequate solution for the many software glitches that jeopardize the availability of a typical Windows server. A typical NT or 2000 server can spontaneously develop numerous transient problems. These may vary from network processes that seem healthy but ignore all network requests, to runaway server applications that lock up the entire operating system. Usually the only solution in these cases is to power cycle and restart the system. I remember having to do that three times a week on a production server. Believe me, it's no fun. Perhaps it's understandable that some network administrators feel that the best way to accelerate a Windows system is at 9.81 meters per second squared.

Does this make Windows an entirely unusable product that cannot run in a stable configuration anywhere? No, fortunately not. There are situations where Windows systems (both workstations and servers) may run for long periods without crashing. A vendor-installed version of Windows NT of 2000 on an HCL-compliant, A-brand system, with all the required service packs and only certified drivers, should give you relatively few problems (provided that you don't use it for much more than basic file and print services, of course). The rule of thumb here is to use only hardware that is on Microsoft's Hardware Compatibility List (HCL), to use only vendor-supplied, certified drivers and other software, and to use third-party clustering solutions for applications where availability is a critical issue.
To be honest, Windows 2000 is somewhat better (or rather less bad) than NT4 was. It's less prone to spontaneous crashes and some of NT's most awkward design blunders have been fixed. (For example, the user home directories are no longer located under the WINNT directory.) On most systems (especially on notebook computers) it is considerably less shaky. Which goes to show that a few relatively minor improvements go a long way, I suppose. But still, given the general quality of Microsoft products and Windows in particular, there are absolutely no guarantees. And of course Microsoft introduced a whole new set of glitches and bugs in Windows XP, which largely undid many of the improvements in Windows 2000, so that Windows XP is less stable than Windows 2000. But that's innovation for you, I suppose.

The most frightening aspect about all this is that Microsoft doesn't seem to realize how serious these problems are. Or rather, they probably realize it but they don't seem to care as long as sales hold up. Their documents on serious problems (which are always called 'Issues' in Microsoft-speak) are very clear on that point. Take the 'TCP/IP Denial Of Service Issue' for example: a serious problem that was discovered a few years ago. It caused NT servers to stop responding to network service requests, thus rendering mission-critical services unavailable. (This should not be confused with deliberate Denial Of Service attacks to which most operating systems are vulnerable; this was a Windows issue only.) At the time there was no real solution for this problem. Microsoft's only response at the time was to state that "This issue does not compromise sensitive data in any way. It merely forces a server to become unavailable for a short time, which is easily remedied by rebooting the server." (NT administrators had to wait for the next service pack that was released several months later before this problem was addressed.)
And Microsoft thinks that this stuff can compete with Unix and threaten the mainframe market for mission-critical applications?
Uh-huh.
I don't think so.
In September 2001 Hewlett-Packard clustered 225 PCs running the Open Source Linux operating system. The resulting system (called I-cluster) benchmarked itself right into the global top-500 of supercomputers, using nothing but unmodified, out-of-the-box hardware. (A significant number of entries in that top-500, by the way, runs Linux, and more and more Unix clusters are being used for supercomputing applications.) Microsoft, with a product line that is descended solely from single-user desktop systems, can't even dream of such scalability - not now, not ever. Nevertheless Microsoft claimed on a partner website with Unisys that Windows will outperform Unix, because Unisys' server with Windows 2000 Datacenter could be scaled up to 32 CPU's. This performance claim is of course a blatant lie: the opposite is true and they know it. Still Microsoft would have us believe that the performance, reliability and scalability of the entire Windows product line is on par with that of Unix, and that clustered Windows servers are a viable replacement option for mainframes and Unix midrange systems. I'm not kidding, that's what they say. If you're at all familiar with the scalability of Unix midrange servers and the requirements of the applications that mainframes are being used for, you will realize how ludicrous this is. And if you're not, consider this: when Microsoft acquired the successful Hotmail free Email service, the system had roughly 10 million users, and the core systems that powered Hotmail all ran Unix. Today the number of Hotmail users exceeds 50 million, but in spite of Microsoft's claims about the power of Windows servers and their previous intentions to replace Hotmail's core systems with NT servers, Hotmail's core systems still run Unix. This is discussed thoroughly in a leaked-out internal paper by Microsoft's Windows 2000 Server Product Group member David Brooks. He mentions the proverbial stability of the Unix kernel and the Apache web server, the system's transparency and combination of power and simplicity. Windows on the other hand is considered to be needlessly GUI-biased (Brooks writes: "Windows 2000 server products continue to be designed with the desktop in mind") and also complex, obscure, needlessly resource-hungry (Brooks: "It's true that Windows requires a more powerful computer than Linux or FreeBSD") and involving "reboot as an expectation" (sic).
Of course Hotmail is not the only example of Microsoft refusing to eat their own dog food. The "We have the way out" anti-Unix website that Microsoft (along with partner Unisys) put up in the first months of 2002, initially ran Unix and Apache (and was ported to IIS on Windows 2000 only after the entire ICT community had had a good laugh). And Microsoft's own accounting division used IBM's AS/400 midrange platform for critical applications such as the payroll system, until the late nineties. Food for thought.

It should also be mentioned that Microsoft doesn't know the first thing about networking. A Windows system in a TCP/IP environment still uses a NetBIOS name. Microsoft networking is built around NetBEUI, which is an extended version of NetBIOS. This is a true Stone Age protocol which is totally unroutable. It uses lots of broadcasts, and on a network segment with Windows PCs broadcasts indeed make up a significant portion of the network traffic, even for point-to-point connections (e.g. between a Microsoft mailbox and a client PC). If it weren't for the fact that it is possible to encapsulate NetBIOS/NetBEUI traffic in a TCP/IP envelope, connecting Windows to the real world would be totally impossible. (Note that Microsoft calls the IP encapsulation of NetBEUI packets 'native IP'. Go figure.)
In any case Windows PCs tend to generate an inordinate amount of garbage on the network. I remember reading a document from Microsoft that stated that a typical PC network consists of ten or at most twenty peer-to-peer workstations on a single cable segment, all running Microsoft operating systems. And that explains it, I suppose. If you want anything more than that, on your own head be it.
BTW: don't believe me -- try for yourself. Take a good, fast FTP server (i.e. one that runs on Unix). Upload and download a few large files (say, 50MB) from and to a Windows NT or 2000 workstation. (I used a 233MHz Pentium-II.) You will probably see a throughput in the order of 1 Mbit/s for uploads and 2 to 3 Mbit/s for downloads. Then boot Linux on the same workstation and repeat. You will now see your throughput limited only by the bandwidth or your network connection or by the capacity of your FTP server, whichever comes first. On 10 Mbit/s Ethernet, 5 Mbit/s upload and download throughput are the least you may expect. To further test this, you can repeat it with a really slow client (e.g. a 60 or 75MHz Pentium) running Linux. The throughput limit will still be network-bound and not system-bound. (Note: this is not limited to FTP but also affects other network protocols. It's a performance problem related to the code in Windows' IP stack and other parts of the architecture involved with data throughput.)
New Windows versions bring no relief here. Any network engineer who uses PPPoE (Point-to-Point Protocol over Ethernet) with ADSL will tell you that the MTU (a setting that limits packet size) should be set to 1492 or less. In XP it's set by default to 1500, which may lead to problems with the routers of many DSL ISP's. Microsoft is aware of the problem, but XP nevertheless persists in setting up PPPoE with an MTU of 1500. There is a registry hack for PPPoE users, but there is no patch, and XP has no GUI-based option which enables the user to change the MTU conveniently. (This problem is rather typical for XP. Previous versions of Windows needed third party code to support such features. This was inconvenient, but at least there was a chance to obtain code written by developers who knew what they were doing. In Windows XP Microsoft insisted on doing the job themselves, and botched it.)
On top of all this, readers of this paper report that according to John Dvorak in PC Magazine, the Windows kernel maxes out at 483 Mbps. He remarks that as many businesses are upgrading to 1 Gigabit Ethernet, Windows (including XP) just can't keep up.
Now go read what Microsoft writes about Windows 2000 and XP being the ideal platform for Internet applications...
The sloppy nature of Windows' networking support code and protocol stacks also makes the system more vulnerable to Denial of Service attacks. A DoS attack is nothing but a form of computer vandalism, with the intention to crash a system or otherwise render it unavailable. In a typical DoS attack a deliberately malformed network packet is sent to the target system, where it triggers a known flaw in the operating system to disrupt it. In the case of Windows, though, there are more ways to bring down a system. For example, the kernel routines in Windows 2000 and XP that process incoming IPsec (UDP port 500) packets are written so badly that sending a stream of regular IPsec packets to the server will cause it to bog down in a CPU overload. And of course Windows' IPsec filters cannot block a 500/udp packet stream.
Another way to render a system unavailable is a Distributed Denial of Service attack. A DDoS attack involves many networked systems that send network traffic to a single target system or network segment, which is then swamped with traffic and becomes unreachable. There's very little that can be done against DDoS attacks, and all platforms are equally vulnerable.
With all these DoS and DDoS vulnerabilities, it's a worrying development that Windows 2000 and XP provide new platforms to generate such attacks. The only real 'improvement' in Windows 2000's and XP's IP stacks is that for no good reason whatsoever, Microsoft has extended the control that an application has over the IP stack. This does not improve Windows' sub-standard networking performance, but it gives applications the option to build custom IP packets to generate incredibly malicious Internet traffic. This includes spoofed source IP addresses and SYN-flooding full scale Denial of Service (DoS) attacks.

So far we have concentrated on Windows. Most of the problems with Microsoft products originate here, since Windows is by far the most complex Microsoft product line, and there are more interactions between Windows and other products than anywhere else. But unfortunately most server and desktop applications are cut from the same cloth as Windows is. The general quality of their code and design is not much better.
The additional server products generally run on a Windows server. This means that all the disadvantages of an insecure, unstable platform also apply to the server products that run on those servers. For example, Microsoft SQL Server is a product that has relatively few problems. It's basically a straightforward implementation of a general SQL server. It's not very remarkable or innovative perhaps, but it's not a bad product as far as it goes, certainly not by Microsoft standards. But any database service can never be more stable than the platform it's running on. (This goes of course for any software product, not just for an SQL database server.) So all vulnerabilities that apply to the Windows server directly apply to the database service as well.
Other additional server products come with their own additional problems, though. Microsoft's webserver product, Internet Information Server (IIS), is designed not just to serve up web pages written in the standard HTML language, but also to provide additional authentication and links to content databases, to add server and client side scripting to web pages, to generate Dynamic HTML and Active Server Pages, et cetera. And it does all these things, and more, but often not very well. IIS is outperformed by all other major webserver products (especially Apache). IIS' authentication is far from robust (the lack of security in MS products is discussed below) and the integration of an IIS webserver with a content database server is far from seamless. Dynamic HTML, ASP and scripting require the webserver to execute code at the server end, and there Microsoft's bad process management comes into play: server load is often excessive. Running code at the server end in response to web requests creates a lot of security issues as well, and on top of all that the web pages that are generated do not conform to the global HTML standards, they are only viewed correctly in Microsoft's own web browser products.
Microsoft's mail server product, Exchange, has a few sharp edges as well. To lose a few days worth of corporate E-mail in an Exchange crash is not uncommon. Exchange is designed to integrate primarily with other Microsoft products (especially the Outlook E-mail client) and it doesn't take the Internet's global RFC standards too seriously. This limits compatibility and may cause all kinds of problems. Outlook Express also has a strange way of talking IMAP to the Exchange server. It makes a bazillion IMAP connections; each connection logs in, performs one task, sets the connection to IDLE-- and then drops the connection. Since OE does not always close the mailbox properly before dropping the connection, the mailbox and Outlook do not necessarily sync up. This means that you may delete messages in OE that magically return to life in a few minutes because those deletions did not get disseminated to the mailbox before the connection terminated.
Just like other Microsoft applications, the additional server products are tightly integrated into Windows during installation. They replace DLLs belonging to the operating system, and they run services at the system level. This does not improve the stability of the system as a whole to begin with, and of course most of the code in the additional server products is of the same doubtful quality as the code that makes up Windows. The reliability and availability of any service can never be better than the server OS it runs on. However most of Microsoft's additional server products add their own complexity, bugs and glitches to the system, which only makes it worse. The resulting uptime and reliability figures are rather predictable. The inefficiency that exists in Windows is also present in the additional server products, so as a rule of thumb each additional service needs its own server platform. In other words: if you need a file and print server, a web server and a mail server, you need three separate systems whereas Unix or Netware could probably do the job on only one system.

Microsoft desktop applications (like Word and Excel) are largely more of the same. They're in the terminal stages of feature bloat: they're full of gadgets that don't really add anything useful to the product, but that ruin productivity because of their complexity, and that introduce more errors, increase resource demands, and require more code which in turn leads to increased risks. After years of patching and adding, the code base for these products has become very messy indeed. Security, if any, has been added as an afterthought here, too. For example, a password-protected Word document is not encrypted in any way. Inserting a 'protected' document into another non-protected document (e.g. an empty new document) is enough to get around the 'protection'.
Animated paper clips don't really make Word a better word processor. We'd be better off with other things, such as a consistent behavior of the auto-format features, the ability to view markup codes, or a more complete spell checking algorithm and dictionary. But in spite of all the "new" versions of Office and persistent feature requests from their users, Microsoft still hasn't gotten around to that. Instead we have multi-language support that tends to 'forget' its settings occasionally, and an 'auto-correct' feature that's limited to the point of being more annoying than useful. Word documents have become excessively large and unwieldy, and occasionally they are corrupted while being saved to disk so that Word will crash while trying to read them at a later time.
We can be brief about Excel: it has similar problems, and calculation errors in formula-based spreadsheets on top of that. Excel is full of frills and spiffy graphics and animations, but essentially it's still a spreadsheet that cannot count and that requires that many formulas and macros be rewritten for each new version of Excel.
Menu interfaces in all Microsoft applications, even in those that are bundled in MS Office, are inconsistent and non-intuitive. For example, the menu option to set application preferences, which may be titled 'Preferences' in some products but 'Options' in others, may be found under the 'File' menu, under the 'Edit' menu, under 'View' or somewhere else, depending on what product you're currently using. To create even more confusion, the same options in different applications do not work identically. For example the 'Unsorted list' button (to create a bullet list) handles indentation correctly in Word but ignores it completely in PowerPoint (PowerPoint adds bullets but messes up the left outline of the text). And the 'F3' key activates the 'search again' function for string searches in practically all Microsoft products, except in Internet Explorer where it brings up a 'Find: all files' window for no apparent reason.

Microsoft's most important application outside MS Office is without doubt Internet Explorer. In its first incarnation IE was a very unremarkable web browser; e.g. version 2.0 as it was shipped with Windows NT 4 was so backward that it didn't even have frame capability. This soon changed as Microsoft began integrating the web browser with Windows as a part of their integration and bundling strategies (which are discussed in detail below).
In all honesty it must be said that recent versions of IE (starting with version 6) aren't bad web browsers. They do what they're supposed to do, and they do it pretty well. At least they display standards-compliant HTML as correctly rendered web pages at a speed that is by all means acceptable. Previous versions weren't so good and even contained deliberate deviations from the global HTML standards that were intended to discourage the use of standardized HTML in favor of Microsoft's own proprietary and restrictive ideas.
The main drawbacks of Internet Explorer lie in the fact that it tries to be more than just a web browser. It adds scripting support (with the ability to run Visual Basic or Jscripts that are embedded in web pages) and it hooks directly into the Windows kernel. I've seen web pages that would shut down the Windows system as soon as the page was viewed with Internet Explorer. Microsoft doesn't seem to have bothered very much with basic security considerations, to put it mildly. And of course the installation of a new version of Internet Explorer replaces (overwrites) significant portions of the Windows operating system, with all the drawbacks discussed above.
Similar problems are found in Outlook, Microsoft's E-mail client. Outlook is in fact a separate application, but it isn't shipped separately. There are two versions: one is bundled with Internet Explorer (this version is called Outlook Express) and the other is part of MS-Office (this version is named 'Outlook' and comes with groupware and scheduler capabilities). In itself Outlook is an acceptable, if unremarkable, E-mail client; it allows the user to read and write E-mail. It comes with a few nasty default settings, but at least these can be changed, although the average novice user of course never does that. (For example, messages are by default sent as HTML file attachments instead of as readable text, when a user replies to an E-mail the quoting feature sometimes uses weird formatting that won't go away without dynamite, and there's often a lot of junk that accompanies an outgoing E-mail message.) More serious is the fact that both Outlook and its server-end companion Exchange tend to strip fields from E-mail headers, a practice that is largely frowned upon. This also makes both network administration and troubleshooting more difficult.
Outlook comes with a lot of hooks into Internet Explorer. IE code is being used to render HTML file attachments, including scripts that may be embedded into an HTML-formatted E-mail message. Again Microsoft seems to have been completely unaware of the need for any security here; code embedded in inbound E-mail is by default executed without any further checking or intervention from the user.

And that brings us to another major weakness of all Microsoft products: security, or rather the lack thereof. The notorious insecurity of Microsoft software is a problem in itself.
It all begins with Windows' rather weak security. The number of reports on security holes has become downright embarrassing, but it still keeps increasing regularly. On the other hand, Windows security holes have become so common that they hardly attract attention anymore. Microsoft usually downplays the latest security issues and releases another patch... after the fact. If Microsoft really wanted to resolve these software problems, they would take greater care to ensure such problems were fixed before its products went on sale-- and thus reverse the way it traditionally conducts business. Doing so would mean less resources wasted by its customers each year patching and re-patching their systems in an attempt to clean up after Microsoft's mistakes, but it would also decrease the customers' dependency on what Microsoft calls 'software maintenance'. In the meantime, hackers are having a ball with Microsoft's shaky security models and even weaker password encryption (such as simple XOR bitflip operations, the kind of 'encryption' that just about every student reinvents in school). Hackers, script kiddies and other wannabees get to take their pick from the wide choice of elementary security weaknesses to exploit. Some recent and highly virulent worms, for example, spread so rapidly because they could crack remote share passwords in about twenty seconds. (This did not stop Microsoft from running an advertising campaign in spring 2003 that centered on hackers becoming extinct along with the dodo and the dinosaur, all because of Microsoft's oh so secure software. Unsurprisingly, this violated a few regulations on truth in advertising, and the campaign had to be withdrawn.)
Another large part of the problem is Windows' lack of adequate separation between code running on various system and user levels. Windows always assumes that code runs with the highest privilege so that it can do almost anything, including malicious intent. This makes it impossible to prevent malicious code from invading the system. Users may (inadvertantly or deliberately) download and run code from the Internet, but it's impossible to prevent system level resources from damage by user level code.
The tight integration between the various Microsoft products does little to improve overall security. All software components are loaded with features, and all components can use each other's functions. Unfortunately this means that all security weaknesses are shared as well.
For example, the Outlook E-mail client uses portions of Internet Explorer to render HTML that is embedded in E-mail messages, including script code. And of course IE and Outlook hook into the Windows kernel with enough privileges to run arbitrary malicious code that happens to be embedded in a received E-mail message or a viewed web page. Since Outlook uses portions of IE's code, it's vulnerable to IE's bugs as well. So a scripting vulnerability that exists in Outlook also opens up IE and vice versa, and if IE has a hook into certain Windows kernel functions, those functions can also be exploited through a weakness in Outlook. In other words, a minor security leak in one of the components immediately puts the entire system at risk. Read: a vulnerability in Internet Explorer means a vulnerability in Windows Server 2003! A simple Visual Basic script in an E-mail message has sufficient access rights to overwrite half the planet, as has been proven by Email virus outbreaks (e.g. Melissa, ILOVEYOU and similar worms) that have caused billions of dollars worth of damage.
A good example are Word viruses; these are essentially VBS (Visual Basic Script) routines that are embedded in Word documents as a macro. The creation of a relatively simple macro requires more programming skills than the average office employee can be expected to have, but at the same time a total lack of even basic security features makes Word users vulnerable to malicious code in Word documents. Because of the integrated nature of the software components, a Word macro is able to read Outlook's E-mail address book and then propagate itself through the system's E-mail and/or networking components. If Windows' security settings prevent this, the malicious virus code can easily circumvent this protective measure by the simple expedient of changing the security settings. How's that for security?
Similarly, VBS scripts embedded in web pages or E-mail messages may exploit weaknesses in IE or Outlook, so that viewing an infected web page or receiving an infected E-mail is enough to corrupt the system without any further action from the user (including manually downloading a file or opening an attachment). Through those weaknesses the malicious code may access data elsewhere on the system, modify the system's configuration or even start processes. In March 2000, a hacker wrote (of course anonymously) on ICQ:

21/03/2k: Found the 1st Weakness: In Windows 2000 [...] there is a Telnet daemon service, which is not started by default. It can be remotely started by embedding a COM object into HTML code that can be posted on a web page, or sent to an Outlook client. Following script will start the Telnet service:
<SCRIPT LANGUAGE=VBScript> CreateObject("TlntSvr.EnumTelnetClientsSvr")</SCRIPT>
We've tried it and it really works. Only a Problem... we've put it into a html page. When opening the page... our best friend "IE5" shows an alert msg saying that "you're going to run some commands that can be dangerous to your PC...Continue?" We must fix it! No problem using Outlook... [sic]

It's interesting to note that after patching no less than seven different security holes in the Windows 2000 telnet code (yes, that's seven security leaks in telnet alone!) Microsoft released another patch in February 2002, to fix security issue number eight: another buffer overflow vulnerability. Somehow I don't think this patch will be the last. If you don't succeed at first, try seven more times, try, try (and try some more) again.
It's not surprising that J.S. Wurzler Underwriting Managers, one of the first companies to offer hacker insurance, have begun charging clients 5 to 15 percent more if they use Microsoft's Windows NT software in their Internet operations.
Microsoft knows exactly how bad their own product security is. Nevertheless they wax lyrical about new features rather than accept their responsibility for their actions. To quote Tom Lehrer:

"The rockets go up,
who cares where they come down?
That's not my department,
says Werner von Braun."

Microsoft can't be unaware of the risks and damages they cause. They have relied on a third-party product to secure their own mail servers for many years. They always claimed to use Exchange for their own corporate E-mail, but neglected to mention they were using Interscan Viruswall NT (by Trend Micro, Inc.) to provide the essential security that Microsoft's own products lacked. Another interesting detail is that the Microsoft servers were still running Viruswall version 3.24 in the summer of 2001. This is a version for NT that is not Windows 2000 'ready'. In other words, Microsoft had prudently decided not to run Windows and Exchange 2000 on their own mail servers yet. Only by the end of 2001 Microsoft had migrated to Windows and Exchange 2000 themselves.
This is not the only example of Microsoft's lack of trust in their own products. Microsoft's SQL Labs, the part of the company that works on Microsoft's SQL Server, is using NetScreen's 500-series security appliance to defend its network against Code Red, Nimda and other worm attacks. Apparently, the labs' choice was made despite the fact that Microsoft already sells its own security product touted as a defense against worms. The Microsoft ISA [Internet Security and Acceleration] Server was introduced in early 2001 and was hailed by Microsoft as their first product aimed entirely at the security market. In fact, the most important reason businesses ought to switch to ISA Server, according to Microsoft, was that "ISA Server is an [...] enterprise firewall and secure application gateway designed to protect the enterprise network from hacker intrusion and malicious worms". Still Microsoft's SQL Labs prudently decided to rely on other products than their own to provide basic security.

And it gets even better, because of the sloppy code found in many Microsoft products. The many buffer overrun vulnerabilities can be combined with scripting weaknesses. You don't need to open E-mail attachments or even read an incoming E-mail message to risk the introduction of malicious code on your system. Just receiving the code (e.g. downloading E-mail from a POP3 server or viewing a web page) is enough. Yes, I know, stories like this have long been urban legend, but Outlook has made it reality. Microsoft explains: "The vulnerability results because a component used by both Outlook and Outlook Express contains an unchecked buffer in the module that interprets E-mail header fields when certain E-mail protocols are used to download mail from the mail server. This could allow a malicious user to send an E-mail that, when retrieved from the server using an affected product, could cause code of his choice to run on the recipient's computer." This vulnerability has been successfully exploited by Nimda and other malicious worm programs. Other worm programs (e.g. Code Red) combine vulnerabilities like this with creatively constructed URL's that trigger buffer overruns in IIS. Even without the Frontpage extensions installed it is relatively easy to obtain unencrypted administration passwords and non-public files and documents from an IIS webserver. Furthermore, this "E-commerce solution of the future" contains a prank (a hardcoded passphrase deriding Netscape developers as "weenies") in the code section concerned with the access verification mechanism for the whole system. And there are many more weaknesses like this. The list goes on and on and on.
IIS is supposed to power multi-million dollar E-commerce sites, and it has many backend features to accomplish this application. But each and every time we hear about a large online mailorder or E-commerce website that has spilled confidential user data (including credit card numbers) it turns out that that website runs IIS on Windows NT or 2000. (And that goes for adult mailorder houses too. I'm not quite sure what kind of toy a Tarzan II MultiSpeed Deluxe is, but I can probably tell you who bought one, and to which address it was shipped. Many E-commerce websites promise you security and discretion, but if they run IIS they can only promise you good intentions and nothing more. Think before you order...)

The Code Red and Nimda worms provided a nice and instructive demonstration of how easy it is to infect servers running IIS and other Microsoft products, and use them for malicious purposes (i.e. the spreading of malicious code and DDoS attacks on a global scale). Anyone who bothers to exploit one of the many documented vulnerabilities can do this. Some of the vulnerabilities exploited by Code Red and Nimda were months old, but many administrators just can't keep up with the ridiculous amount of patches required by IIS. Nor is patching always a solution: the patch that Microsoft released to counter Nimda contained bugs that left mission-critical IIS production servers non-operational.
On 20 June 2001, Gartner vice president and analyst John Pescatore wrote:

IIS security vulnerabilities are not even newsworthy anymore as they are discovered almost weekly. This latest bug echoes the very first reported Windows 2000 security vulnerability in the Indexing Service, an add-on component in Windows NT Server incorporated into the code base of Windows 2000. As Gartner warned in 1999, pulling complex application software into operating system software represents a substantial security risk. More lines of code mean more complexity, which means more security bugs. Worse yet, it often means that fixing one security bug will cause one or more new security bugs.
The fact that the beta version of Windows XP also contains this vulnerability raises serious concerns about whether XP will show any security improvement over Windows 2000.

On 19 September 2001, Pescatore continued:

Code Red also showed how easy it is to attack IIS Web servers [...] Thus, using Internet-exposed IIS Web servers securely has a high cost of ownership. Enterprises using Microsoft's IIS Web server software have to update every IIS server with every Microsoft security patch that comes out - almost weekly. However, Nimda (and to a lesser degree Code Blue) has again shown the high risk of using IIS and the effort involved in keeping up with Microsoft's frequent security patches.
Gartner recommends that enterprises hit by both Code Red and Nimda immediately investigate alternatives to IIS, including moving Web applications to Web server software from other vendors, such as iPlanet and Apache. Although these Web servers have required some security patches, they have much better security records than IIS and are not under active attack by the vast number of virus and worm writers. Gartner remains concerned that viruses and worms will continue to attack IIS until Microsoft has released a completely rewritten, thoroughly and publicly tested, new release of IIS. Sufficient operational testing should follow to ensure that the initial wave of security vulnerabilities every software product experiences has been uncovered and fixed. This move should include any Microsoft .NET Web services, which requires the use of IIS. Gartner believes that this rewriting will not occur before year-end 2002 (0.8 probability).

In all honesty it must be said that Microsoft has learned to react generally well to newly discovered security holes. Although the severity of many security problems is often downplayed and the underlying cause (flawed or absent security models) is glossed over, information and patches are generally released promptly and are available to the user community without cost. This is commendable. But then the procedure has become routine for Microsoft, since new leaks are discovered literally several times a week, and plugging leaks has become part of Microsoft's core business. The flood of patches has become so great that it's almost impossible to keep up with it. This is illustrated by the fact that most of today's security breaches successfully exploit leaks for which patches have already been released. In fact the sheer volume of patchwork eventually became sufficient to justify the automated distribution of patches. For recent versions of Windows there is an automatic service to notify the user of required "critical updates" (read: security patches) which may then be downloaded with a single mouseclick. This service (which does work fairly well) has become very popular. And for good reason: in the year 2000 alone MS released about 100 (yes, one hundred) security bulletins - that's an average of one newly discovered security-related issue every three to four days!. The number of holes in Microsoft products would put a Swiss cheese to shame. And the pace has increased rather than slowed down. For example, once you install a "recommended update" (such as Media Player 7.1) through the Windows Update service, you discover immediately afterward that you must repeat the whole exercise in order to install a "critical update" to patch the new security leaks that were introduced with the first download! It's hardly reasonable to expect users to keep up with such a rat race, and not surprising that most users can't. As a result, many E-mail viruses and worms exploit security holes that are months or years old. The MSBlaster worm that spread in the summer of 2003 managed to infect Windows Server 2003 using a vulnerability that was already present in NT4! In an age where smokers sue the tobacco industry for millions of dollars, all Microsoft products had better come with a warning on the package, stating that "This insecure product will cause expensive damage to your ICT infrastructure unless you update frequently and allocate time every day to find, download and install the patch-du-jour". Unfortunately they don't, and Windows-based macro and script viruses emerged at a rate of 200 to 300 a month in 2002.
An interesting side effect of the ridiculous rate with which patches need to be released, is that some users now get the impression that Microsoft takes software maintenance very seriously and that they are constantly working to improve their products. This is of course rather naive. If they'd bought a car that needed serious maintenance or repairs every two weeks or so, they probably wouldn't feel that way about their car manufacturer.
And of course no amount of patching can possibly remedy the structural design flaws in (or absence of) Microsoft products' security. A patch is like a band-aid: it will help to heal a simple cut or abrasion, but for a broken leg or a genetic deficiency it's useless, even if you apply a few thousand of them. The obvious weak point in the system is of course integration. Microsoft likes to call Windows "feature-rich" but when they have to release an advisory on a serious vulnerability involving MIDI files it becomes obvious that the set of features integrated in Windows has long since passed the point of maximum usefulness.
Lately Microsoft lobbyists are trying to promote the idea that free communication about newly discovered security leaks is not in the interest of the user community, since public knowledge of the many weaknesses in their products would enable and even encourage malicious hackers to exploit those leaks. Microsoft's Security Response Center spokesman Scott Culp blamed security experts for the outbreak of worms like Code Red and Nimda, and in an article on Microsoft's website in October 2001 he proposed to restrict circulation of security-related information to "select circles". And it's all for our own good, of course. After all, censorship is such a nasty word.
In August 2002, during a court hearing discussing a settlement between Microsoft and the DoJ, Windows OS chief Jim Allchin testified how cover-ups are Microsoft's preferred (and recommended) course of action:

"There is a protocol dealing with software functionality in Windows called message queueing, and there is a mistake in that protocol. And that mistake, if we disclosed it, would in my opinion compromise a company who is using that particular protocol."

In the meantime things are only getting worse with the lack of security in Microsoft products. The latest incarnation of Office (Office XP) provides full VBA support for Outlook, while CryptoAPI provides encryption for messages and documents, including VBS attaches and macro's. In other words, anti-virus software will no longer be able to detect and intercept viruses that come with E-mail and Word documents, rendering companies completely defenseless against virus attacks.
Clearly this is a recipe for disaster. It's like a car manufacturer who floods the market with cars without brakes.
Another worrying development is that leaky code from products such as IIS or other products is often installed with other software (and even with Windows XP) without the system administrators being aware of it. For example: SQL Server 2000 introduced 'super sockets' support for data access via the Dnetlib DLL. It provides multi-protocol connectivity, encryption, and authentication; in other words a roll-up of the different implementations of these technologies in past versions of the product. A system would only have this DLL if SQL Server 2000, the client administration tools, MSDE, or a vendor-specific solution was installed on the box. However, with XP this DLL is part of the default installation-- even on the home edition. One has to wonder how a component goes from "installed only in specialized machines on a particular platform" to "installed by default on all flavors of the OS." What other components and vulnerabilities are now automatically installed that we don't know about?
And the Windows fileset is getting extremely cluttered as it is. Looking through the WINNT directory on a Windows 2000 or XP system, you'll find lots of legacy executables that are obsolete and never used: Media Player 5, 16-bit legacy code from previous Windows versions as far back as version 3.10 (in fact the bulk of the original Windows 3.10 executable code is there), files that belong to features that are never used in most cases (e.g. RAS support) or accessibility options that most users fortunately don't need (such as the Narrator and Onscreen Keyboard features). Dormant code means possible dormant security issues. The needless installation of such a roundup reflects the laziness of Microsoft's developers: if you just install everything but the kitchen sink, you can just assume it's there at a later time and not bother with the proper verifications. Of course this practice doesn't improve quality control at all, it merely adds to the bloat that has plagued Windows from day one.

The future promises only more of the same. Since Microsoft is already working on the next versions of Windows, maybe to be released in 2003, it seems a safe assumption that we're stuck with the current flawed Windows architecture and that no structural improvements are to be expected. So far Microsoft has never seemed interested in cleaning up their architectures. Instead they concentrate on finding workarounds.
A good example is Microsoft's recommendation that PCs "designed for Windows XP" no longer accept expansion cards but only work with USB peripherals. This clearly indicates that XP still suffers from the architecture-related driver problems that have caused so many Windows crashes in the past. In an attempt to get rid of the problem, Microsoft tried to persuade PC manufacturers to abandon the PCI expansion bus. The fact that this recommendation was immediately scrapped by the hardware industry is irrelevant; the point is that Microsoft tried to get rid of expansion bus support rather than improve XP's architecture to make it robust.
This doesn't bode well for the future.
A good look at Windows and Windows applications shows that it's virtually impossible for Microsoft to remedy the basic problems with their software. They would have to redevelop their entire product range from scratch. Since robust design and Windows compatibility are mutually exclusive in the foreseeable future, this would mean to give up the limitations that bind the end user to the Microsoft platform. This is commercially unacceptable for Microsoft. In order to maintain revenues, they must hang on to their current software architecture, flaws and all. Lately Microsoft has been making a lot of noise about how they're now going to take security very seriously, but the bad overall quality of their product code makes it impossible to live up to that promise. Their Baseline Security Analyzer (which they released as part of their attempts to improve their image) is a good indication: it doesn't scan for vulnerabilities but merely for missing patches, and it does a sloppy job at that with a lot of false positives as a result.
Another largely empty promise is the so-called ".Net Framework". This is the development environment for the upcoming new .Net product lines. Its most touted 'innovation' is "Zero Impact Install" which proposes to do away with the tight integration between application and operating system. Instead of the current mess of DLL's being inserted into the OS and settings spread throughout an insecure registry database, applications will live in their own subdirectories and be self-contained. Code will be delivered in a cross-platform format and be JIT-compiled (Just In Time) for the platform it runs on. While these things mean a dramatic improvement over the current situation, their innovation factor is of course close to zero: the need for an adequate separation between OS and application code makes sophisticated ICT professionals long for Unix, mainframe environments or even DOS, and JIT-compilation is nothing new either (it wasn't even a new idea when Sun Microsystems proposed Java in the mid-90's). But more importantly: it remains entirely unclear how Microsoft will realize all this. In order to come up with a really good and robust platform, they'd have to replace Windows (and therefore their whole product range) with something that has an essentially different architecture. But .Net is not going to be a ground-up rewrite of Microsoft's OS product line. Such a rewrite would detach Microsoft from their installed base, so compatibility with (and therefore perpetuation of the shortcomings of) existing Windows versions seems unavoidable.
Let's face it: Microsoft's promises about dramatic quality improvement are unrealistic at best, not to say misleading. They're impossible to fulfill in the foreseeable future, and everyone at Microsoft knows it. To illustrate, in January 2002 Bill Gates wrote in his "Trustworthy computing" memo to all Microsoft employees:

"Today, in the developed world, we do not worry about electricity and water services being available. With telephony, we rely both on its availability and its security for conducting highly confidential business transactions without worrying that information about who we call or what we say will be compromised. Computing falls well short of this, ranging from the individual user who isn't willing to add a new application because it might destabilize their system, to a corporation that moves slowly to embrace e-business because today's platforms don't make the grade."

Now, for "today's platforms" read "a decade of Windows, in most cases" and keep in mind that Microsoft won't use their own security products but relies on third party products instead. Add to that the presence of spyware features in Windows Media Player, the fact that Windows XP Home Edition connects to a server called wustat.windows.com, hooks for the Alexa spyware in IE's 'Tools/Show Related Links' feature, and the fact that XP's Search Assistant calls sa.windows.com as soon as you search for information... and the picture is complete. Maybe Big Brother isn't watching you and nothing is being done with the knowledge about what you search for and which websites you visit... but don't count on it. And for those who still don't get it: in November 2002 Microsoft made customer details, along with numerous confidential internal documents, freely available from a very insecure FTP server. This FTP server sported many known vulnerabilities, which made gaining access a trivial exercise. Clearly, Microsoft's recent privacy-concerned and quality-concerned noises sound rather hollow at best. They don't even have any respect for their customers' privacy and security themselves.
Nor is this surprising. Stuart Okin, MS Security Officer for the UK, described security as "a recent issue". During an interview at Microsoft's Tech Ed event in 2002, Okin explained that recent press coverage on viruses and related issues had put security high on Microsoft's agenda. Read: it was never much of an issue, but now it's time to pay lip service to security concerns in order to save public relations. And indeed Microsoft's only real 'improvement' so far has been an advertising campaign that touts Windows XP as the secure platform that protects the corporate user from virus attacks. No, really - that's what they say. They also make a lot of noise about having received "Government-based security certification". In fact this means that Windows 2000 SP3 has met the CCITSE Common Criteria, so that it can be part of government systems without buyers having to get special waivers from the National Security Agency or perform additional testing every time. CC-compliance does not does not mean the software is now secure, but merely means the testing has confirmed the code is working as per specifications. That's all"- the discovery of new security holes at least once a week has nothing to do with it. But even so, Windows 2000 SP3 was the first Microsoft product ever that worked well enough to be CC-certified. Go figure.
As if to make a point, a few weeks after Gates' memo on Trustworthy Computing, Microsoft managed to send the Nimda worm to their own Korean developers, along with the Korean language version of Visual Studio .Net, thus spreading an infection that had originated with the third-party Korean translators. How 'trustworthy' can we expect a company to be, if they aren't even capable of security basics such as adequate virus protection?
And of course since Gates wrote the above memo nothing has changed. Security holes and vulnerabilities in all MS products, many of which allow blackhat hackers to execute arbitrary code on any PC connected to the Internet, continue to be discovered and exploited with a depressing regularity. Microsoft claims to have put 11,000 engineers through security training to solve the problem, but all users of Microsoft products continue to be plagued by security flaws. It's obvious that real improvement won't come around anytime soon. Windows Server 2003 is marketed as "secure by design" but apart from a couple of improved default settings and the Software Restriction Policies not much has changed. Shortly after Windows Server 2003 was released, the first security patch (to plug a vulnerability that existed through Internet Explorer 6) had to be applied, to nobody's surprise.
Since Gates' initial launch of the Trustworthy Computing idea, Microsoft's plans on security have been long on rhetoric and short of actions. Nothing really happened for about 18 months, and then Ballmer made the stunning announcement that the big security initiative will consist of... a lot of minor product fixes (yes, again), training users, and rolling up several minor patches into bigger ones. Microsoft's press release actually used the words, quote, "improving the patch experience", unquote. So far this "improvement" has mainly consisted of monthly patch packages, which had to be re-released and re-installed several times a month in a 'revised' monthly version. Right...

Another sad aspect of Microsoft's actual stance on security is neatly summed up by internet.com editor Rebecca Lieb, who investigated Microsoft's commitment on fighting the epidemic flood of spam. She concludes:

"[Microsoft] executives are certainly committed to saying they are [committed to helping end the spam epidemic]. These days, Bill Gates is front and center: testifying before the Senate; penning a Wall Street Journal editorial; putting millions up in bounty for spammer arrests; building a Web page for consumers; and forming an Anti-Spam Technology & Strategy Group, "fighting spam from all angles-- technology, enforcement, education, legislation and industry self-regulation."
When I meet members of that group, I always ask the same question. Every version of the Windows OS that shipped prior to XP's release last year is configured --by default-- as an open relay. Millions have been upgraded to broadband. Ergo, most PCs on planet Earth emit a siren call to spammers: "Use me! Abuse me!" Why won't Microsoft tell its millions of registered customers how to close the open relay?"

Meanwhile Microsoft is branching into new markets and so far runs true to form. They have already shipped their first cellphone products. Orange, the first cellnet operator to run Microsoft Smartphone software on their SPV phones, has already had to investigate several security leaks. On top of that the phones are reported to crash and require three subsequent power-ups to get going again, call random numbers from the address book and have flakey power management. I shudder to think what will happen when their plans on the automotive software market begin to materialize.

In spite of what Microsoft's sales droids would have us believe, the facts speak for themselves: developments at Microsoft are solely driven by business targets and not by quality targets. As long as they manage to keep up their $30 billion plus yearly turnover, nobody's rear is on the line no matter how bad their software is. Microsoft products are immature and of inferior quality. New versions of these products provide no structural remedy, but are in fact point releases with bugfixes, minor updates and little else but cosmetic improvement. If it weren't for additional security products such as hardware-based or Unix-based filters and firewalls, it would be impossible to run an even remotely secure environment with Windows.
MS products are bloated with an almost baroque excess of features, but that's not the point. The point is that they are to be considered harmful, lacking robustness and security as a direct result of basic design flaws that are in many cases over a decade old. They promise to do a lot, but in practice they don't do any of it very well. If you need something robust, designed for mission-critical applications, you might want to look elsewhere. Microsoft's need for compatibility with previous mistakes makes structural improvements impossible. The day Microsoft makes something that doesn't suck, they'll be making vacuum-cleaners.
Besides, 63,000 known defects in Windows should be enough for anyone.


Comments? E-mail me!

Contents copyright © 2004 F.W. van Wensveen - all rights reserved.