home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 8 / CDASC08.ISO / VRAC / INIMT21F.ZIP / INIFILE.TXT < prev    next >
Text File  |  1992-08-13  |  5KB  |  82 lines

  1.      
  2.                            INIFILE.TXT
  3.  
  4.                       Discussion of INI Files
  5.  
  6. This is not intended to be a replacement for the normal documentation
  7. on INI files, but just a very general orientation explaining the
  8. reason I started the development of INIMAINT.
  9.  
  10. Many, if not all applications that run in any computer environment
  11. need to have a place to keep information that is system specific. In
  12. a standard DOS environment, every application must define a place for
  13. this information and manage it themselves. With the advent of Windows
  14. and it's requirement that a lot of Windows information be kept
  15. somewhere, a standard file approach was developed. In the original
  16. Windows environment this file was called WIN.INI and could contain
  17. information about Applications as well as Windows itself. This file
  18. was, and still is, a standard ASCII text file and this causes some
  19. problems. Specifically, much of the data stored in the file could be
  20. more efficiently stored and used if it was in a binary format and,
  21. more important, an ASCII file meant that the user could, and almost
  22. always did, edit the file. This editing can introduce errors, so the
  23. parsing of the file becomes a big problem. Because of formatting and
  24. performance problems, some of the standard information needed to run
  25. individual programs was still not stored in the INI file, but was
  26. stored in individual Program Information Files or PIF files. These
  27. files were binary, thus solving the performance and editing
  28. problems, since they were maintained by Windows itself. However, this
  29. generated a huge number of tiny files, each one taking an entire
  30. allocation unit on the harddisk and generating a significant backup
  31. problem. OS/2 takes the concept a step further by making the INI
  32. files binary files and incorporating all of the information that
  33. Windows stores in the PIF files in the same file. These files
  34. OS2.INI, for user information, and OS2SYS.INI, for system
  35. information. In addition, a set of OS/2 API's are supplied to manage
  36. these files.
  37.  
  38. The OS/2 INI files are organized on three levels:
  39. 1. The highest level is the Application Name.
  40. 2. Within each Application, there is a series of individual entries
  41.    which are called Keys and identified by a Key name.
  42. 3. Associated with each Key name is the actual data for the
  43.    Application/Key pair or Key value.
  44. For example, INIMAINT will create a new Application called "INI File
  45. Maintenance" in the OS2.INI file. This is the INIMAINT Application
  46. name. One of the Keys that INIMAINT will create is "Current INI"
  47. which is used to keep track of which INI file the user is currently
  48. working with. The Key value for this Application/Key pair will be the
  49. path and filename of the current INI file.
  50.  
  51. Since the files are binary, the performance is reasonable, especially
  52. since the files do not have to be accessed that often. In addition,
  53. the contents of the files are managed by OS/2, so there is not a
  54. problem of parsing the entries to insure that they are properly
  55. formatted. 
  56.  
  57. However, this creates other problems. For example, there is no way
  58. for a user to even find out what is in the files, even for
  59. applications that he has installed. One of the advantages of the fact
  60. that the Windows INI files were ASCII and the PIF files were
  61. application specific was that they user could install an application
  62. on one system and then move it, with customizing, to other systems
  63. by moving the PIF files and, sometimes, some entries from the INI
  64. files. None of this is possible in an OS/2 environment. Every machine
  65. must be customized manually and every change must be made in every
  66. system. Further, it turns out that no application, including OS/2
  67. itself, makes any provision for removing obsolete entries from the
  68. INI files. Therefore, as you change your OS/2 environment and upgrade
  69. or change your applications, the OS2.INI file and OS2SYS.INI files
  70. get bigger and bigger as they fill with information that no longer
  71. applies to your environment. Finally, since OS/2 always has the User
  72. and System INI files open, there is no way to create a backup of
  73. these files except during boot time. This normally means you have to
  74. keep several layers of copies, since you have to reboot to fix
  75. anything.
  76.  
  77. INIMAINT was developed to address the new problems introduced by the
  78. new INI file approach in OS/2. With INIMAINT you can review what is
  79. in the files, change it, delete old entries, do complete or partial
  80. backups at any time and otherwise have an appropriate level of
  81. control over these files.
  82.