security model from their inception, where all but a select few programs are designed to run within the security confines of the user who launched them. The first versions of Windows didn't support running processes in a separate 'user space' which didn't have direct access to hardware and other resources. Since MS usually puts a big effort into backwards compatibility so people can still use the large existing software base when they upgrade, no attempt was made to block programs from elevating their permissions if needed (later versions allow enforcing this via policies like Hayu mentioned). In turn, most developers didn't feel the need to code their apps without requiring elevated access. So, UAC comes along and many more programs trigger it than they should, because they're not coded properly. Such a program in OSX/Linux flat out wouldn't run unless you're a super-user because no such elevation mechanism exists. This should change over the next few years- MS might decide to run old apps (or maybe all apps) in a complete VM sandbox (parts of the machine are already virtualized for all processes) since we're at the point where even the lowliest hardware can handle it. I'm guessing this is what happens when you run a Classic MacOS program in OSX, for example. We have been writing an application for windows Vista and runs nicely on anything pre vista. On Vista, the program cannot read or write from its own folders. We have done everything thats suggestd by MS including