Microsoft implemented the "Virtual Store" concept in Vista. In days of old, it was common practice for apps to read/write configuration and ini files, etc. using the same folder where the app was installed... and this was typically C:\Program Files. Later on, when security was tightened in Windows, this practice would no longer work unless the user had admin rights. To prevent apps from crashing while protecting unauthorized changes, Windows was enhanced to intercept attempts to write into protected folders and re-directs the activity to the user's Virtual Store. Read attempts by unauthorized users into protected folders are automatically read from the Virtual Store if the file exists there. So, once written there, that's where the real file resides.
This is all well and good, and I have no doubt that a Vista engineering team within Microsoft patted themselves on the back for their ingenuity. The deception falls apart, however, when an admin user makes a legitimate change to what they believe is the "real" file residing in C:\Program Files... the non-admin user will never see the updated file because Windows always gives them the non-updated version that resides in their Virtual Store.
As Kevin correctly suggests, the fix is to stop reading and writing files from the app's protected installation folder.
The 32 bit APPNAME VirtualStore hive location is here:
HKEY_CLASSES_ROOT\VirtualStore\MACHINE\SOFTWARE\WOW6432Node\APPNAME\App_Folder
The location of the Drive Mappings is here:
HKEY_CURRENT_USER\Network