
                   Crossdos (Japan) Implementation Notes



1.   Automatically convert Shift JIS code in file/dir name of MS-DOS disks
     to EUC when reading MS-DOS disk and convert  EUC code in file/dir name
     of AMIGA disks to Shift JIS when writing to MS-DOS disks. All
     conversions are done using jcc library.

     --  When a file/dir name has more than 8(11) bytes , if the truncation
         causing the last byte to be the first byte of a 2-byte character
         during writing, the last byte will be cut off.

     --  All Shift JIS code of katakana characters converted from EUC will be
         double byte Shift JIS.  i.e. to search a directory list of MS-DOS
         disk , double byte Shift JIS code will be used.  However,
         if no matching name found,  the katakana characters are converted
         to single byte Shift JIS code, and the search  will be conducted
         again.  As a result, single byte Shift JIS code is always used in
         katakana characters of a file name when the file is created.

     --  As far as file/dir names are concerned,  it is assumed that Shift
         JIS code is used in MS-DOS disks.

 2.   Automatically convert  text file contents when text filter flag is set.
      All conversions are done using jcc library.

     --  Same flag is used for both  Ctrl-M , Ctrl-Z filtering and code
         conversion since it doesn't seem making sense to handle them
         separately.

     --  The conversion handles and flags monitoring states of conversion are
         allocated per lock.

     --  During file transferring,  attempt is made to determine the input
         file code.  if  the input file is not a text file, or a text file
         with non EUC/Shift JIS code, no conversion or filtering will be made.

     --  When reading from a MS-DOS disk, if the last byte to read is not
         on character boundary, attempt is makd to pre-scan the next byte so
         the correct translation of the byte can be returned.  However, if a
         task is trying to seek to a particular location of the file, the
         task has to make sure the seeking position is on a character
         boundary.  (see "Potential problems").

     --  Writing is handled a bit differently.  If the data written is not
         ended on character boundary, the last byte will not be written
         until the next write.

     --  During the converting process, all single-byte katakana is replaced
         by character '%'.

 3.  Potential problems:

     --  If the block of data to read/write consists of only single byte
         Shift JIS code,  it is difficult to distinguish it from EUC code,
         currently, EUC code is assumed (jcc library).   For reading,
         pre-scanning entire file would help.

     --  If Seek is used to read/write in the middle of file,  if the
         seeking position is not on character boundary,  problem may occur.
         Scan back  can solve the reading problem .





.
