Discussion of INI Files: Difference between revisions

From OS2World.Com Wiki
Jump to navigation Jump to search
Created page with "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 th..."
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
By [[Larry Martin]]
By [[Larry Martin]]


This is not intended to be a replacement for the normal documentation
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.
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
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.
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:
The OS/2 INI files are organized on three levels:
1. The highest level is the Application Name.
# The highest level is the Application Name.
2. Within each Application, there is a series of individual entries
# Within each Application, there is a series of individual entries which are called Keys and identified by a Key name.
  which are called Keys and identified by a Key name.
# Associated with each Key name is the actual data for the Application/Key pair or Key value.
3. Associated with each Key name is the actual data for the
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.
  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 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.  
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
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.
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
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.
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
[[Category:Technical‎]]
backups at any time and otherwise have an appropriate level of
control over these files.

Latest revision as of 17:30, 29 March 2020

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:

  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.