Preparing AUTOEXEC.BAT and CONFIG.SYS

The OS/2 device driver FSFILTER.SYS is provided to address the above problem.

FSFILTER.SYS allows the DOS in the Virtual Machine Boot to access HPFS files.

However, some DOS programs test for the presence of these drivers. OS/2 V2.0 provides the equivalent "stub" drivers to satisfy these programs that the services actually are available.

The following types of device drivers should also be omitted from CONFIG.SYS:

• Disk cache
  
• Print spooler
  
• RAM disk

  These facilities are already provided by OS/2 Version 2.0 and may be accessed by virtual DOS machines and VMB sessions; including them with DOS leads to unnecessary duplication, and may impact overall performance.

  When the Virtual Machine Boot is started from a diskette image on the hard disk, the real DOS sees the diskette image as drive A:. The real drive A: cannot be accessed. OS/2 V2.0 provides a DOS program, FSACCESS.EXE, that can be used from the DOS command prompt or inserted in AUTOEXEC.BAT to overcome this problem.

  We will cover each of these special requirements in detail in the following sections.

  Drive Letter Allocation and Access

  Drive letter allocation and access is one of the more complex areas of VMB, mainly due to the automatic drive letter allocation performed by DOS, and the limitations of earlier DOS versions. The following possible areas of confusion may arise for the user:

• If DOS is booted from an image file, it sees this image file as its A: drive. This prevents access to the real A: diskette drive. Attempts to write to the apparent A: drive will fail.

• Unlike the DOS Emulation kernel provided by OS/2 Version 2.0, the "real" DOS booted by VMB cannot see or access an HPFS partition on the hard disk.

• A DOS 3.x VDM cannot see a large (>32MB) FAT partition on the fixed disk, or FAT partitions beyond an HPFS partition on the disk.

• Even if the booted DOS can otherwise see the hard disk partition, it is only given read access. Attempts to write will fail with simulated errors such as General failure writing drive C:". The user might mistake this for a genuine hardware fault.

• If the booted DOS loads a block device-driver, the allocated drive letter may be the same as that of a different device outside this VDM, thereby preventing access to that device from within the VDM.

  The results could be somewhat disorienting for the user. To help resolve these issues, two utilities FSFILTER and FSACCESS are provided with OS/2 Version 2.0.

  It is recommended that disk volumes should always be given a meaningful name, either when formatting or later using the LABEL command. This name will remain constant regardless of drive letter allocation, and will aid in identifying a particular volume, even if the assigned drive letter is different. FSFILTER

  FSFILTER.SYS is a device driver which manages DOS VDM access to OS/2 disks. FSFILTER.SYS should be copied from the \OS2\MDOS directory to the DOS diskette, and the following statement added to the CONFIG.SYS file of the bootable DOS diskette or image.

  device=a:fsfilter.sys
  

  This statement should precede any DEVICE= statements which load block device drivers.

  Note that FSFILTER.SYS gives DOS full access to all OS/2 partitions, regardless of their file system type or partition size.

  This is an important and somewhat surprising point. For example, DOS 3.3 (in a VDM) has no problem accessing a 300MB HPFS partition, once FSFILTER is loaded. I/O calls within the DOS virtual machine are passed transparently to OS/2 Version 2.0. DOS itself is unaware of the underlying file system. DOS can read, write and modify files on the hard disk, and for most configurations the drive letter mapping within the VMB session will match those of OS/2 Version 2.0.

  The FSFILTER device driver occupies approximately 11KB of memory. It can be loaded into high memory under DOS 5.0 by specifying the command DEVICEHIGH = FSFILTER.SYS in CONFIG.SYS.

  The users should also specify the path to COMMAND.COM in the SHELL= statement of CONFIG.SYS. For example, if DOS files have been copied to C:\DOS, the CONFIG.SYS file on a diskette intended for VMB should contain the following statement:

  SHELL=c:\DOS\COMMAND.COM c:\dos /p
  

  The first parameter specifies the command processor to be loaded. The second parameter specifies the reload path (that is, the COMSPEC path). This is preferable to a SET COMSPEC = command in AUTOEXEC.BAT.

  Each block device driver loaded in DOS CONFIG.SYS is allocated the next free OS/2 letter excluding LAN drives. This can result in a drive letter clash. An example may illustrate the point. OS/2 drives are:

  A:

  Diskette drive 0
  B:
  Diskette drive 1
  C:
  Hard disk
  D:
  External diskette drive
  E:
  Remote LAN drive on a server

  FSFILTER will ensure that a booted DOS sees these drives by the same letter. The booted DOS has the same access to the external diskette drive and LAN resources as does OS/2 itself. This is true whether the VMB session is started before or after user logon to the network, when remote drive letters are assigned.

  However, a block device driver in a VMB session will also initialize as E:, so LAN drive access is lost. To remedy this, issue an "fsaccess f=e" command. The LAN drive is now accessible as F: within the DOS session.

  Note that even when FSFILTER is loaded, the following restrictions still apply:

• A VMB session cannot see HPFS files or directories which have:

  • Long file names (9 or more characters) -
    Invalid FAT characters (for example, plus, comma, blank)
    -
    Multiple dot separators.
    
    HPFS file names containing lowercase letters are folded to uppercase.
    
    PC DOS commands which require low-level disk access will fail. These include:

    • CHKDSK -
      SYS
      -
      UNDELETE
      -
      FORMAT
      -
      UNFORMAT
      -
      MIRROR.
      In such cases OS/2 Version 2.0 will simulate a disk error condition. DOS may interpret this as a hardware fault, or report that the command is not supported on a network or assigned drive.

    FSACCESS

    FSACCESS.EXE is a utility supplied with OS/2 Version 2.0 but intended to run in a VMB session. It cooperates with FSFILTER to manage drive letters within the VMB session. This serves three purposes:

    • Drives may be registered for filtering.

    • The drive letter for a device can be changed, giving consistency across sessions.

    • Letters can be removed in order to hide the OS/2 device from the VMB session.

      The syntax of the FSACCESS command is:

      FSACCESS ────────────────┬─────────────────────────┬─────┐
                               ├─┬───┬─ DOSletter ───────┘     │
                               │ └ ! ┘                         │
                               ├────── DOSletter - DOSletter ──┤
                               │                               │
                               └────── DOSletter = OS2drive  ──┘
      

      FSACCESS

      Lists the current drive mapping. For example:

                   Local C: is mapped to OS/2 C:
                   Local D: is mapped to OS/2 D:
                   Local E: is mapped to OS/2 K:

      FSACCESS F:
      Registers DOS letter F: for filtering. References to F: will be sent to OS/2 Version 2.0.
      FSACCESS !F:
      De-registers DOS letter F: from filtering.
      FSACCESS F:-H:
      Registers DOS letters F: through H: for filtering.
      FSACCESS M:=C:
      Routes requests for DOS letter M: to OS/2 drive C:

      Parameters can be combined on a single command line, and the colon is optional.

      When booting from an image file, it is often desirable to issue the command FSACCESS A: in order to access the A: diskette drive. This will remove access to the image file, so the booted DOS will be unable to reload its COMMAND.COM when necessary. It may be useful to copy all the DOS files to a subdirectory on hard disk, ensuring the PATH and COMSPEC point there.

      An alternative is to access the diskette drive via a different letter. For example, a user may issue the command FSACCESS G:=A, then use G: to access the real A: drive. The image file remains as A:, avoiding PATH and COMSPEC problems.

      ---

      [Back: Configuring Virtual Machine Boot]
      [Next: Mouse, EMS and XMS Support]