We do have a few Windows XP machines at work and they work OK for the most part. Of course, I've heard about virus and security problems and because of that I understand why I get the message that Windows has important security updates to install. It seems like every week I'm running these installs and rebooting.
We do use Macs for most of our stuff and these machines don't even have virus utilities installed. I've often wondered, is it really because of security-through-obscurity that keeps us Mac users devoid of these problems so prevalent in the Windows world?
I ran across this article that provides an excellent explanation (facts not hype) of the problem...
Five Architectural Flaws in Windows Solved In Mac OS X
http://www.roughlydrafted.com/Oct05.5Flaws.html
What was intended to be a short aside about Mac OS X's strengths turned into an entire series on Windows NT/2000/XP flaws! Here is the first of five examples of core Windows architectural problems that relate to process management, applications and security.
When writing the second article in the Wishlist for Mac OS X 10.5 Leopard series, I started by comparing ideas Apple that had borrowed from Windows, ideas they could borrow, and areas where Mac OS X was already ahead. The latter begat five articles, of which this is the first.
It is useful to understand why bad ideas are bad. It's also useful to identify how significant and difficult to solve a given problem is. This article tries to give a brief indication of why these design flaws are real and significant issues for Microsoft, and the real world problems they cause for Windows users.
I tried to limit the scope of this article to flaws related to process management and security. I've also separately written another article related to the Windows Registry that I'll be publishing soon. Without further ado, here is:
Flaw 1 - Windows' Interactive Services
Like all Unix distributions, Mac OS X spawns background system processes, called daemons, to handle various tasks. When a user logs into Mac OS X, a special security context is created for that user. Any applications that user launches are started under that user's credentials. Background processes can respond to requests from user-level applications, but they can not initiate any contact with the user, nor present any graphical interface, because they operate in a separate security context.
This is an important security measure that is missing in Windows, which allows for "interactive services." Allowing system processes running as root ("Services running as LocalSystem" in Windows-speak) to present a graphic UI to a logged in user ("become interactive with the desktop") is, to quote an MSDN blogger, a "spectacularly bad idea that should never have been added to the system."
Window's casual mix of security contexts makes it easy for malicious code to jump from the user's limited access realm into the root context, making it easy for a basic exploit to take over the entire machine. Exploiting this Windows-only flaw is called a Shatter Attack.
Three years ago, Microsoft replied to the threat of Shatter Attacks by stating that it was a known problem, and only offering that the inherently insecure and commonly used feature shouldn't be used (while citing earlier documentation that explained how to use it); that it only affected computers where a user could log in, such as a terminal server, or a workstation, or a server allowing logins (boggle!); and that, while a Shatter Attack could own your Terminal Server, it couldn't directly own the network. Of course, there are other security flaws to use once an exploit owns a trusted server.
Microsoft has decided to remove interactive services from Windows Vista (five years after the discovery became widely publicized), but this will break all the Windows services that currently use this insecure mechanism.
As a side note, Mac OS X's security edge over Windows in this example wasn't a product of hindsight; Apple just employed reasonable, known security principles. Shatter Attacks were exposed in 2002, the timeframe of Jaguar, after Apple had completed most of Mac OS X's security policy.
Flaw 2 - Windows' opaque and illogical file system presentation
Mac OS X applications and files are organized into clear, obvious security contexts.
Apple controls:
- system and support files in /System/Library
Machine administrators control:
- support files in local /Library
- applications in local /Applications
- documents in local / (root directory)
Users control:
- support files in /User/username/Library
- applications are installed in /User/username/Applications
- documents under /User/username/
Apple's convention of bundles, which present a folder and all of its contents as a file, renders individual Mac OS X applications as clean, uncluttered, self contained objects.
In Windows, the user, local and system contexts are muddied. Directories containing applications and settings are considered too confusing and dangerous to even display for users, so when a user tries to browse the file system, they are presented with:
These files are hidden. This folder contains files that keep your system working properly. You should not modify its contents.
Microsoft installs Windows into /WINDOWS, but the directory is mingled with third party additions, the problem that the reserved /System directory solves on Mac OS X.
Most programs install into /Program Files. Microsoft considers this folder too messy, confusing and dangerous to even display for users. Additionally, while Windows has lacked a limitation on file names for years, Windows applications are still a mess of cryptic 8.3 names, so that Internet Explorer is iexplore.exe and Outlook Express is msimn.exe.
Being messy and cryptic is not necessary, it is simply a Windows convention; Apple installs iTunes.exe and QuickTimePlayer.exe for Windows users.
Users have their own folders under /Documents and Settings/username/, but the Application Data and Local Settings folders (the equivalent to Mac OS X's ~/Library ) are both considered too confusing and dangerous to display. This is problematic for users, since that's where their cookies, caches, plug-ins, email and other stuff is saved.
Most of the user, application and machine settings are actually kept in the Windows Registry, which is even more complex and dangerous to allow users to access.
Windows' complexification further results in a file system layout that doesn't make logical sense. The user's desktop is presented as being the root directory, with everything inside it (My Computer, which contains drives; My Documents; etc.), but it's also presented elsewhere at its real location: /Documents and Settings/username/Desktop.
However, once a user navigates to the desktop, they can't go up a level to view their user directory. This results in shortcuts being put in the desktop directory (when viewed from a file browser) that don't necessarily appear on the desktop. What a mess!
It's easy to continue complaining about the illogical, inconsistent behaviors in Windows, but the key point is that Windows' opaque file system not only makes it hard to find things, but it also, more importantly, makes it easy for malicious code to hide things in a way that users can't easily monitor or defend against.
Flaw 3 - 'Least privilege' is impractical and broken
In the classic Mac OS (as with DOS), there was no concept of users or security. Users launched applications that could do anything. The system couldn't prevent users from deleting or overwriting critical files, and any application could stuff the System Folder full of Extensions that directly modified the system.
While a clean Mac install was pretty stable, once enough junk was installed, the system would lose stability and frequently crash, losing all unsaved data. It provided unbounded freedom through anarchy, and traded off security and stability for convenience and simplicity.
As computers joined networks, they were exposed to real external threats that demanded more attention to security. Unix, and later Windows NT, took somewhat similar approaches to providing this, by handing authority to a privileged kernel that preemptively scheduled tasks, restricted access to protected memory and other hardware, set ownership and permissions on files, and defined users with restricted privileges.
The capacity for restricted users allows applications and processes to run with the least amount of privilege necessary, so if they are compromised, anything that takes control is restricted in what damage it can cause.
Limited user privileges act like janitors in a high security building; they have enough security clearance to do their work, but are restricted from areas they don't need to enter. If someone were to steal their keys, they would still only have limited access within the building.
"Least privilege" is an important security principle that is poorly implemented in Windows. Part of the problem is sloppy programming by application developers, which demand excessive privileges when installing applications and consequently require users to have administrative privileges simply to run them. In Windows, the janitors have keys to everything. Pick a janitor's pocket, and you have free run of the entire building.
One method for making 'least privilege' feasible in Windows is the secondary sign-on feature. In Windows, a user can right click on an application and choose "Run As..." to execute the program as an administrative user, but this also runs the application in the admin user's environment, so that program can no longer see or access the current user's shares, personal files, or mounted drives. This frequently leaves the application improperly installed for non-admin users.
Running Windows under non-admin accounts is so difficult that one "Windows security expert" suggested that the idea of least privilege is a "red herring," and basically concluded that, since Windows' fragile notion of security is so easy to exploit anyway, why bother?
If Windows apologists demanded better security from Microsoft, instead of making excuses for the Church of Redmond and indoctrinating sheep-like submission into the Windows faithful, perhaps Microsoft would consider security a more important feature.
Another problem with using secondary sign-on, or "Run As...", to achieve least privilege is that the Windows interface confuses the definition of an application. Sometimes a control panel is a folder, sometimes its an actual application, sometimes a shortcut.
Sometimes what appears to be an application is a plugin embedded into the Microsoft Management Console, and sometimes an application is only presented when you click a button in another window. How do you right click on an application to "Run as..." if the application isn't presented in the interface?
It's not like you can browse the computer to find the application; that's off limits in Windows. And good luck doing a search; Windows' search function is a long joke with no punch line. You are only presented with the Program list in the Start menu, which is something akin to the Mac OS X Dock, but more difficult to customize, hidden away in the Start menu, and presented as a series of deeply nestled sub menus with maddening delays.
In Mac OS X, anytime you start an application, it appears in the Dock and changes the menubar; you can right click a Dock icon and ask it to "Show in Finder." Were it only so simple in Windows!
The main point however, is that in Mac OS X, non administrative users can install applications locally in their user context. You can theoretically do this in Windows, but installing an application for a single, non admin user is frequently broken in practice. Trying to run Windows according to least privilege policy is difficult at best, and often simply considered impractical, so nobody does it. This leaves Windows users unnecessarily vulnerable.
Flaw 4 - No signal of privilege escalation
An administrator in Mac OS X can act as root by authenticating. When a user installs an application that requires special privileges, they are prompted to enter an administrative password. This also reminds the user that they are delegating important security privileges to that application.
That level of trust is not required unless an application needs to install background services that run as privileged daemons, or installing to system level folders such as /Applications or /Library.
Not only is it excessively difficult to run Windows as anything but an administrator (as noted in the previous point), but once logged in as an administrator, Windows users are not prompted to authenticate when performing a root level administrative task.
Since everyone is running Windows as an administrator, malicious code has no problem getting installed, without Windows ever flagging the user that important security permissions have been handed out, particularly during an installation.
The result of multiplying flaws two, three, and four explains the current plague of viruses, adware, malware, spyware and other flavors of malicious code that are so easy for spam-based marketers to foist upon vulnerable Windows users. Unfortunately, these flaws are all deeply rooted both in Window's architecture and culture.
That's right, Windows has flaws that are not just technical problems (which are usually straightforward to solve), but are tied to Microsoft core nature. Microsoft is, and has always been, a marketing company that sells software products, or more precisely, sells ideas that may become products.
Bill Gates sold IBM the idea of MS DOS, then rushed to deliver it, and his company has been selling vaporware ideas for the last twenty five years. Microsoft only attempts to deliver a product when the licensing market cycle requires it. The company sells placeholder-ware; products described to fit a solution. Once the sale is made, then work on delivering the product is begun.
Windows itself was placeholder-ware; Microsoft wanted Apple to license the Mac system software for PCs; when they didn't, Microsoft announced they would themselves. Microsoft fudged a graphical analog on top of DOS, and ported their existing Mac Office apps to run on it, but they delivered Windows 95 over a decade after the Mac, despite starting Windows prior to the initial release of the Macintosh.
Windows NT was also placeholder-ware to solve a gap: the lack of a real operating system for Windows 3. After abandoning OS/2 development with IBM, Microsoft hired a technically savvy operating system guru and delivered Windows NT 3.5.
Microsoft avoids competition by pitting its placeholder-ware product definition against real products for sale in new and emerging markets. By instilling fear, uncertainty and doubt surrounding the threat of Microsoft's entry into the market, kowtowed market analysts advise customers to wait for Microsoft to fill in placeholder products. Meanwhile, the competition dies of starvation, and Microsoft begins work on developing, or buying, an acceptable product that rarely meets the originally promised feature set.
The security problem related to Microsoft's marketing driven focus is that the company is only interested in a market position until they own it. After establishing a monopoly, they lose interest in (and motivation for) ongoing development, particularly in the area of security flaws which do not result in features that drive the next version of their product.
For example, after leveraging their monopoly position to destroy Netscape as a competitor, Microsoft left internet Explorer to rot. The Mac version was entirely canned, and the Windows version grew stagnant.
Conversely, technology-driven companies seek to provide customers with solutions that fit their needs, and security is an important consideration. Microsoft's leading market position may make its products a more obvious security target, but the real problem is that Microsoft doesn't need to care about security because the are insulated from market realities.
Hopefully, serious competition from Linux on the server side, and Mac OS X on the desktop, will prompt Microsoft to take serious steps toward delivering not only technology fixes for its security problems, but also make the company reevaluate the value of its reputation as well, and make a business case for caring about the quality of the software they market.
Flaw 5 - Windows' expensive processes
Another problem for Windows is that launching a new process is expensive. While Unix was designed to be very efficient at spawning new processes, Windows NT was designed to handle parallel processing using multiple threads within a single process.
Creating a new process in Windows takes a "non trivial amount of time to launch, and each process consumes a fair amount of system resources," so Windows frequently tries to pack multiple services into a single shared service process to skimp on the number of expensive processes that have to be launched and maintained.
For example, svchost.exe is a single process in Windows that can be running 25 to 30 or more different services (a service in Windows is similar to a Unix daemon) as threads within the single process. In Mac OS X, one daemon is one process.
Shared services is an ugly catch-22 for Windows. On one hand, splitting services out into separate processes would eat up a lot of memory and performance; that's why they are shared in the first place. On the other hand, sharing the same process means all those processes run in the same address space and can interfere with each other. If one tanks, it brings down all the others, and likely the entire system too. It also kills the notion of protected memory, one of the primary goals of modern operating systems.
And because shared services are considered a necessary evil, services have developed dependencies upon running in a shared address space, much like a battered spouse that finds living with dysfunction easier than leaving.
That means even if you decide to take the performance hit and split services out into separate processes, they will likely no longer run properly and crash your machine.
So there you have it. The next time someone asks you about Windows' significant architectural flaws, you'll have something to talk about.
We do use Macs for most of our stuff and these machines don't even have virus utilities installed. I've often wondered, is it really because of security-through-obscurity that keeps us Mac users devoid of these problems so prevalent in the Windows world?
I ran across this article that provides an excellent explanation (facts not hype) of the problem...
Five Architectural Flaws in Windows Solved In Mac OS X
http://www.roughlydrafted.com/Oct05.5Flaws.html
What was intended to be a short aside about Mac OS X's strengths turned into an entire series on Windows NT/2000/XP flaws! Here is the first of five examples of core Windows architectural problems that relate to process management, applications and security.
When writing the second article in the Wishlist for Mac OS X 10.5 Leopard series, I started by comparing ideas Apple that had borrowed from Windows, ideas they could borrow, and areas where Mac OS X was already ahead. The latter begat five articles, of which this is the first.
It is useful to understand why bad ideas are bad. It's also useful to identify how significant and difficult to solve a given problem is. This article tries to give a brief indication of why these design flaws are real and significant issues for Microsoft, and the real world problems they cause for Windows users.
I tried to limit the scope of this article to flaws related to process management and security. I've also separately written another article related to the Windows Registry that I'll be publishing soon. Without further ado, here is:
Flaw 1 - Windows' Interactive Services
Like all Unix distributions, Mac OS X spawns background system processes, called daemons, to handle various tasks. When a user logs into Mac OS X, a special security context is created for that user. Any applications that user launches are started under that user's credentials. Background processes can respond to requests from user-level applications, but they can not initiate any contact with the user, nor present any graphical interface, because they operate in a separate security context.
This is an important security measure that is missing in Windows, which allows for "interactive services." Allowing system processes running as root ("Services running as LocalSystem" in Windows-speak) to present a graphic UI to a logged in user ("become interactive with the desktop") is, to quote an MSDN blogger, a "spectacularly bad idea that should never have been added to the system."
Window's casual mix of security contexts makes it easy for malicious code to jump from the user's limited access realm into the root context, making it easy for a basic exploit to take over the entire machine. Exploiting this Windows-only flaw is called a Shatter Attack.
Three years ago, Microsoft replied to the threat of Shatter Attacks by stating that it was a known problem, and only offering that the inherently insecure and commonly used feature shouldn't be used (while citing earlier documentation that explained how to use it); that it only affected computers where a user could log in, such as a terminal server, or a workstation, or a server allowing logins (boggle!); and that, while a Shatter Attack could own your Terminal Server, it couldn't directly own the network. Of course, there are other security flaws to use once an exploit owns a trusted server.
Microsoft has decided to remove interactive services from Windows Vista (five years after the discovery became widely publicized), but this will break all the Windows services that currently use this insecure mechanism.
As a side note, Mac OS X's security edge over Windows in this example wasn't a product of hindsight; Apple just employed reasonable, known security principles. Shatter Attacks were exposed in 2002, the timeframe of Jaguar, after Apple had completed most of Mac OS X's security policy.
Flaw 2 - Windows' opaque and illogical file system presentation
Mac OS X applications and files are organized into clear, obvious security contexts.
Apple controls:
- system and support files in /System/Library
Machine administrators control:
- support files in local /Library
- applications in local /Applications
- documents in local / (root directory)
Users control:
- support files in /User/username/Library
- applications are installed in /User/username/Applications
- documents under /User/username/
Apple's convention of bundles, which present a folder and all of its contents as a file, renders individual Mac OS X applications as clean, uncluttered, self contained objects.
In Windows, the user, local and system contexts are muddied. Directories containing applications and settings are considered too confusing and dangerous to even display for users, so when a user tries to browse the file system, they are presented with:
These files are hidden. This folder contains files that keep your system working properly. You should not modify its contents.
Microsoft installs Windows into /WINDOWS, but the directory is mingled with third party additions, the problem that the reserved /System directory solves on Mac OS X.
Most programs install into /Program Files. Microsoft considers this folder too messy, confusing and dangerous to even display for users. Additionally, while Windows has lacked a limitation on file names for years, Windows applications are still a mess of cryptic 8.3 names, so that Internet Explorer is iexplore.exe and Outlook Express is msimn.exe.
Being messy and cryptic is not necessary, it is simply a Windows convention; Apple installs iTunes.exe and QuickTimePlayer.exe for Windows users.
Users have their own folders under /Documents and Settings/username/, but the Application Data and Local Settings folders (the equivalent to Mac OS X's ~/Library ) are both considered too confusing and dangerous to display. This is problematic for users, since that's where their cookies, caches, plug-ins, email and other stuff is saved.
Most of the user, application and machine settings are actually kept in the Windows Registry, which is even more complex and dangerous to allow users to access.
Windows' complexification further results in a file system layout that doesn't make logical sense. The user's desktop is presented as being the root directory, with everything inside it (My Computer, which contains drives; My Documents; etc.), but it's also presented elsewhere at its real location: /Documents and Settings/username/Desktop.
However, once a user navigates to the desktop, they can't go up a level to view their user directory. This results in shortcuts being put in the desktop directory (when viewed from a file browser) that don't necessarily appear on the desktop. What a mess!
It's easy to continue complaining about the illogical, inconsistent behaviors in Windows, but the key point is that Windows' opaque file system not only makes it hard to find things, but it also, more importantly, makes it easy for malicious code to hide things in a way that users can't easily monitor or defend against.
Flaw 3 - 'Least privilege' is impractical and broken
In the classic Mac OS (as with DOS), there was no concept of users or security. Users launched applications that could do anything. The system couldn't prevent users from deleting or overwriting critical files, and any application could stuff the System Folder full of Extensions that directly modified the system.
While a clean Mac install was pretty stable, once enough junk was installed, the system would lose stability and frequently crash, losing all unsaved data. It provided unbounded freedom through anarchy, and traded off security and stability for convenience and simplicity.
As computers joined networks, they were exposed to real external threats that demanded more attention to security. Unix, and later Windows NT, took somewhat similar approaches to providing this, by handing authority to a privileged kernel that preemptively scheduled tasks, restricted access to protected memory and other hardware, set ownership and permissions on files, and defined users with restricted privileges.
The capacity for restricted users allows applications and processes to run with the least amount of privilege necessary, so if they are compromised, anything that takes control is restricted in what damage it can cause.
Limited user privileges act like janitors in a high security building; they have enough security clearance to do their work, but are restricted from areas they don't need to enter. If someone were to steal their keys, they would still only have limited access within the building.
"Least privilege" is an important security principle that is poorly implemented in Windows. Part of the problem is sloppy programming by application developers, which demand excessive privileges when installing applications and consequently require users to have administrative privileges simply to run them. In Windows, the janitors have keys to everything. Pick a janitor's pocket, and you have free run of the entire building.
One method for making 'least privilege' feasible in Windows is the secondary sign-on feature. In Windows, a user can right click on an application and choose "Run As..." to execute the program as an administrative user, but this also runs the application in the admin user's environment, so that program can no longer see or access the current user's shares, personal files, or mounted drives. This frequently leaves the application improperly installed for non-admin users.
Running Windows under non-admin accounts is so difficult that one "Windows security expert" suggested that the idea of least privilege is a "red herring," and basically concluded that, since Windows' fragile notion of security is so easy to exploit anyway, why bother?
If Windows apologists demanded better security from Microsoft, instead of making excuses for the Church of Redmond and indoctrinating sheep-like submission into the Windows faithful, perhaps Microsoft would consider security a more important feature.
Another problem with using secondary sign-on, or "Run As...", to achieve least privilege is that the Windows interface confuses the definition of an application. Sometimes a control panel is a folder, sometimes its an actual application, sometimes a shortcut.
Sometimes what appears to be an application is a plugin embedded into the Microsoft Management Console, and sometimes an application is only presented when you click a button in another window. How do you right click on an application to "Run as..." if the application isn't presented in the interface?
It's not like you can browse the computer to find the application; that's off limits in Windows. And good luck doing a search; Windows' search function is a long joke with no punch line. You are only presented with the Program list in the Start menu, which is something akin to the Mac OS X Dock, but more difficult to customize, hidden away in the Start menu, and presented as a series of deeply nestled sub menus with maddening delays.
In Mac OS X, anytime you start an application, it appears in the Dock and changes the menubar; you can right click a Dock icon and ask it to "Show in Finder." Were it only so simple in Windows!
The main point however, is that in Mac OS X, non administrative users can install applications locally in their user context. You can theoretically do this in Windows, but installing an application for a single, non admin user is frequently broken in practice. Trying to run Windows according to least privilege policy is difficult at best, and often simply considered impractical, so nobody does it. This leaves Windows users unnecessarily vulnerable.
Flaw 4 - No signal of privilege escalation
An administrator in Mac OS X can act as root by authenticating. When a user installs an application that requires special privileges, they are prompted to enter an administrative password. This also reminds the user that they are delegating important security privileges to that application.
That level of trust is not required unless an application needs to install background services that run as privileged daemons, or installing to system level folders such as /Applications or /Library.
Not only is it excessively difficult to run Windows as anything but an administrator (as noted in the previous point), but once logged in as an administrator, Windows users are not prompted to authenticate when performing a root level administrative task.
Since everyone is running Windows as an administrator, malicious code has no problem getting installed, without Windows ever flagging the user that important security permissions have been handed out, particularly during an installation.
The result of multiplying flaws two, three, and four explains the current plague of viruses, adware, malware, spyware and other flavors of malicious code that are so easy for spam-based marketers to foist upon vulnerable Windows users. Unfortunately, these flaws are all deeply rooted both in Window's architecture and culture.
That's right, Windows has flaws that are not just technical problems (which are usually straightforward to solve), but are tied to Microsoft core nature. Microsoft is, and has always been, a marketing company that sells software products, or more precisely, sells ideas that may become products.
Bill Gates sold IBM the idea of MS DOS, then rushed to deliver it, and his company has been selling vaporware ideas for the last twenty five years. Microsoft only attempts to deliver a product when the licensing market cycle requires it. The company sells placeholder-ware; products described to fit a solution. Once the sale is made, then work on delivering the product is begun.
Windows itself was placeholder-ware; Microsoft wanted Apple to license the Mac system software for PCs; when they didn't, Microsoft announced they would themselves. Microsoft fudged a graphical analog on top of DOS, and ported their existing Mac Office apps to run on it, but they delivered Windows 95 over a decade after the Mac, despite starting Windows prior to the initial release of the Macintosh.
Windows NT was also placeholder-ware to solve a gap: the lack of a real operating system for Windows 3. After abandoning OS/2 development with IBM, Microsoft hired a technically savvy operating system guru and delivered Windows NT 3.5.
Microsoft avoids competition by pitting its placeholder-ware product definition against real products for sale in new and emerging markets. By instilling fear, uncertainty and doubt surrounding the threat of Microsoft's entry into the market, kowtowed market analysts advise customers to wait for Microsoft to fill in placeholder products. Meanwhile, the competition dies of starvation, and Microsoft begins work on developing, or buying, an acceptable product that rarely meets the originally promised feature set.
The security problem related to Microsoft's marketing driven focus is that the company is only interested in a market position until they own it. After establishing a monopoly, they lose interest in (and motivation for) ongoing development, particularly in the area of security flaws which do not result in features that drive the next version of their product.
For example, after leveraging their monopoly position to destroy Netscape as a competitor, Microsoft left internet Explorer to rot. The Mac version was entirely canned, and the Windows version grew stagnant.
Conversely, technology-driven companies seek to provide customers with solutions that fit their needs, and security is an important consideration. Microsoft's leading market position may make its products a more obvious security target, but the real problem is that Microsoft doesn't need to care about security because the are insulated from market realities.
Hopefully, serious competition from Linux on the server side, and Mac OS X on the desktop, will prompt Microsoft to take serious steps toward delivering not only technology fixes for its security problems, but also make the company reevaluate the value of its reputation as well, and make a business case for caring about the quality of the software they market.
Flaw 5 - Windows' expensive processes
Another problem for Windows is that launching a new process is expensive. While Unix was designed to be very efficient at spawning new processes, Windows NT was designed to handle parallel processing using multiple threads within a single process.
Creating a new process in Windows takes a "non trivial amount of time to launch, and each process consumes a fair amount of system resources," so Windows frequently tries to pack multiple services into a single shared service process to skimp on the number of expensive processes that have to be launched and maintained.
For example, svchost.exe is a single process in Windows that can be running 25 to 30 or more different services (a service in Windows is similar to a Unix daemon) as threads within the single process. In Mac OS X, one daemon is one process.
Shared services is an ugly catch-22 for Windows. On one hand, splitting services out into separate processes would eat up a lot of memory and performance; that's why they are shared in the first place. On the other hand, sharing the same process means all those processes run in the same address space and can interfere with each other. If one tanks, it brings down all the others, and likely the entire system too. It also kills the notion of protected memory, one of the primary goals of modern operating systems.
And because shared services are considered a necessary evil, services have developed dependencies upon running in a shared address space, much like a battered spouse that finds living with dysfunction easier than leaving.
That means even if you decide to take the performance hit and split services out into separate processes, they will likely no longer run properly and crash your machine.
So there you have it. The next time someone asks you about Windows' significant architectural flaws, you'll have something to talk about.
