I notice that I have a tendency to set out to write multi-part (“to be continued next week”) blog posts and then move on to something else and never come back and write the next part. Now that I have finished the upgrade to EP Office I am happily back working on my Linux partition, and memories of Vista troubles are already rapidly fading. Nevertheless, the crux of the problem I was having with Vista was not really directly UAC related (see Part I if you don’t know what UAC is, or as an alternative try to install software on you Vista computer and wait until the screen goes dark and a thud sound occurs and you are prompted to confirm that you really want to do what you just asked the computer to do), but rather had to do with the difficulty of installing a database application on a Vista machine. There is still no good “single user” installation option on Windows (supposedly will be with Windows 7), so applications are installed as “single-machine” installations. The immutable parts of the installation should go to the Program Files folder, the read-only registry keys to HKEY_LOCAL_MACHINE, and then, what about the rest? Well, customization stuff that will vary by user should clearly go to the individual user’s home folder, their local application data folder and document folders, and to HKEY_CURRENT_USER in the registry. What about shared data? Well, on XP the All Users folder in Documents and Settings could store application data, or, what was more commonly done, just stick all that stuff in the Program Files folder. Since every user was an administrator, it didn’t matter. Vista has a ProgramData folder for shared data. Surely I could put my database there and thus allow multiple users on a single machine to access it. WRONG! It turns out only the original installing user has read and write access to whatever is installed in that folder, all other users can read the data, but can’t change it! Note here that I am not even talking about the backend database for the program. It is actually located on a remote server. It is the frontend Access database that for various reasons has to have read and write permission for the program to work that I was trying to find a good home for. It is possible to change the ACL (Access Control List) of the files in the ProgramData folder, but what a pain in the butt! So what did I do? I put the frontend, mutable Access database file in the user AppData folder. Thus the program can only be run by whatever user installed it on each machine. (It can be run by other users if the “Run As Administrator” option is used, but there is something vile about doing this and changing files in another user’s AppData folder). I considered an option that I think would work as an alternative: Have a central location for the the frontend database file (ProgramData folder?) and when each user tries to run the program, if the frontend is not present in his or her own AppData folder, the frontend will automatically be copied into the AppData folder. It is not important that the same frontend database file be used by each user, the only reason it has to be writable has to do with substituting the window icon from the default Access icon to the EP Office icon which has to be done at runtime. I’m sure this would work, but, at least for now, the process was rejected as too cumbersome.
So there you have it. Hoops jumped through to avoid unnecessary UAC prompts, to prevent under the table virtualization of your program folders (a whole other feature of Vista which I glossed over), and basically to make something work under Vista that worked without problems under XP. Now that I sorta understand how this all works with Vista, I’m sure I’ll have to learn how to jump through more hoops with W7.
