Vista incompatibility isn't always Vista
In fact, it is very rarely Vista, from the problems I've seen.
Sure, there are some programs that rely on features and functionality that has been removed from Vista - but by and large, that functionality was already documented by Microsoft as being 'deprecated' or 'obsolete'. [Some features documented as obsolete for a decade!]
In those cases, you can argue that Microsoft should have made the decision to keep the feature in Windows because it was still being used. You won't persuade me, because the majority of features being removed are harmful to continued reliability and security (we'll talk about GINA and WinLogon later).
So, with this attitude, you'd think I would try to spend a lot of time making sure every piece of code I used would work in Windows Vista, right?
I'm as guilty of assuming as the next guy over.
I've been spending months ignoring the fact that my version control software, Component Software's CS-RCS Pro, isn't working on Vista.
Every time I open up Visual Studio 2005, it tries to open CS-RCS to get at the version control information for the files it's looking at. It doesn't help that some of the solutions I'm working on have five or more projects, and each project gets a warning that I have to acknowledge.
I'd been struggling through this, hitting "Ignore" or "Cancel" over and over, with the typical developer mentality of "I've got to get the job done, I can't afford to spend time trying in vain to fix the tools".
Until, that is, this weekend, when I decided I'd download a new version from Component Software's web site. "Surely by now," I rationalised, "they must have fixed it to work with Vista".
Nope - same problems.
So I went to read the help file.
Seriously? Access denied? On a help file?
Sure enough, the directory was banning me from accessing it.
NTFS permissions were doing me in.
Why? Because there was nobody listed in the DACL. The fact that I got no access indicates that this must have been an empty DACL. In Vista, an empty DACL really means "no access" - in Windows XP, an empty DACL means "owner has full control, everyone else no access".
So, it's possible that this was simply an inappropriate use of a poorly-documented DACL behaviour, rather than setting a DACL explicitly to restrict usage of the CS-RCS directory.
I can't reproduce this behaviour with the current install of CS-RCS, so I can't say whether this was my poor setup, or CS-RCS setting the DACL restrictively.