Actually, the answer is no, you shouldn't. Although in the past (particularly pre-Win95) it was common to store application data in the application folder, this is no longer considered a good practice. Doing so presents a variety of problems to end users:
- They may be operating within limited user accounts that don't permit writing into particular directories such as "Program Files. If the application was installed there by a user with higher privileges (such as an IT administrator), the user would not be able to save necessary information to the folder.
- It doesn’t support roaming of user accounts.
- It makes backup of user data more difficult because the data is commingled with application files.
- It makes it more difficult for multiple users to share the same computer.
Looking over the set of issues, the first one is probably the most critical in today's environment. As computers have become more networked and the potential for the spread of viruses and other damaging software has increased, many corporations have instituted a policy of reducing user account rights to the bare minimum necessary to operate a set of approved applications. An administrator installs the applications on a workstation and sets up a limited user account. An end user then uses the applications and deposits any created data in an approved and safe location.
Applications that are older and were migrated from the Win 3.x platform likely have the most problems complying with not writing into the application folder. Back then it was common to create application "INI files and other such artifacts that contained both user settings and application data. These were placed in the application folder or sub-folders. When Windows 95 was released and the concept of an operating-system supplied user folder became available (called MyDocuments), applications were expected to begin using this location as their default storage location for user data.
In addition, there were other system-supplied areas created to support storage of application-wide data that wasn't user generated. These areas include the Registry and the Common Application Folder. However, to ensure that applications used a consistent approach to decide when to use a particular location to store data, Microsoft developed some basic rules to assist developers. To begin, application data should be separated into one of the following groups:
- Per user, non-roaming
- Per user, roaming
- Per computer (non-user specific and non-roaming)
If the data to be saved is per user, non-roaming then use the user profile\Local folder if more than 64K of data is to be stored. The registry can be used (under the Current User key) if it is less than 64K.
If the data to be saved is per user, roaming then use the user profile\Application Data folder if more than 64K of data is to be stored. The registry can also be used (under the Current User key) if it is less than 64K.
If the data to be saved is per computer, then use the common application data folder (i.e., All Users\Application Data).
However, since these folders may be in different locations from machine-to-machine, the Win32 SDK provides APIs to determine their correct values at runtime, which ensure that your application will work properly in a variety of configurations. To access the definition of MyDocuments, the Application Data folder, and so on, use the SDK function SHGetFolderPath. It takes several parameters, the most important of which is an integer that defines the type of environmental folder to retrieve. You can refer to the SDK for more information of this function and the valid set of values, but for our purposes, to access the MyDocuments folder, you'd pass in the CSIDL_PERSONAL value to get the physical path to this folder. To get the Application Data folder, you'd pass in CSIDL_APPDATA.
Following Microsoft's guidelines on proper storage of application and user-generated data ensures that your application will run correctly regardless of the type of environment it may be run in. The biggest challenge may be in retrofitting an older application to follow these rules. However, you can get the complete set of things you should review in your application in the Microsoft document Designed for Windows XP spec v2.3, which you can find on the Internet at http://www.microsoft.com/winlogo/software/default.mspx.
Mark M. Baker is the Chief of Research & Development at BNA Software located
in Washington, D.C.
Do you have a Windows development question? Send it to [email protected].
