home *** CD-ROM | disk | FTP | other *** search
/ Hall of Fame / HallofFameCDROM.cdr / pcmag / install.lzh / INSTALL.DOC < prev   
Text File  |  1987-12-18  |  6KB  |  106 lines
  1. USING INSTALL/REMOVE   Normally a TSR utility is loaded simply by 
  2. entering its name at the DOS prompt or as an entry in your
  3. AUTOEXEC.BAT file.  In order to be able to control the 
  4. loading/unloading of each TSR, you must run the INSTALL program before
  5. each TSR (or group of TSRs) is loaded.  That way, pertinent 
  6. information needed for removal can be intercepted and stored away. 
  7. The syntax for INSTALL is:
  8.  
  9.   INSTALL [namelist]
  10.  
  11. where namelist is the name of the TSR utilities comprising the group
  12. about to be loaded.  The namelist parameter is an optional descriptor
  13. containing up to 119 characters; it does not have to match the TSR
  14. filenames.  The descriptor is used in the list of installed utilities
  15. presented when REMOVE is requested to perform a deinstallation.
  16.     The INSTALL utility should be thought of as a sort of 
  17. 'bookmark' applied to the operating system.  When INSTALL is invoked,
  18. it records the current state of the system; Each time REMOVE is run,
  19. it restores the system to the state it was in just before the last
  20. INSTALL.  Any TSR's loaded since the last INSTALL are disabled.  Up
  21. to 32 system states can be docketed.  If you want the ability to
  22. delete TSR's individually, you must run INSTALL before loading each
  23. TSR.  At the other extreme, you could run INSTALL only once, right
  24. after the system power-up, then load all the resident utilities your
  25. system can hold.  Then a single call to REMOVE would purge them all.
  26.     The following sequence (which might be included in an
  27. AUTOEXEC.BAT file) installs four resident programs.  TIMEKEY and
  28. FREEZE, a pair of utilities that appeared in PC Magazine's own 
  29. Programming/Utilities column, are each preceded by INSTALL, so they
  30. can be deleted one at a time.  SuperKey and SideKick, the venerable
  31. Borland utilities, are loaded consecutively so that they will be
  32. erased as a group:
  33.  
  34. INSTALL TIMEKEY
  35. TIMEKEY
  36. INSTALL FREEZE
  37. FREEZE
  38. INSTALL SUPERKEY SIDEKICK
  39. KEY
  40. SK
  41.  
  42. Eliminating the last TSR or group of TSR's is as simple as running
  43. REMOVE.  REMOVE displays a list of utilities currently installed (by
  44. echoing the descriptive names you typed in on INSTALL's command line)
  45. and prompts you to verify by pressing the Enter key.  If the four
  46. utilities had been installed as shown above, running REMOVE would
  47. produce the following display:
  48.  
  49. Number of installations: 3
  50.  
  51. TIMEKEY
  52. FREEZE
  53. SUPERKEY SIDEKICK
  54.  
  55. Press ENTER to remove, ESC to abort
  56.  
  57. If you press the Enter key, the last group, SuperKey and SideKick,
  58. will be released from memory.  Pressing the Esc key simply terminates
  59. the deinstallation harmlessly.  Successive utilities may be deleted
  60. through successive calls to REMOVE.  Running REMOVE a second time in
  61. the example above would show only two installations recorded, with
  62. FREEZE the topmost TSR queued to be deleted next.
  63.     It's perfectly legitimate to load more TSR's than was 
  64. indicated in the namelist parameter.  REMOVE will still delete 
  65. everything entered since the last INSTALL.  REMOVE's list of installed
  66. utilities, however, only reflects those designated on INSTALL's 
  67. command line.  If you choose, you can even leave the command line
  68. empty.  It's usually convenient, however, to have an accurate list of
  69. TSR's presented every time you run REMOVE.
  70.     INSTALL is itself a short memory-resident utility.  Every time
  71. it's called it consumes about 1600 bytes of memory, but, more 
  72. importantly, it inserts a resident "wedge" in memory that contains a
  73. complete copy of the PC's interrupt vector table.  A utility not
  74. preceded somwehere in memory by one of these wedges cannot be
  75. removed.  REMOVE recovers both the the memory used by the programs it
  76. unloads and the memory dedicated to their identifying wedge.
  77.     INSTALL answers the command to load additional groups beyond
  78. the limit of 32 with the message "No room for more."  Likewise, when
  79. REMOVE is executed with no TSR's installed, it responds with the
  80. warning "None installed."  Resident programs can be freely INSTALLed
  81. and REMOVEd as many times as you wish.  In addition, there's no limit
  82. to the number of TSR's you can place in a group.
  83.     Note that programs (or groups of programs) can only be deleted
  84. in the reverse order in which they were installed.  The removal of an
  85. intermediate one would create all sorts of problems, one of which
  86. would be the tricky proposition of moving all resident routines above
  87. it down in memory to fill the hole, rerouting all appropriate 
  88. interrupt vectors to the modified addresses, and altering any
  89. references to absolute addresses.  Unfortunately, that's next to 
  90. impossible. If you have to purge a set other than the one most 
  91. recently loaded, run REMOVE as many times as necessary to regress to
  92. the one targeted, then reinstall the ones above it.
  93.     It's also legal to run REMOVE immediately after INSTALL, with
  94. no TSR's loaded in between.  The wedge left by INSTALL will be
  95. erased.  In fact, although there's no obvious reason to do so, you
  96. can run INSTALL several times in succession, then reverse the action
  97. a layer at a time.  You may also run other applications, if you 
  98. prefer, between the time INSTALL is invoked and a TSR is loaded.
  99.     In the unlikely event that you encounter a "Deinstallation
  100. failed" warning in the course of removing a TSR, you should probably
  101. reboot the system.  It's possible you might encounter no adverse side
  102. effects without the reset, but it's also possible that down the road
  103. somewhere (and at the worst possible time) execution might skid to a
  104. halt with a critical memory allocation error.
  105.  
  106.