In the first part of this article we discussed the user settings file (mainly for eMRD). This second part discusses the Microsoft Virtual Store and how it affects our applications.
As you are probably aware, all LES applications run on Microsoft Operating Systems and are compatible with MS Windows XP (SP3) right through to Windows 8.1. Because we have designed our products to run in the MS OS environment, we are constrained by certain things that Windows does that may affect how our software behaves.
The Virtual Store
Since the MS Vista OS (that includes Windows 7 and Windows 8) Microsoft introduced this concept of a Virtual Store. The Virtual Store affects the way applications are managed and changed within your programs directory.
In a nutshell, if the user is not logged on with administrator rights and any file is modified in a “protected” directory, then the OS will allow the file to be changed but will store a post-modified version of that file in the Virtual Store. Typically, the user will expect to use or see the changes made to that particular file – however, what really happens is that the OS directs the application to use the post-modified file stored in the Virtual Store. With Windows Vista this was easy to get around – just disable User Access Control (UAC). Microsoft made it a little more difficult with Windows 7, 8 and 8.1.
Protected directories include:
- C:\windows
- C:\Program Files
- C:\Program Files (x86)
What becomes more confusing is this is a user based feature. The Virtual Store typically lives at:
- C:\Users\<user name>\AppData\Local\VirtualStore
Therefore, if you share the machine with another user who did not initiate the change then they would not benefit from the change of that particular file.
How does this affect our applications? (eMRD in particular). When you start eMRD you may notice on the splash screen that this particular version of eMRD is compatible with a certain back end database version. The most current version of eMRD is compatible with database version 1.7. When we release patches to eMRD and some minor tweaks are required to the database, rather than providing a new LSABlank, we will include code in eMRD to interrogate the blank and update it as required. The database version number remains the same however.
Any OS employing Virtual Store will see this as an unauthorised change to a file in a “protected directory” and do its thing by saving the post-modified copy in the Virtual Store. Generally, this all works very well until a file is copied into the protected area. If there is a file of the same name in the user’s Virtual Store, eMRD will not use the file the user is expecting but rather it will use the one in the Virtual Store.
Once we discovered this was going on (thanks to the timely reports from some of our users) we modified the way we handled files in the Program Directory.
Our approach was to relocate any “data” files out of the “Program Files” directory and into the “Program Data” directory. The only files remaining in the “Program Files” directory are executables, dlls and license files. This is all taken care of at installation time (actually this is the only way to do it – you can’t manually reconfigure where the files reside) and is in accordance with Microsoft’s “Best Practices” for programming.
A consequence of this approach is that versions previous to V3.2 of eMRD, eLORA and eMRD Companion should be completely uninstalled with only the license files remaining in the “program Files” directory. The new versions can then be installed.