Beware the consequences of Vista’s “compatibility modes”

Vista’s compatibility modes are great in many ways. I use them to run old games, and to work around a problem in Eclipse for example. However, they contain a sneaky little “gotcha” that recently caught me out.

I have recently been involved in work with Vista’s implementation of symbolic links. For reasons best known to Microsoft, they chose to use a feature available in XP – reparse points – to implement symbolic links in Vista, yet didn’t release the reparse point drivers for symbolic links as an update to XP. This means that XP can recognise a symbolic link, but can’t do anything with it. As a result, I ended up with different Java Native Interface (JNI) DLLs for basic Windows file functionality and Symbolic link-specific functionality, and only wanted the latter loaded on a Vista (or Server 2008) machine.

Java provides a means of determining the operating system by calling System.getProperty("os.name"). On a Vista machine, it returns “Windows Vista”, and on an XP machine it returns “Windows XP”. Except that for me, it didn’t. I tried various versions of the JDK and JRE, wrote a test program etc and all to no avail, for my Vista box kept reporting it was Windows XP. At a complete loss, I turned to Stackoverflow and asked there. Someone very quickly pointed out what I was doing wrong: I was running Eclipse in XP compatibility mode, which meant any Java program or test suite launched via Eclipse also ran in XP compatibility mode! I ran Eclipse without it and all my Java code dutifully reported it was running on Vista.

The points here may be obvious to many, but they never really occurred to me. If you run a program in compatibility mode, any program it launches in turn, will also run in compatibility mode. And part of the compatibility mode features involves lying to the program about the operating system it’s running on.