home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / utilities / armedit_1 / Docs / Device < prev    next >
Text File  |  1997-02-21  |  7KB  |  198 lines
  1. File        : Device
  2. Date        : 21-Feb-97
  3. Author      : © A.Thoukydides, 1995, 1996, 1997
  4. Description : Description of the ARMEDIT.SYS DOS device driver.
  5.  
  6.  
  7. INTRODUCTION
  8.  
  9. The ARMEDIT.SYS device driver allows RISC OS filesystems to be accessed like
  10. normal DOS drives. To use this driver it is necessary to load the ARMEdit
  11. module before starting the PC front-end.
  12.  
  13.  
  14. INSTALLING THE DRIVER
  15.  
  16. Add a line like the following to the CONFIG.SYS file:
  17.  
  18.     DEVICE=ARMEDIT.SYS [-limit <size>] <path1> [<path2> [...]]
  19.  
  20. where
  21.  
  22.     <size>      - The maximum size of file, specified in bytes, to include
  23.                   in the device. The default of 10MB is used if no value is
  24.                   specified. Use a value of 0 to allow all objects to be
  25.                   included regardless of size.
  26.  
  27.     <path1> etc - The full RISC OS pathnames for the root of each emulated
  28.                   device. Currently up to four paths may be specified.
  29.  
  30. The RISC OS pathnames may be prefixed by one or more of the following
  31. characters:
  32.  
  33.     \           - Image files are treated as directories. This allows archives
  34.                   to be accessed via a suitable RISC OS dearchiver, e.g. 
  35.                   SparkFS or ArcFS.
  36.  
  37.     #           - Disables canonicalisation of the pathname. This allows
  38.                   multiple discs to be used in removable drives.
  39.  
  40. If the driver is not in the root directory of the default drive then the full
  41. pathname should be inserted after the "=" sign.
  42.  
  43. It may also be necessary to change the LASTDRIVE entry in the CONFIG.SYS
  44. file to support more drives.
  45.  
  46.  
  47. DIRECTORY LOGGING
  48.  
  49. The device driver builds up a DOS image of the RISC OS filesystem being
  50. accessed. This has two side effects: Quite a lot of memory can be used, and
  51. changes made to the filesystem from RISC OS will not be seen by the PC.
  52.  
  53. To overcome both these problems the command *ARMEdit_DevicesRelog should be
  54. used to clear unrequired parts of the disc log. This command does not take
  55. immediate effect - it waits until DOS informs the device driver that the
  56. disc may be changed. Hence, there should be no files open from the PC on
  57. the emulated device, and a simple operation should be performed (such as
  58. typing "DIR").
  59.  
  60. Unexpected disc errors can be due one of a number of limitations being
  61. reached, such as RAM or number of FAT entries. If this happens, and repeating
  62. the operation does not complete the operation successfully, then try
  63. *ARMEdit_DeviceRelog to clear the logged data.
  64.  
  65. If a Risc PC is being used, then the problem of a large amount of memory
  66. being used for the logged directories can be overcome by using my virtual
  67. memory manager Virtualise, available from Clares.
  68.  
  69.  
  70. FILENAME TRANSLATION
  71.  
  72. To behave as a normal DOS device, all RISC OS filenames need to be translated
  73. ino the 8.3 character filenames. This is performed in a number of steps.
  74.  
  75. Firstly, the three character file extension is chosen. If the original
  76. filename had a DOS extension (starting with a "/" character) then this is
  77. used. Otherwise, the RISC OS filetype is translated using the same DOS
  78. mappings as used by the PUTFILE and GETFILE commands. These mappings can
  79. be updated using *ARMEdit_DOSMap.
  80.  
  81. The individual characters of the filename are then translated in a similar
  82. manner to DOSFS. Additionally, hard space characters (code 160) are converted
  83. to "_" and other top bit set characters to "@".
  84.  
  85. Finally, any duplicate filenames are modified to allow access to all files
  86. with unique names.
  87.  
  88.  
  89. DRIVE LETTERS
  90.  
  91. Drive letters are assigned to all block input/output devices configured for
  92. use. Examples of block devices are disc drives, CD-ROMs, scanners, and the
  93. ARMEDIT.SYS device driver. Drive letter after the C: (boot) drive may change
  94. when this device driver is installed.
  95.  
  96. Drive letter changes can affect the access to a network, CD-ROM drives, and
  97. applications that reference existing drive letters.  When drive letters
  98. change, the following items need to be checked:
  99.  
  100.     CONFIG.SYS and AUTOEXEC.BAT files need to reflect the new drive letters
  101.     when loading device drivers.
  102.     
  103.     The PATH statement in the AUTOEXEC.BAT file may require changes to refer
  104.     to the correct drives.
  105.     
  106.     Other batch files may reference the wrong drives.
  107.     
  108.     Windows .INI files and Windows groups should be updated with the new
  109.     drive letter assignments, including the program icons.
  110.     
  111.     Rerun INSTALL or SETUP for application programs that do not allow the
  112.     drive letter to be changed.
  113.     
  114.     Update any network login scripts as necessary.
  115.     
  116.     REMOUNT any compressed drives.
  117.  
  118.  
  119. PRESERVING PREVIOUS DRIVE MAPPINGS
  120.  
  121. With PC-DOS (or versions of MS-DOS up to 5.0), the DOS ASSIGN command can be
  122. used to overcome the problem of drives changing name. As an example, if
  123. before using ARMEdit the CD-ROM drive was E: and a single ARMEdit device is
  124. added which shifts the CD-ROM to drive F: then the command
  125.  
  126.     ASSIGN E=F F=E
  127.  
  128. will make the CD-ROM drive appear as drive E: and the ARMEdit device as drive
  129. F:. Similarly, if two ARMEdit devices are added then
  130.  
  131.     ASSIGN E=G F=E G=F
  132.  
  133. will sort it out.
  134.  
  135. There does not appear to be a good solution to the problem with MS-DOS 6,
  136. although the SUBST command can sometimes help.
  137.  
  138. With PC DOS 7 and Windows 95's MS-DOS mode, the DYNALOAD command can be used
  139. to load the driver after the CD-ROM drive assigments have been performed by
  140. MSCDEX. The syntax to use is:
  141.  
  142.     DYNALOAD ARMEDIT.SYS <path1> [<path2> [...]]
  143.  
  144. This may be either typed at the command line or included in the AUTOEXEC.BAT
  145. file. Prefixing the line by LOADHIGH will load the driver as if it had been
  146. loaded with DEVICEHIGH in the CONFIG.SYS file.
  147.  
  148.  
  149. OTHER POINTS TO NOTE
  150.  
  151. The device driver does not currently support write operations. Any attempts
  152. to modify the drive from the PC simply modify a copy in RAM. This is intended
  153. mainly as a debugging aid, but may be extended to allow use as a RAM disc in
  154. future.
  155.  
  156. Low level PC disc tools may not operate as expected on emulated devices. This
  157. is due to the way in which the directory structure of the device is
  158. dynamically constructed as it is accessed.
  159.  
  160. If heavy use has been made of emulated devices then some operations, such as
  161. quitting the PC software, can take a surprisingly long time to complete. This
  162. is normal, and is due to the operation of the memory management.
  163.  
  164. When used with Windows 95, the error:
  165.  
  166.     Windows was unable to identify the specified real mode driver which was
  167.     loaded in your Config.sys file.
  168.  
  169.     If you no longer need this driver, remove it from your Config.sys file,
  170.     Otherwise contact the manufacturer of this driver to see if a Windows
  171.     (protected-mode) driver is available.  Windows will not perform optimally
  172.     until you have done one of these things.
  173.  
  174. will be displayed. This is a consequence of the driver being written for DOS.
  175. Ignore this error - the driver will operate correctly.
  176.  
  177.  
  178. THINGS TO DO
  179.  
  180. The following are changes that may be made to the ARMEdit device driver
  181. sometime in the future.
  182.     
  183.     Support write operations.
  184.  
  185.  
  186. VERSION HISTORY
  187.  
  188. 0.00 (07-May-96)    Original development version.
  189.  
  190. 0.01 (27-May-96)    Support for Acorn's software PC emulator included.
  191.  
  192. 0.02 (13-Jun-96)    PC emulator support code corrected.
  193.  
  194. 1.02 (06-Aug-96)    First official release version.
  195.  
  196. 1.03 (21-Feb-97)    Maximum object size to include may be specified.
  197.                     ARMEdit_DevicesRelog now accepts a "-now" switch.
  198.                     Added option to disable canonicalisation of path names.