Data Files Location in Vista 1

[TOMBUGGY]

I have a VB6 app created on a Windows XP system for which I use the Package and Deployment Wizard to create a Setup file that installs the program in DriveLtr\Program Files\PMM (e.g. in C:\Program Files\PMM). I wish to have data files created by the app in the same folder as the program.

This works fine under Windows XP but under Vista the data files are stored in:

C:\Users\Tom\AppData\Local\VirtualStore\Program Files\PMM

I suspect that this has something to do with Vista's screwy security features. Is there any way to get around it?

Related to this I created a small VB6 app on a Vista system to test possibilities for locating the data files. I simply tried to write a sequential file to App.Path but the file got written to the Users area as above. Further, when I tried to compile (Make .exe) the app under VB I got a message saying that I "can't save files to this location" and to see the Administrator. I AM the Administrator. What's up with this?

Thanks.

 

[Tom4511]

Your suspicions are correct.

Writing data is not permitted to the Program Files directory in Vista or the forthcoming Windows 7.

You will need to create an application folder in the Common Application or User Application Directory.

Much has been written about this and searching VB6 and Vista will turn up information on this and even more anomalies for your dining and dancing pleasure.

 

[dilettante]

Please note that this is because newer versions of Windows merely enforce rules that once were merely guidelines.

If your program are marked as aware of the new requirements they would be terminated for trying this. Since they are detected as legacy software instead, Windows will redirect the I/O to virtualized locations as you are seeing. This is one form of application compatibility shim meant to make it more likely an old-style program can be run on newer versions of Windows.

As Tom4511 states above this is now a very old story. It dates back to the Vista beta programs of 2006 when information on the topic was first published. You might try going through some of the materials on the subject that are still available: Dev Readiness: Files Library.


The PDW is no longer adequate for creating setup packages for Windows. A program's per-machine read/write data should be put into a folder created under ProgramData (also called CommonAppData) with the necessary permissions set on it during installation.

While you might create a patched Setup1 to address most of this, the Wizard itself does not expose the new options for you to select among them as they are required. For example the Wizard cannot be extended to offer the $(CommonAppData) file location macro nor present a folder permissions dialog.

You might hand-edit Setup.lst after the Wizard creates it though. Then use a modified Setup1 that will properly interpret and act upon your extensions to create and set permissions on your $(CommonAppData) subfolders.


I typically use Visual Studio 6.0 Installer 1.1 that replaced the PDW back in 2000 (following 1998's VSI 1.0). A quick overview can be seen at Create installations with Visual Studio Installer.

But even this requires a post-build step to add LockPermissions table entries. A newer Visual Studio version's "installer project" type may address this more directly, or you might look at 3rd party packagers that provide more extensive support for newer Windows Installer options.

Some free alternatives include MAKEMSI and WiX but I have not used them myself.


Keep in mind that VB 6.0 was released when Windows 98 and NT 4.0 were current. While service packs and tools were released as a stopgap to accomodate Win98 SE, WinMe, Win2K, and WinXP... we never got the true VB 7.0, 8.0, etc. that would have addressed changes in the Windows ecosystem over time.

This means we need to stay aware and innovative on our own, with only very limited support from Microsoft as the years go on. Remember the VB6 theme song: We Are the Champions - Queen (YouTube).

 

[TOMBUGGY]

Thanks for the outstanding replies. We have been "getting away with" using the PDW because we have mostly non-complex apps that run on standalone (non-network) computers and a very unsophisticated set of customers, very few of whom use Vista and those who do know little or nothing about Vista's data files conventions and permissions.

The reason we have placed data files in the same folder as the app is for user simplicity in finding the files if they need to send them to us for support purposes. We recently had our very first situation of a user trying to find the data files on a Vista syatem - thus, my original post.

I guess we have three alternatives for retaining the simplicity:

1. Providing instructions for finding the files (undesirable because it's not simple for most users who resist "education").

2. Install the apps outside of Program Files so that the data files can be placed in the same folder as the app (which violates Microsoft security conventions/rules).

3. Keep the app in Program Files and reprogram to create our own data files folder and place files in it. That way we could direct the user to a simple folder path for the data files.

BTW, with respect to PDW alternatives we have used InnoScript and the Inno Setup Compiler successfully for a complex app that can be used in a network environment.

 

[dilettante]

We've all been here. As you say this was common practice by most programmers for a long time. Some of us ran into it earlier I suppose, since it is not just an issue in Vista but anywhere that the "Program Files" directory is secured against user writes.

I don't understand your alternative #1 above. I thought we were talking about files the program uses and the user never touches or operates upon directly.

Alternative #2 is a possibility, and Microsoft even suggests this as a last resort for programs that frequently self-update (games and such) but with warnings that it provides a malware vector. Actually in Windows 7 they have even "blessed" it for some per-user installation cases by creating a new folder: a "Programs" folder under LocalAppData.

See Deploying Your Application with Windows Installer (MSI) and ClickOnce (.PPTX file).

With alternative #3 I'd have to ask where you'd put this folder. However it does appear that an unelevated process can create a folder under the boot drive root and use it now (Vista SP1?) though I thought this had been prohibited in Vista initially.

 

[TOMBUGGY]

dilettante, thanks for another informative post. As for Alternative #1, the user does not usually touch or operate on the data files as part of app operation. Again, our purpose is to enable the user to easily find these files for the purpose of sending them to us for support purposes.

As for Alternative #3, we would create the folder under the root drive (e.g. C:\) and we have done so successfully in a test app run on a Vista system.

 

[dilettante]

It still feels a little awkward to me, but it seems to solve the problem. Hard to complain about that!

Remember that not all systems have a C:\ drive anymore though, and when C:\ exists it might not be the boot drive. For us ProgramData seems to work well and it should be as easy for users to navigate as Programs is. And you know where it points, unlike using C:\ which could be the boot drive for another OS on a multiboot system.

To repeat for others reading this: It appears that Vista restricts standard users from creating or altering files in the system drive root, but creating and using folders there is just fine.

Big news? No. But useful to be aware of.

 

[TOMBUGGY]

dilettante, an insightful post, as usual. C:\ is an example. Actually, what we do is take the leftmost character of App.Path to determine the drive on which the program is installed, and than use that drive letter to create the folder for the data files.