Windows 7 application data locations 1

[bbuk]

Hi

I have to update my application which has previously run under XP to run on Windows 7 machines. I ran into a problem because my application stores an ini file in the application directory and .rtf output files in a sub folder of the application. I can see by some searching that this is a very common problem but I am having some difficult wading through the masses of information about which is the easiest/best way to implement changes to make sure my application will run correctly on XP and Windows 7.

I am hoping that someone here who understands more of the intricacies than I can hope to will be able to point me in the right direction. The setup is that the machine is not networked so roaming is not required. There is only ever one user set up, and that user is an administrator. The pc is used to interact with a piece of test equipment so only my application is normally installed. The software is installed and maintained by technicians who are not necessarily capable of advanced Windows techniques such as changing user permissions or enabling / disabling UAC etc,

Any pointers or advice about pitfalls would be greatly appreciated.

 

[dilettante]

Well there really isn't a whole lot that is new since these "changes" were effective with the Windows 95 Desktop Update that was part of IE 4.x. As such, pretty much everything you need to know is contained in the MSDN Library CDs that shipped with VB6 and were updated by subscription (free with VB6 product registration) through October 2001.

The fact that Win2K and WinXP appcompat shims plus running as an Administrator or Power User let you continue to write code as if you were still on Windows 95 pre-update was an added bonus. It let people squeak by without doing things correctly.

But Microsoft got beat up in the press about Windows being "insecure" so among other changes starting in 2006 Windows no longer allows such things. The Power Users group is basically gone, and Administrators group users are reined in via UAC's "split token" mechanism.


So to correct an old VB6 application to begin following those 1996 Developer Guidelines generally involves two issues at the most fundamental level, which you have encountered. Both of these issues involve the placement of run-time updated and created files.

The first issue is where to put the files. For an application that does not support roaming there are two basic locations: [CommonAppData] for any per-machine data and [AppDataLocal] for any per-user data. These are symbolic names for "special folders" that may be located in different places depending on the Windows version and administrative actions. To use these special folders your installer is meant to create a subfolder based on CompanyName, and a subfolder under that based on ProductName. Then below that you can put your files or additional subfolders as needed. The idea is to avoid collisions between different applications.

Folders created under [CommonAppData] normally inherit "owner" security. This means the user who creates a file basically has full control and other users get read-only access. If you want different security this is something else your installer must take care of when it creates the folders. This is fairly simple using Windows Installer packages but not something the old PDW supports.

If you have just one user you can limp aling relying on "owner" rights but remember that you have simply left another time-bomb ticking that may go off in the future.

The second issue is how your program finds these locations. For this there is a Shell object with a NameSpace method that accepts a Special Folder constant and returns the corresponding path. Your program can add CompanyName and ProductName sub-levels to this path based on the properties of the VB6 App object - assuming you set these Project properties as you should. Installers generally use a variation of the same method to create your program data folders.

That's pretty much it.

The only other common exception is to use the [Personal] Special Folder (a.k.a. "My Documents"). This is where any file the user interacts with directly should go, i.e. your Open and Save dialogs should default there and allow the user to navigate to the actual desired location.

 

[bbuk]

Many thanks dilettante, you gave me enough information to solve my problem without over complicating things. I have succeeded in my update with the help of this post and a couple of others from you and strongm - it turns out it wasn't so difficult after all!

This is a great community