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

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 are the 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, UNIMAINT will create a new Application called "INI File
Maintenance" in the OS2.INI file. This is the UNIMAINT Application
name. One of the Keys that UNIMAINT 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.

UNIMAINT was developed to address the new problems introduced by the
INI file approach in OS/2. With UNIMAINT 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.
