CUG #431: DOS Remote Installable File System


Introduction

Kyle A. York (McGraw Hill School Systems) submits his Remote Installable File System for DOS. The Remote Installable File System provides a LAN linking two computers through the serial port so they may share resources. RIFS installs itself as a TSR using the MSCDEX convention for installable file systems. Shareable resources are currently limited to available disk drives including hard disks, CD-ROM, and network drives. RIFS also supports the redirection of a client parallel port to a file or device on the server. RIFS supplies 32-bit Cyclic Redundancy Check (CRC) to guarantee error-free file transfers. The CUG Library distribution includes full source in C and ASM as well as MS-DOS executables. RIFS for DOS (released 10/08/94) is immediately available as CUG volume #431.

RIFS compiles under Borland Turbo C 2.0 and uses some Turbo C specific structures in the server packet processing. York's intention was to do as much of the code with standard C as possible. Specifically, he has minimized the assembly code to only the most time critical tasks and some things which are notoriously difficult in C, such as interrupt handlers. The 32-bit CRC module is also in assembly language because it is five times faster than doing it in C. Actual CRC calculations are produced from an algorithm by Rob Warnock pubished in comp.compression on Usenet. The assembly language files are tailored for use with Borland Turbo Assembler.

Installing and Running RIFS

You can get up and running with RIFS in just a few minutes. This example assumes COM1 for serial connections:

  1. Connect computers via serial cables and null-modem

  2. Add the following to config.sys on the client PC
         LASTDRIVE = Z

  3. On the server PC, type
         SHARE
         RSERVER /COM1

  4. On the client PC, type
         RCLIENT /COM1

  5. On the client PC, type
         RDRIVE /local=Z /remote=C

    (this links the client's drive Z to the server's drive C.

This is the simplest possible example of using RIFS. Each of the commands includes several options which merit further examination. Both RCLIENT and RSERVER allow command-line options to specify communications parameters. The /speed= option lets you select any baud rate from 300 to 115200 baud.

RIFS supports COM1-COM4 as defined by the BIOS data area. You may define additional nonstandard COM ports by combining the /irq= and /port= parameters. For example, you might use /irq=0B and /port=02e8 on a customized COM port. RIFS cannot access FOSSIL interface COM ports or take advantage of smart serial boards. RIFS does not take advantage of data buffering available on serial ports with NS16550 compatible UART chips.

Both RCLIENT and RSERVER can unload their RAM resident portions using the /remove parameter. RDRIVE is technically not a TSR since merely changes settings in the resident part of RCLIENT and then exits without permanently allocating RAM. However, RDRIVE also has a /remove parameter which serves to unmap any remote drive associations made so far. Thus you can then re-use the drive letter for a different mapping.

Printer port redirection

Once an RCLIENT/RSERVER session is established, you can also take advantage of parallel port redirection services. Just as RDRIVE lets the client utilize the remote disk system as a local drive, RPORT lets the client share the remote computer's printer as if it were local. Specifically, any of LPT1-LPT3 on the local computer can be mapped to LPT1-LPT3 on the remote computer.

MSCDEX and Installable File Systems

The Microsoft MS-DOS CD-ROM Extensions (MSCDEX) provide a much simpler method of allowing access to a non-local drive than redirecting INT 21h (Disk Request) and associated functions. Instead, an installable file system, such as RCLIENT, only needs to chain into the INT 2Fh (Multiplex). The advantage is that this module only has to provide a handful of services, allowing DOS to do most of the work. Any disk that is compatible with DOS is automatically compatible with RIFS.

For those interested in low-level details of IFS, York recommends chapter 4 of the book Undocumented DOS. I have found the Microsoft Press book MS-DOS Extensions (ISBN 1-55615-212-4) by Ray Duncan to be helpful in detailing MSCDEX functions. You might also look in the Microsoft Developer's Network CD-ROM under the Microsoft CD-ROM Extensions Device Driver Kit (DDK).

System Requirements

RIFS required software and hardware requirements are minimal:

The RCLIENT module works with MSDOS 3.2 and later. except for MSDOS 4.x. RCLIENT has been tested with MS Windows 3.1 and Desqview 2.4 and can run either inside a DOS window, or before Windows or Desqview is loaded. In the latter case, the remote drives become available to all windows. Note also the remote drive may only be accessed sequentially rather than simultaneously by more than one window. RCLIENT will not work with Windows NT 3.0 and may not be compatible with OS/2.

The RSERVER module runs in one of two possible states. On a computer running only DOS, it runs in an internal multitasking state. If it is run under Desqview, the internal multitasking must be disabled with the /nobackground command-line switch. Furthermore, it must be run in a dedicated window. This causes a slight decrease in performance. RSERVER running with multitasking disabled works with any multitasking operating system that runs DOS programs. It has been tested with Window NT 3.0 and Desqview. RSERVER will not run with Windows 3.1 unless it is rewritten to be a VxD.

RIFS operates efficiently even on older PCs. York has benchmarked 23,000 bps effective throughput rates on a classic 4.77Mhz PC and 115,200 bps on a 12Mhz 80286. The maximum rate of standard serial ports is 115,200 bps due to the baud rate oscillator division.

Documentation, Licensing, and Support

RIFS documentation consists primarily of a usage guide and technical notes in a 5-page ASCII file. The usage section explains the underlying theory of operation as well as the command-line syntax for RCLIENT, RSERVER, RDRIVE, RSTATUS, and RPORT. The technical notes highlight some of the design decisions including the advantages of implementation using MS-DOS Installable File System hooks. A separate file documents the client/server communication protocol. The structure of a packet is shown in Fig. 1.

York intends RIFS primarily for personal noncommercial use. He specifically asks you to refrain from reselling the product until contacting him first. Also, he asks that you retain his name where it appears in comments when incorporating his code into your program. Last, if you produce modified versions of the source, please indicate your name as well.

Since RIFS is freeware, a formal technical support plan is unavailable. However, the author encourages feedback by email whether positive or negative.

Future RIFS development

York has several ambitious ideas for improving RIFS in the future. Some of these include:
---------------------------- FIGURE 1 ---------------------------------
               Client/Server Communication Packet Buffer

typedef struct {
  BYTE  packetID[2];  /* ................................... */
  WORD  length;       /* total number of bytes in this block */
  WORD  notlength;    /* ~ length (used for checking)        */
  WORD  cmd;          /* command to execute / result         */
  WORD  sender_id;    /* machine ID of block sender          */
  WORD  address_id;   /* machine ID of intended reciever     */
  WORD  process_id;   /* ID of sending process (for closeall)*/
  DWORD crc32;        /* crc-32 of entire block              */
  BYTE  data[];       /* misc. data                          */
} XMITBUF;

This assumes that only one request can be processed in either direction at a time, but requests can go in either direction. If both directions are going simultaneously, a full packet must be transmitted in one direction first.

Each packet contains maximum 1024 bytes of actual data.

---------------------------- FIGURE 1 ---------------------------------