Shared memory space is not the reason for most buffer overflow exploits. Windows doesn't have shared memory since Win 3.0 (or Win 3.1 running on 80286), so it's been a long time, almost 20 years, since Windows was last shipped which supported shared memory model.
Buffer overflow allows the attacker to change memory in the process which is being exploited. By doing that the attacker is aiming to execute a system operation (for example start a process, or load a dynamic library, or change a certain user's rights, etc.) using the target processes' privilege level.
This is possible on Win* platforms, *nix platforms, and many other. How the OS and the application which is being exploited, is dealing with this attempt, is what makes the difference. On the application side, careful buffer size checking is what it usually takes to avoid this. Technologies like ASLR (address space layout randomization, which prevents the attacker from guessing the address of a function she needs to call to do harm) and DEP (data execution prevention, which prevents the attacker from injecting executable code into your data areas), provided by the OS, help tremendously. On the OS side, not running applications as root/administrator is perhaps the most important line of defense.