home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / programs / acorn / riscos3 / support / !Patch / ReadMe < prev    next >
Encoding:
Text File  |  1991-09-12  |  10.1 KB  |  247 lines

  1.  
  2. Writing patch definitions for !Patch.
  3. -------------------------------------
  4. It is recommended that any patch files supplied seperately from !Patch be
  5. neatly bundled into an application directory which Filer_Runs them all for
  6. you when you double click on it. In this way a path variable can be set up
  7. for the directory, allowing unambiguous yet directory and filing system
  8. independent file paths to be quoted for accessing other patch files,
  9. transform files and *commands.
  10.  
  11. Directory verification.
  12. -----------------------
  13. When writing patch files, you should remember that !Patch needs to be able
  14. to verify that the correct application directory is being dealt with. So
  15. for example the sole purpose of the patch may be to put a !Sprites22 file
  16. into the application directory, but this will not be sufficient for
  17. !Patch to be certain that it is patching the correct directory. The best
  18. way is to specify some words in the !RunImage that !Patch can verify. It
  19. will then only move the !Sprites22 file in if the words in the !RunImage
  20. match.
  21.  
  22. There should always be some words, bytes or strings in a patch that
  23. actually change (or a file which is created or deleted). If not, !Patch
  24. cannot tell the difference between a directory which has had the patch
  25. applied to it and one which has not. This is not a particularly great
  26. restriction - there is always a version number in some file or other
  27. that should be modified anyway.
  28.  
  29. File extension.
  30. ---------------
  31. It is possible to extend the file being patched, simply by specifying
  32. ChangeWord commands which are off the end of the file. In this case, the
  33. old bytes should be specified as &00.
  34.  
  35. Patch file format.
  36. ------------------
  37. The BootStrap patch file inside !Patch is read on startup, which causes the
  38. patch files stored inside the Patches sub-directory to be read. Patch files
  39. should have a filetype of Patch (&FC3). Files with any other filetype will
  40. be ignored.
  41.  
  42. The patch files are textual in nature. Each line of a patch file can
  43. be one of:
  44.  
  45.     blank
  46.     start with a # to be a comment line
  47.     of the form Command:other parameters
  48.  
  49. Blank and comment lines are ignored.
  50. Other lines have the following meanings:
  51.  
  52. PatchesDir:<file or directory path>
  53. This causes the path specified to be recursively scanned for more patch
  54. files. This is typically used so that you only have to Filer_Run one
  55. patch file (eg. Filer_Run MyPatch:StartUp) in your !Run file to get
  56. !Patch to automatically find all the patch files in the directory
  57. specified.
  58. eg.
  59. PatchesDir:Patch:Patches
  60.  
  61. TransformsFile:<file path>
  62. This adds the file specified to the list of files looked in to build the
  63. *commands for performing transformations.
  64. eg:
  65. TransformsFile:Patch:Transforms
  66.  
  67. Application:<program name> <file type>
  68. This introduces some patches for the named application.
  69. eg:
  70. Application:!PCEm &2000
  71.  
  72. Description:<program description>
  73. This is a textual description of the application.
  74. eg:
  75. Acorn PC Emulator
  76.  
  77. Patch:<patch name>
  78. This introduces a patch and gives it a textual name. This name will be what
  79. is quoted in the patch query window.
  80. eg:
  81. Patch:Fix bug in version 1.60 with DOSDisc hard disk images
  82.  
  83. File:<file name> <file type>
  84. This introduces some patches for the named file in the application. Note
  85. that the file name quoted should always start with the application directory
  86. - this allows individual files to have patches for them.
  87. eg:
  88. File:!PCEm.!RunImage &FF8
  89.  
  90. Transform:<transform>
  91. This optional field indicates that the file has had the named transform
  92. applied to it. The patches will be applied to the untransformed form of
  93. the file. A list of default transforms can be found in the Transforms
  94. file of !Patch. Currently this is Squeeze, and do nothing (Copy).
  95. eg:
  96. Transform:Squeeze
  97.  
  98. Location:<location>
  99. This indicates the byte location in the unsqueezed (or whatever) file for
  100. the following changes. To specify in decimal just give the number. To
  101. specify in hex prefix the number with an &. The location is always in the
  102. unpatched file. Where the patched file ends up with a differentĀ length,
  103. appropriate adjustments are made to the location in the target file.
  104. Effectively this means that two locations are maintained.
  105. eg:
  106. Location:&1B2D0
  107.  
  108. ChangeWord:<from> <to>
  109. This describes the change required to a single word at the current location.
  110. Location advances by four each change, so you may give a sequence. The
  111. current location should be word aligned (a multiple of four) when this
  112. keyword is specified.
  113. eg:
  114. ChangeWord:&059D0008 &13500003
  115. ChangeWord:&028DD010 &13A00000
  116. ChangeWord:&13A00000 &059D0008
  117. ChangeWord:&128DD010 &E95BA800
  118.  
  119. VerifyWord:<word>
  120. This specifies that the word at the current location must match the word
  121. specified. The locations are advanced by four.
  122. eg:
  123. VerifyWord:&54230001
  124.  
  125. ChangeByte:<from> <to>
  126. This describes the change required to a single byte at the current location.
  127. Location advances by one each change, so you may give a sequence.
  128. eg:
  129. ChangeByte:&BD 65
  130.  
  131. VerifyByte:<byte>
  132. This specifies that the byte at the current location must match the byte
  133. specified. The locations are advanced by one.
  134. eg:
  135. VerifyByte:&23
  136.  
  137. ChangeString:<from> <to>
  138. This describes the change required to a string at the given location.
  139. <from> and <to> must be of the same length, and are in GSTrans format.
  140. The strings must not contain spaces, as space is the seperator between the
  141. two strings. Use <32> instead of space. The current location advances by
  142. the length of the strings, so you may give a sequence.
  143. eg:
  144. ChangeString:Verify<32>:4|M Verify<32>4|M<0>
  145.  
  146. VerifyString:<string>
  147. This specifies a string which must match the string found at the current
  148. location. The locations are then advanced by the length of the string.
  149. eg:
  150. VerifySring:<127>foobar<32><0>
  151.  
  152. ReplaceFile:<file name>
  153. OldContents:<file name> <file type>
  154. NewContents:<file name> <file type>
  155. This causes the file in the application directory to be replaced with a
  156. new version of the file supplied within the patches directory. The old
  157. version of the file is also supplied in the patches directory to allow
  158. patch removal. No checking of the file contents is performed, so you
  159. should ensure there is enough verify or change data for other files in
  160. the application to allow !Patch to be certain it is dealing with the
  161. correct directory eg. verify some words in the !RunImage. You may use
  162. verify data for the file to be replaced, so for example you could verify
  163. the comment string at the start of a !Run file since that is unlikely to
  164. have been edited by the user. If you do this, the data verified must be
  165. present and correct in both the OldContents file and the NewContents file.
  166. eg:
  167. ReplaceFile:!PCEm.!Boot
  168. OldContents:Patch:Files.Acorn.PCEm.Old.!Boot &FEB
  169. NewContents:Patch:Files.Acorn.PCEm.New.!Boot &FEB
  170.  
  171. CreateFile:<file name>
  172. NewContents:<file name> <file type>
  173. This causes the file in the application directory to be created, its
  174. contents being taken from the file specified in the patches directory.
  175. eg:
  176. CreateFile:!PCEm.!Sprites22
  177. NewContents:Patch:Files.Acorn.PCEm.New.!Sprites22 &FF9
  178. CreateFile:!PCEm.!Sprites23
  179. NewContents:Patch:Files.Acorn.PCEm.New.!Sprites23 &FF9
  180.  
  181. DeleteFile:<file name>
  182. OldContents:<file name> <file type>
  183. This causes the file in the application directory to be deleted. Its
  184. contents are provided to allow patch removal.
  185. eg:
  186. DeleteFile:!PCEm.!Boot
  187. OldContents:Patch:Files.Acorn.PCEm.Old.!Boot &FEB
  188.  
  189. Transforms file format.
  190. -----------------------
  191. The transforms files are processed using MessageTrans. The tokens looked up
  192. for a given transform are <transform>_Prepare and <transform>_Finish to get
  193. the actual *commands, and <transform>_PrepareSlot and <transform>_FinishSlot to get the Wimp slot size (in K) that each command gets to start with. The
  194. documentation for the transforms is here rather than in the Transforms
  195. file as MessageTrans reads the entire of the Transforms file into memory,
  196. comments and all.
  197.  
  198. For <transform>_Prepare, %0 is the initial file and %1 is the file that
  199. will actually be patched.
  200.  
  201. For <transform>_Finish, %0 is the patched file and %1 is the final file.
  202.  
  203. In both cases, %2 is a filename that printed output from the transforming
  204. program should be redirected to. For a program that does not print anything
  205. (eg. UnSqueeze) it need not be specified. After the transformation
  206. program has been run, if the error file exists and is of non zero size its
  207. contents will be displayed in an error box. !Patch will then attempt to
  208. continue ie. it is not assumed that the presence of output means an error
  209. occured. In fact in the case of squeeze, if there is any output there
  210. was an error, and !Patch will get a "File not found" error when it attempts
  211. to continue.
  212.  
  213. After SWI MessageTrans_GSLookup has been called, the results should be
  214. a valid *command which will perform the job, which is passed to SWI
  215. Wimp_StartTask. This may of course be an Obey file. Application space
  216. may be used however you like, as the *command is running as a new wimp
  217. task with its own application space.
  218.  
  219. The Prepare transformation is exercised a lot. Not only is it used while
  220. performing the actual patching but it is also used while scanning
  221. directories and after patching has been performed to work out whether
  222. the patches for a file can be applied, removed, or neither. Therefore
  223. the prepare transformation should ideally be fast, small and memory
  224. resident eg. UnSqueeze is performed by a small module loaded by !Patch.!Run.
  225. The benefit of being memory resident is that you have to swap floppy disks
  226. much less often. The benefit of being small is that you can afford to be
  227. memory resident. Squeeze takes a lot of memory to run, so you should not
  228. rmload huge modules just so you can have memory resident prepare transforms
  229. as this may then mean there is insufficient memory for Squeeze to run
  230. when a particularly large file is patched eg. !DTP.!RunImage.
  231.  
  232. 'Copy' is the standard "transform" used for files which need no
  233. transforming. This is because we patch in <Wimp$Scrap> and the transform
  234. performs the copying operations.
  235.  
  236. 'Squeeze' is the transform used for programs which have been run through
  237. the squeeze program supplied with the Acorn C and Assembler packages.
  238.  
  239. eg:
  240. Copy_PrepareSlot/Copy_FinishSlot:8
  241. Copy_Prepare/Copy_Finish:Copy %0 %1 ~A ~C ~D F ~L ~N ~P Q ~R S ~T ~V
  242.  
  243. Squeeze_PrepareSlot:0
  244. Squeeze_Prepare:UnSqueeze %0 %1
  245. Squeeze_FinishSlot:32
  246. Squeeze_Finish:Run Patch:Library.squeeze %0 %1
  247.