Discussion of INI Files

By Larry Martin

This is not intended to be a replacement for the normal documentation on INI files, but just a very general orientation explaining the reason I started the development of INIMAINT.

Many, if not all applications that run in any computer environment need to have a place to keep information that is system specific. In a standard DOS environment, every application must define a place for this information and manage it themselves. With the advent of Windows and it's requirement that a lot of Windows information be kept somewhere, a standard file approach was developed. In the original Windows environment this file was called WIN.INI and could contain information about Applications as well as Windows itself. This file was, and still is, a standard ASCII text file and this causes some problems. Specifically, much of the data stored in the file could be more efficiently stored and used if it was in a binary format and, more important, an ASCII file meant that the user could, and almost always did, edit the file. This editing can introduce errors, so the parsing of the file becomes a big problem. Because of formatting and performance problems, some of the standard information needed to run individual programs was still not stored in the INI file, but was stored in individual Program Information Files or PIF files. These iles were binary, thus solving the performance and editing problems, since they were maintained by Windows itself. However, this generated a huge number of tiny files, each one taking an entire allocation unit on the harddisk and generating a significant backup problem. OS/2 takes the concept a step further by making the INI files binary files and incorporating all of the information that Windows stores in the PIF files in the same file. These files OS2.INI, for user information, and OS2SYS.INI, for system information. In addition, a set of OS/2 API's are supplied to manage these files.

The OS/2 INI files are organized on three levels: For example, INIMAINT will create a new Application called "INI File Maintenance" in the OS2.INI file. This is the INIMAINT Application name. One of the Keys that INIMAINT will create is "Current INI" which is used to keep track of which INI file the user is currently working with. The Key value for this Application/Key pair will be the path and filename of the current INI file.
 * 1) The highest level is the Application Name.
 * 2) Within each Application, there is a series of individual entries which are called Keys and identified by a Key name.
 * 3) Associated with each Key name is the actual data for the Application/Key pair or Key value.

Since the files are binary, the performance is reasonable, especially since the files do not have to be accessed that often. In addition, the contents of the files are managed by OS/2, so there is not a problem of parsing the entries to insure that they are properly formatted.

However, this creates other problems. For example, there is no way for a user to even find out what is in the files, even for applications that he has installed. One of the advantages of the fact that the Windows INI files were ASCII and the PIF files were application specific was that they user could install an application on one system and then move it, with customizing, to other systems by moving the PIF files and, sometimes, some entries from the INI files. None of this is possible in an OS/2 environment. Every machine must be customized manually and every change must be made in every system. Further, it turns out that no application, including OS/2 itself, makes any provision for removing obsolete entries from the INI files. Therefore, as you change your OS/2 environment and upgrade or change your applications, the OS2.INI file and OS2SYS.INI files get bigger and bigger as they fill with information that no longer applies to your environment. Finally, since OS/2 always has the User and System INI files open, there is no way to create a backup of these files except during boot time. This normally means you have to keep several layers of copies, since you have to reboot to fix anything.

INIMAINT was developed to address the new problems introduced by the new INI file approach in OS/2. With INIMAINT you can review what is in the files, change it, delete old entries, do complete or partial backups at any time and otherwise have an appropriate level of control over these files.