Configuration architectural antipatterns

I've got the flu, these days: and in fever's drowsiness has surfaced the memory of an application I've worked on six years ago.

It was an aged application, developed by a former employee using Visual Basic 6 - uh! oh!

I was doing only fixes and small enhancements on that application, but I'll remember it forever due to its bright and genial configuration-relating design.

That application's configuration, as was the case also for other applications by the same author, was "designed" around the Multiple Configuration Points conceptual antipattern: it wasn't stored in a single, well defined, simple accessible place, but in multiple, differently implemented respositories:

• part of the configuration was read from an "ini" file: the file was processed without using some kind of library, but reading the raw input and counting rows: at row #X, parameter Y - oh, yeah!
• the remainder part of configuration cames from a MS Access File (may god forgive him! - if a god exists) and was accessed using OLE DB support and SQL queries (this part of the configuration was modifiable through the application itself)

So, in one application, and only with regard to configuration management, you can list several architectural antipatterns:

1. Multiple Configuration Points: configuration spawned in multiple, heterogeneous repositories
2. Reinventing The Wheel: "ini" file read through home-made procedure
3. Brittle configuration: formatting-depandant "ini" file semantics
4. Tightly coupling to external libraries versions: MDB configuration file could be read without errors  only when the MS Access' version on the host machine was the version for which the application was compiled - otherwise, the application wasn't ever able to start. And if the MDB file was modified using a most recent version, it became unreadable for the application...

And - final masterpiece: that application, which used relational DB for (partial) configuration management, did not use any type of database for business data storage and inter-application communication purposes: data storage was performed writing sequental text files with fixed-length records, and applications interested in data interchange read the same files (code reading and writing records was naturally duplicated between applications, not extracted in a common library).

I've got the flu, these days... but even conceive of such an architecture must have required a great fever... isn't it?