Smarter Data Storage

If my application needs to store information, should I use my application folder?


August 03, 2004
URL:http://drdobbs.com/smarter-data-storage/184405751

wqa_template


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:

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:

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].

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.