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.
_______________________________________________
Ethereal-dev mailing list
[EMAIL PROTECTED]
http://www.ethereal.com/mailman/listinfo/ethereal-dev
