We do NOT recommend:

Hardcoding constants which may vary during the lifetime of the package.

For example, although you may think that your database server name is written in stone, it will change one day. And on that day you might not feel like recompiling with a new constant.

Having only a single configuration file.

For example, if you store so much as a single absolute folder name in your single configuration file, you are running a security risk if the whole configuration file is accessible to the wrong people.

Putting configuration into the Windows registry.

Oh yes, the registry is so scary, end-users will never dare to go in there. But... the registry is vulnerable to malware, software upgrades/patches gone awry (no, never!), and how exactly do you back it up? Why would you put super critical configuration information into a place which cannot be backed up trivially?

And the Windows registry is for Windows... it is not a cross-platform solution.

Configuration Starting Point

In this section, we discuss the specific topic of tried-and-abandoned ideas for the configuration starting point.

Same folder as EXE (compiled binary)

This popular location needs to be ruled out if you want to support components which may run from unusual environments, namely buried within a dynamically linked library (.dll, .bpl, .so) associated with an executable, compiled binary in another folder.

For example, if you happen to develop components for Borland Delphi (as we do), and you want your components to be able to initialize themselves while they are "running" on a form in design mode within the Borland Integrated Development Environment, then you would not want to use the "same folder as executable compiled binary" because that folder is the one containing Delphi (or Kylix, or C++Builder), not containing the program being built...

Another example of when this does NOT work at all is when two or more programs, in two or more folders, want to SHARE a single configuration file.

Operating System Folder

Why not? Because after years of use, the OS will be upgraded, changed, lost due to hard disk failure, and at that moment you may realize that you never did back up those miscellaneous INI, XML, CFG files which controlled your software package(s).

Also, the OS folder may have restricted rights, making it difficult for users to change settings in the configuration file.

The Windows Registry

Why not? It is not cross-platform, it can be targeted easily by malware, it is difficult to back up (the registry tends to be a large data file, the backup itself is difficult to learn, and the data is not plain-text, and cannot be easily restored).

Humor... on the bad idea theme...

This web site content is licensed under a Creative Commons Attribution 2.5 License. The ZaphodsMap web site is published by HREF Tools Corp. If you use ZaphodsMap, please mention ZaphodsMap.com at least once in your software source and at least once in your software documentation. All other trademarks are the property of their respective owners.