Vista was a major security redesign, not just bug fixes. UAC was one of the biggest security improvements in the OS, because it meant that users were no longer running as admin by default.

UAC is not a security feature/ boundary (even according to MSFT themselves). It was aimed to help stop ISVs from writing software assuming admin privileges.

Vista had A LOT of security improvements overall, but UAC shouldn't be considered as one of them (similar to PatchGuard for x64 Windows - it's cited as sometimes a security feature, but it's not).

I'm sure they didn't like it because security is, while necessary, a pita

> UAC was one of the biggest security improvements

I assumed it was just an interface stapled onto the old system, and something underneath that allowed changing permissions without logging off.

It might have had a big effect, but it doesn't sound like a significant change in the system. But maybe my assumptions are wrong ...

The entire concept of UAC and programs not running by default was introduced in Vista. It was such a big change that it pretty much ruined the reputation of the OS, single-handedly. I remember that one of the major complaints about Vista was the number and intrusiveness of UAC prompts, which occurred because programs were doing things like keeping settings in C:\Program Files, rather than the user's application data folder.

Windows 7 has the same permissions model as Vista, but has a much better reputation, because by the time 7 was released, applications had been updated to not require as much in the way of permissions. From the users perspective, this meant that 7 "worked properly", even though little had changed in terms of the security model between Vista and 7.

I've used Linux for many years, but I've always defended Vista. The other complaint about Vista was excessive resource use. I tell people that When XP came out, Intel released the Pentium 4. When Vista came out, Intel released the Core 2 Duo.

I'm conflating processor date with date-you-could-buy-a-computer-with-that-chip, but still: Pentium 4 is a world away from Core. Windows Vista does a lot more than XP.

The complaints went away because people gradually bought computers with Core architectures.

The real problem with Vista and resource use came from the OEMs. Details here: http://blog.seattlepi.com/microsoft/2008/02/27/full-text-mic...

Microsoft has a program where they certify that hardware will work acceptably with their operating systems. This is important in the run-up to a new version of Windows, because during the period when everyone knows that Windows X+1 is coming soon but all you can buy off the shelf are machines with Windows X, people want to be confident that they'll be able to upgrade to Windows X+1 when it's available.

For Vista, if your machine passed this certification, you got the right to ship it with a shiny sticker that said "Vista Ready." Seeing the "Vista Ready" sticker on that XP laptop on the shelf at Best Buy told customers that they could buy it without fear. It was certified future-proof.

However, Vista required more resources than XP did to run with acceptable performance. That meant that OEMs had a ton of ultra-cheap XP machines in the pipeline that could not with a straight face be called "Vista Ready." And this was a problem, because they didn't want to get stuck with warehouses full of machines nobody would buy because they couldn't run Vista.

So what they pushed for, and what MS eventually gave them, was a new certification: "Vista Capable." Unlike "Vista Ready," "Vista Capable" didn't mean Vista would run well on the hardware in question. It just meant you could install Vista on it, with no guarantees as to how it would actually run. And the shiny "Vista Capable" sticker looked pretty much exactly like the shiny "Vista Ready" sticker, so if you weren't looking carefully, it was easy to confuse the two.

The OEMs loved this solution, because they could now slap "Vista Capable" stickers on all those crappy XP machines and unload them on people. But, entirely predictably, then Vista came out and suddenly tons of people were installing it on hardware that was nowhere near beefy enough for it. So for umpty-ump millions of people who bought that crappy hardware, the experience of using Vista was painful and awkward and slooooow. Eventually even the cheapest machines were powerful enough to meet Vista's requirements -- but by that point Vista's reputation had been sealed. As the saying goes, you never get a second chance to make a first impression.

But the OEMs did get all that inventory out of their warehouses. So, you know, mission accomplished.

This, exactly.

Vista is now my go-to example for when people managing platforms say "just break badly written applications, their incompetence is their problem, not ours." Microsoft took a staggering PR hit when all sorts of crappy, poorly-written applications broke under Vista, because their users all blamed Microsoft for it. People don't know their applications are crappy under the hood; all they know is that they used to work, and now they don't.

UAC in Vista essentially introduced the idea of a "split token". Administrators get two access tokens: a full access token, and a filtered access token. The filtered access token essentially is a standard user token and used by default. Only when elevating (UAC is prompted) is the full access token used (which is the filtered access token plus various admin-level privileges).

Each token has different privileges on what it allows/ doesn't allow. One notable change in Vista was the introduction of SetTimeZonePrivilege, since in XP, you had to be an adminstrator in order to change the time.

In XP, you could always change permission without logging off, by using the runas command or Run as... in the context menu. I think you could also set shortcuts to run programs as Administrator.

So you could run as a non privileged users, and you'd only need to log in as Administrator for some very specific tasks.

However, there were many applications that didn't play nice with that model and required you to run as Administrator. By changing the default, MS had to do a big push to make software makers abide by the rules (which had been in place since XP (edit: in the mainstream branch) but were often ignored)

You could do that under XP, but needed a separate user account for administrator. It was also more of a hassle, as you always had to enter the password when starting a program as Administrator. I ran with such a setup on my desktop, and remember that to install programs I usually logged out and logged in as Administrator again.

Vista introduced a model that was almost as good, but made it more user-friendly and the default.

And judging by the pageviews on my blogpost on how to disable it, users didn't really like it very much...

Which was caused in part by badly behaving programs (writing user data to the Program Files directory) that triggered the UAC prompt, if I'm not mistaken.

They improved the system in the next release, and since Win7 UAC generally works perfectly even with the "badly behaving" software. Sensitive directories are now mirrored elsewhere in the filesystem, so that when your program wants to read from, say, Program Files directly, what it really reads is C:/Users/[username]/AppData/Local/VirtualStore/...

I've never experienced this in writing my own software. If I try to read or write to a directory I'm not allow to I simply get access denied.

f = open('C:/windows/test.txt')

try:

    f.write('test')
 

except Exception as ex:

    print ex
 

IOError: [Errno 13] Permission denied: 'C:/windows'

Try the same with C:/test.txt. Open Explorer and see if the file actually appears in C:/.

So that's what the policy "Virtualize file and registry write failures to per-user locations" does... uh, good to know :) thanks!

In my particular legacy-apps' field, I believe most problems are due to interactions with the DCOM subsystem though.

Yeah, I only learned about it after I discovered what "~" is being resolved to in my Emacs installation on Windows...

That was already in Vista, if I remember correctly.