On Feb 3, 2004, at 1:23 PM, Olivier Biot wrote:
I'm not saying that it is a MUST requirement; however I see on my PC
running WinXP Home that Adobe Reader, Quicktime, Symantec, MSN
Messenger 6 are applications with configuration data in the "Documents
and Settings/All Users/Application Data" directory. I see this more as
a cosmetic thing to "fix", but I do not know the *exact* rules
stipulated by Microsoft (except from the "put all in registry").
Well, according to
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
dnw2kcli/html/w2kcli_chapter4.asp
in "Application Specification for Microsoft Windows 2000 for Desktop
Applications":
Using Application Data Folders
The CSIDL values described here provide a consistent, unified way to
access the physical paths to the desired folder locations, independent
of the operating system. The preferred API is SHGetFolderPath, because
it behaves consistently across all versions of Windows. To access the
path for application data, applications should call SHGetFolderPath
with the appropriate CSIDL and then append [company name]\[product
name]\[version] to the returned path.
Specifically, to retrieve the CSIDL _APPDATA path:
TCHAR szAppData[MAX_PATH];
…
hr = SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szAppData);
When storing application data in the user profile, applications should
use the same hierarchy under Application Data and Templates as is used
in the registry:
[User Profile]\
Application Data\
[company name]\
[product name]\
[version]\
[file or folder]
Data Type Folder CSIDL Folder Location
Per user, roaming CSIDL_APPDATA [user
profile]\Application data
Per user, non-roaming CSIDL_LOCAL_APPDATA [user profile]\Local
Settings\Application data
Per machine (non-user
specific & non- roaming) CSIDL_COMMON_APPDATA All Users\Application
data
o CSIDL_APPDATA
As part of the User profile, this folder will roam. Use this folder to
store all user-specific application preferences. For example, if a user
can specify a custom dictionary to be used in your application, you
should store it here. That way if the user roams from computer to
computer, their dictionary will roam with them. This also allows other
users to have their own individual custom dictionaries.
o CSIDL_LOCAL_APPDATA
This folder is for application data that does not roam. It is still
part of the User profile, so this is still per-user information.
Application data that is machine-dependent, such as user specified
monitor resolution, should be stored here. This data must not roam
because different machines have different monitors. In addition, large
blocks of data which can easily be re-created should be placed here to
minimize download time that is incurred when roaming. For example,
Internet Explorer keeps its cache of downloaded html/gif pages here so
that they don't roam with the user. But the smaller cookie and history
lists are stored in CSIDL_APPDATA so that they roam.
o CSIDL_COMMON_APPDATA
This folder should be used for application data that is not user
specific. For example, an application may store a spell check
dictionary, a database of clip-art or a log file in the
CSIDL_COMMON_APPDATA folder. This information will not roam and is
available to anyone using the computer. By default, this location is
read-only for normal (non-admin, non-power) Users. If an application
requires normal Users to have write access to an application specific
subdirectory of CSIDL_COMMON_APPDATA, then the application must
explicitly modify the security on that sub-directory during application
setup. The modified security must be documented in the Vendor
Questionnaire.
which suggests that not only should global settings files go in
CSIDL_COMMON_APPDATA, so should all the *other* non-executable files we
now install in the installation directory!
However, this page:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
shellcc/platform/shell/reference/enums/csidl.asp
says of CSIDL_COMMON_APPDATA that known only to version 5.0 of the
Shlwapi.dll:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
shellcc/platform/shell/programmersguide/versions.asp
so if we used the appropriate Shell API's to get it, we'd somehow have
to deal with systems with older versions of those APIs.
