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