The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Working Directories in Windows Vista

I was always using WinXP for my applications, but now my customers require Windows Vista. In XP, I was always using C:\Documents and Settings\All users\Application Data\<MyAppName> (accessible through CSIDL_COMMON_APPDATA) for files that my application worked with.

What directory should I use in Vista? I can't access the Documents and Settings directory anymore. CSIDL_COMMON_APPDATA gives me C:\ProgramData on Vista. Should I use C:\ProgramData\<MyAppName> then? It simply looks too simple path compared to the XP one.

Thank you,
Petr Veit Send private email
Thursday, June 14, 2007
To the OP:

Yes, it looks simple but that's it.  Just be sure you still "get there" via CSIDL_COMMON_APPDATA.
B. Afraid
Thursday, June 14, 2007
Some confusion here!

In Win2K and XP, "CSIDL_APPDATA" should be used for per-user, roaming. In Vista, this is the KNOWNFOLDERID constant "FOLDERID_RoamingAppData".

In Win2K and XP, "CSIDL_LOCAL_APPDATA" should be used for per-user, non-roaming. In Vista, this is the KNOWNFOLDERID constant "FOLDERID_LocalAppData".

In Win2K and XP, "CSIDL_COMMON_APPDATA" should be used for per-machine, non-roaming. In Vista, this is the KNOWNFOLDERID constant "FOLDERID_ProgramData".

NB This last folder is normally read-only to non-admin non-power users!
Mark Pearce Send private email
Thursday, June 14, 2007
And this link is of direct relevance:
Mark Pearce Send private email
Thursday, June 14, 2007
Portable applications continue to use the CSIDL_* constants and functions, and restrict themselves to supported folders.

Vista-only applications (which Microsoft hopes we're all writing) can use the new KNOWNFOLDERIS api, and directly access any new folders.

Advanced portable applications can dynamically load the Vista-only functions and use them if available, and fall back to the older functions where applicable.

Hard-coding paths is still always wrong.

Thursday, June 14, 2007
Mark: you say that CSIDL_COMMON_APPDATA is read-only? Should I use some other folder then? I want all users to share the same settings of my software.
Petr Veit
Friday, June 15, 2007
Petr, the recommended approach is to make a sub-folder under CSIDL_COMMON_APPDATA for your app at install-time, and then make that sub-folder explicitly read-write.

But this does mean that your installer will need admin-level permission to run.
Mark Pearce Send private email
Friday, June 15, 2007
I see. I am doing all at startup of my application. I just look if my directory exists and if it contains all the files and all of them are up to date.

Is this read only valid also in WinXP? Honestly, I have never tried to install the SW under admin account, swith to normal user and then run it for the first time. I always ran the application for the first time when still under admin, so the dir was successfuly created.
Petr Veit
Friday, June 15, 2007
Yes, the "normal" pattern is to have an installer that Vista recognizes as such, preferably a .MSI installer package.  The installer should create a folder structure like <company>\<product> under the COMMON APPDATA folder.  Then set the proper ACL on that <product> folder, generally full access.

This is how an installer runs with admin rights in the first place:

"Since installing some applications on a system requires an administrator access token, a mechanism is in place within the Windows Vista operating system to automatically detect the launch of a setup installer. When an application setup is detected, UAC displays an elevation prompt for the user to validate the installation process."

The installer should also create the initial INI, XML, etc. settings files here, at least for global settings.

Per-user settings should go into a similar folder structure under LOCAL APPDATA (variations for roaming profiles, etc.) and would probably be created by first-run for each user.  These should not require elevation.

Files created and consumed by your application that a user might interact with directly (via Explorer, etc.) should generally go under PERSONAL, since they would be considered "documents" in Windows nomenclature.  This is what WinXP calls the "My Documents" folder.

Making this all happen via something like the old VB6 P&D Wizard would require that you customize Setup1.exe.  This is written in VB6 itself, and the source is part of your VS6/VB6 package under VB98\Wizards in your Visual Studio directory under Program Files.  A VB6 developer would probably just move to using Microsoft Visual Studio Installer 1.1 or some 3rd party tool instead.  Those developing in other languages probably already use a more sophisticated tool for building install packages.

Caveat: I haven't done any of this myself yet.  I've been researching it a bit for future reference though and I'd be very interested in actual experiences - i.e. field tested results.
Friday, June 15, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz