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?

Wrong.

I’m as guilty of assuming as the next guy over.

Example?

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.

Access denied.

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.

4 Responses to Vista incompatibility isn’t always Vista

  • Michael Kairys says:

    How did you get it to install? I’ve tried installing CS-RCS 5.0 on Vista Ultimate and setup.exe dies in the middle every time.

  • alunj says:

    I didn’t do anything special – but this is an upgrade from XP running CS-RCS to Vista running CS-RCS. Maybe the upgrade did some magic.

  • Michael Kairys says:

    Yes, that explains it; it seems to be only the setup program that bombs. If I knew all of what it has to do I could probably do it by hand; but there’s the service and the DocumentManager and who knows what else. Well, if I get desperate enough I’ll probably have a hack at it :)

  • Michael Kairys says:

    Actually it turned out to be easy. I searched my XP registry for ComponentSoftware and CS[-]RCS and made a .reg file of what I found. (I had to edit the user ID in the HKEY_USERS entries.) Then I copied the CS-RCS program files and ran the .reg file on the Vista system and … IJW!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>