Okay, you got Solutions 1 and 2, first makes limited applicability at best and presents a pretty bad advice for all cases except the worse, and the second one it totally wrong. I'll explain.
To begin with: Believe or not, all my applications built in NT technology, which includes Windows NT, W2000 and XP, works on Windows 7. This is because I simply wrote them accurately enough. This is because
backward compatibility takes place. Moreover with
forward compatibility (which is, strictly speaking, not supported), the situation is not that bad. Recently, I assumed that we should support only Window 7 and later, and, when I was asked to support XP, found an incompatibility, and only because I explicitly checked up the
privilege elevation, the notion absent in XP. So, permission…
From all my experience of helping other developers, all the set of reasons of incompatibilities with Windows 7 and later people face is majorly reduced to permission issues. In a nutshell: people write applications which are not quite legitimate even for XP, but standard out-of-the box XP settings are too forgiving. If one tightens up file system permissions even with XP, the similar problems appear.
In most cases, this is the case of using some non-legitimate directories or even hard-coded paths. There are no situation when hard-coded paths could be useful. In all cases, all paths should be calculated during runtime using user input, some configuration files, user profile data and other paths defined by the environment. This is explained in my past answers:
How to find my programs directory (
executable directory),
How to find my programs directory (
current directory, "special folders").
Of course, there can be a number of other problems, but they are all quite rare, in practice. (Too bad you did not present any information on your problems in your question.)
As to Solution 1, using "XP" mode, this is the tool for extreme use in a case of extreme urgent need. It compromises system safety. Fixing your application is much better.
—SA