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.