Correction: shared libraries (DLLs) on Windows are shared between processes exactly the same way as it works on Linux, they're called 'shared' for a reason :-)

Correction: shared libraries (DLLs) on Windows are shared between processes exactly the same way as it works on Linux, they're called 'shared' for a reason :-) They get "mapped" into virtual address space of every process, but physically there's only one copy, moreover, if you're running as an Admin, a process can alter the code in a shared DLL, causing it to work differently in all other processes that use it, that's one of the tricks that infamous rootkits do to hide themselves. You are right, Windows processes are heavy. Moreover, context switch between processes on Windows is also a little slower, because NT-based kernels went "maximum security" route and perform full process isolation, that's also why Windows doesn't have a fork-like syscall, only environment variables, IIRC, can be cloned. (which is how, I suspect, Linux threads are implemented - they're probably share-everything fork calls). On the other hand thread/fiber switch on Windows, I believe, is fastest of all popular x86 OSes. All in all I like Windows process model a lot more. Clear separation between processes (share nothing) and threads (share everything except the stack) is well-known and well documented, and leads to a much nicer server-like application programming experience. Although... I really like how easily you can nuke frozen processes on Linux if there is a problem. No programming tools/knowledge required. Dealing with hung threads would have been a lot harder.