Since that short yet dynamic speech by Lincoln, programmers have sought a convenient way to maintain configurable values in their applications. In the early days of MS-DOS development, it was a configuration free-for-all; each program provided its own settings system. Many applications needed no specialized configuration, but those that did often stored configuration settings together with the application's managed data, all in proprietary ".dat" files.
With the advent of mainstream Windows development, Microsoft introduced file-based settings management through its application programming interface (API). The "private profile" API calls (GetPrivateProfileInt, GetPrivateProfileString, SetPrivateProfileString, and a few others) supplied a standard way to store short configuration values in an open and easy-to-understand text file format. Microsoft used these "INI" files (named for their ".ini" file extension) for its own configuration. A few of these files still reside in your system's Windows folder. (Visual Studio 2005 even installs a couple of them for its purposes.) Here's the content I found in my system's win.ini file.
; for 16-bit app support [fonts] [extensions] [mci extensions] [files] [Mail] MAPI=1 [CDWINSETUP] AUTOUNLOAD=No [MSUCE] Advanced=0 CodePage=Unicode Font=Arial
The format of an INI file was simple to understand. Each file included named sections defined within square brackets, as in "[fonts]." Each section maintained a set of key-value pairs in the form "key=value." The format was simple enough that anyone could use Notepad to make changes. It wasn't even that hard for a program to write its own INI-file management routines, but having them included in the Windows API made them that much more attractive.
But then came the clutter. With so many programs opting to store their configuration files in a known central location, the Windows folder quickly became the file equivalent of Grand Central Station at 5:00 p.m. on a Friday. Speed was an issue too, because the constant parsing and rewriting of INI files consumed precious CPU resources.
Microsoft came up with a solution: the registry. This hierarchical database of key-value pairs cleaned up the file system and brought speed improvements to configuration management. It also added new administrator-defined security settings for access to the registry, and provided support for some limited strongly-typed data. But the new API features weren't the most intuitive (although Visual Basic did include simple commands, such as GetSetting, that provided limited access to registry keys and values).
The registry threw technology at the configuration values problem, but it wasn't a full triumph. With so many vendors stuffing gobs of data in the registry, bloat once again became an issue. And with the system managing all access to the registry, the larger the registry, the worse the performance.
.NET's initial release included application-specific configuration files, a sort-of return to those days of INI-file yesteryear. In some ways, "app.config" and "web.config" files were better than INI files because they contained structured XML content. But big whoop. INI files had structure, and you could update them in Notepad. .NET config files were notoriously difficult to update, either within a .NET application or externally in Notepad (due to some weird caching issues). Also, .config files had neither the security nor the strong data typing available in the registry.
Configuration settings have been giving programmers at least some level of angst since Windows first appeared. But Visual Basic 2005 seeks to change all that with a new and improved settings system.