INIFILE.TXT

                      Discussion of INI Files

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

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.