My involvement with xPL has come to an end. Automation has moved on considerably over the past few years, and it is now possible to buy a stand-alone controller off the shelf for a reasonable price, without having to spend hours writing your own code.

This website is being maintained as a record of my xPL development work up until 2011.

I have released the full source code of all my xPL projects into the public domain. You can download the archive from here.


Microsoft's Permissions Nightmare
31st August 2011

Access rights have become a complete nightmare since Vista, and file system virtualization makes things even worse.

Even if you create folders in the correct locations for user data, they do not automatically come with user access rights, and any files written there are silently redirected to a virtual store. You will see this when you save a configuration file over the top of an old one only for your program to appear to still be loading the orginal version. Similar problems aflict the registry, if you write to keys under HKLM without admin rights.

Added to this is the fact that the Win32 function SHGetKnownFolderPath, and the .Net method System.Environment.GetFolderPath do not always agree on what the user's data folder location should be, means that projects containing a mix of .Net and C++ apps (such as most of my xPL apps that have a C++ service and a .Net config program) can't read common data files.

And finally, if you change your UAC settings, the virtualisation will be turned on or off - the redirection will change and the files and registry settings your programs were relying on suddenly change to old ones.

I was forced to find a solution to Microsoft's brain-dead mess, since in both xPL and my day job I have to write apps that will work on all versions of Windows back to 2000, on 32 and 64 bit platforms, and with a mix of user access right levels.

So, as part of my install process (which runs with admin rights), I now run a small .Net app that creates the app's data folder in the correct location (according to .Net), and then creates a registry key containing the path to that folder. It also sets the permissions on the folder so that the user may write there without the redirection nonsense breaking everything.

This has solved all the problems I mention above. Apps simply read the location from the registry and store all of their configuration information there.

Download CreateDataFolder source code
What's new in 2011?
28th January 2011

The big push this year, the same as last, is OpenZWave. This project has taken a lot longer than expected, but should soon be in a state where a new version of xPLZWave can be created, and my focus can return to the world of xPL.