page is under construction.
These pages do not discuss Linux, but don't worry! Things are confusing enough when dealing with Windows alone :-) This page deals with installation and configuration of your application, and properly storing user data and program data.
time, MicroSoft has suggested different 'preferred practices'. I've been
looking in the SDK, but couldn't find an easy reference, so this is what
I could figure out.
Where are your special folders located? Try the code below to find out.
; survival guide 4_16_100 special folders
Let me start by offering some links that might be of help...
16.3 Soft paths
First the big one: you can NOT rely on 'hardcoded' paths! Users may have changed any of their settings, the locations of their preferred folders, the names of their preferred folders. Localized versions of Windows may have changed the names of specific folders (for example, the Dutch version of windows did away with 'Startup' and called it 'Opstarten'). And on top not all Windows versions may use the same folders in the future.
If you're looking for a specific path, do not assume it's going to be 'x:\y\z' but query Windows to find the proper path.
Warning: never hard-code a path!
Stay away from C:\WINDOWS. There's nothing there of interest. Don't start copying in your DLL's in there. If there is code that you want to share over multiple applications, each with their own install, use the Program Files \ Common Files folder instead.
This is where your application should go. This is most oftenhandled by an installer, which allows the uneducated masses to install your great application. I've never seen this one localized (but hey, I wouldn't be suprised if even that would be possible :-))
Typically, you'll end up with something like:
C:\ Program Files \ <company> \ <product> \ ...This folder will be created by your installer, at the moment of installation. Your application should not create or modify any files inside this folder, it should only read from it.
If you need a place to store changed data and / or user documents, then either your installer, or your application upon first run, must create those additional folders. If your application uses / creates data that is of no interest to, or should be somewhat shielded from the user, that data should go into Application Data. Documents created by the user using your application should go into My Documents.
A user with admin rights on Windows XP can do whatever he likes in the Program Files folder. Not so once you move up to Vista or Windows 7. The idea behind this is to provide additional protection to system integrity, as the Program Files folder, containing the executables, is no longer accessible (by external programs) it should be harder for malware to get through.
What happens if you would install your software somewhere else? That would depend on the rights assigned to the different folders. On my own machine, I've created a folder called C:\software, and anything which does not try to install in the Program Files folder I'll redirect there. I've also put anything that comes as an archive in there. So, for example, my 'software' folder now contains:
C:\software(As an aside, I've also created a C:\games folder, so I can exclude all games from my regular backup, even those games that try to install in the Program Files.)
Portable software typically comes as a complete package, and can be run from a memory stick etcetera. Often. the main folder would contain all executables, data, configuration files and more. Good portable software should not leave any trace on your system.
<< add more details on installers... perhaps :-) >>
If multiple seperate applications use the same libraries, and you want to make sure each of your applications gets the latest version, or that all your applications use the same version, you can install any files 'shared' between your applications in the Program Files \ Common Files.
There's no such thing as Application Data \ Common Files, so appearently anything installed under Common Files is not supposed to keep its own application data :-) You could always create something yourself, or use the registry.
On my machine, this folder resides here:
C:\ Program Files \ Common Files \ ...
If your application uses / creates data that is of no interest to, or should be somewhat shielded from the user, it should go into Application Data. Application Data can be set up to 'roam', so users on a network get the same settings (application data) whenever they move from one workstation to another. If you don't want that data to reside on the network and / or be shared by multiple workstations, you have to use the Local Application Data folders.
My machine shows something like this:
C:\ Documents and Settings \ <user> \ Application Data \ <company> \ <product> \ <version> \ ...Note to self: add more details, CSIDL_APPDATA, etc.
Just like Application Data, yet any data in here cannot be redirected to the network.
Note to self: add more details, CSIDL_LOCAL_APPDATA, etc.
Any material created by the user should go into the My Documents folder. This folder may be stored on a network volume for roaming users. Typically paths will have the following structure:
C:\ Documents and Settings \ <user> \ My Documents \ ...Note to self: add more details, CSIDL_MYDOCUMENTS etc.
to self: add more details, limitations, references etc.