Using NFS to Transfer Files between Windows and MS-DOS 6.22

Although I successfully configured Microsoft Network Client 3.0 to access my shared folder on my Windows 7 machine, the setup eats up almost 100KB of conventional memory, making it impossible to run many other programs while the shared drive is in use. I therefore decided to use some of my free time to explore how to use NFS (Network File System), the original Unix file sharing protocol, to share file between MS-DOS and Windows, hoping that it would use less conventional memory and allow me to run larger programs.

The first task is to find an NFS tool for MS-DOS. After a bit of research, I use XFS191, a lightweight client which was last developed in 1994. As the software was written using Turbo Pascal 6.0, it is necessary to patch the executables to avoid runtime error 200 (division by zero) when running on modern machines. For our purposes, we only need to patch xfstool.exe and xfskrnl.exe. The patched executables together with the hosts and init files as well as a batch file (xfs.bat) to start the client can be downloaded here.

Next, we need to find an NFS server that will work with our antique NFS client. Although modern Linux distributions still support NFS for file sharing, NFS has been upgraded over the years so we need to find a lightweight server that still use NFS v1 which is known to work with XFS191. After a lot of research, I stumbled upon Petebarber’s NFS server which is simply a small Windows executable (download from here). Just run it and your current hard disk drive should be accessible via NFS:

For simplicity, turn off the firewall on your newly started NFS server to avoid any potential issues.

Next, we need to modify our XFS191 configuration. Assuming that a packet driver for your network card has already been installed, you can start by modifying the hosts file to specify the IP address of the local machine as well as the NFS server:

#
# XFS Version 1.71
# hosts
#
# Note: Please keep this file in LF/CR (DOS) format!
#

192.168.1.1	gateway
192.168.1.255	broadcast
255.255.255.0	netmask

192.168.1.41    md386
192.168.1.157   share 

The first three lines specify the network settings, followed by IP addresses of the local machine and NFS servers. Take note that multiple server entries can be added. After that, modify the init file to initialize the network configuration as well as the shared folders to be mounted:

#
# XFS Version 1.8
# Command Script
#
# see  `Xfstool help <command>'  for more
#
#

init md386 sm=255.255.255.0 gw=192.168.1.1 csum=off

# authentication

pcnfsd share
#login

mount    z: share:c:\tools\dos
show

# per-drive re-authentication
# dlogin  f:
# dlogin all

The init md386 line indicates that the NFS client should start with md386 being the local host name. The mount z: share:c:\tools\dos tells XFS191 to map Z: to the c:\tools\dos folder on the NFS server. The LASTDRIVE=Z statement might need to be added to CONFIG.SYS for this to work.

Edit XFS.BAT and make sure that the address of the packet driver (0x60) is correct:

@echo off
rem XFS Version 1.71
loadhigh xfskrnl 0x60
xfstool @init 

After that, start the NFS client by running XFS.BAT. You should receive messages indicating that drive Z: has been mounted successfully:

On some machines, there might also be false warnings indicating missing packet drivers, even when a packet driver has already been installed. You can ignore these messages as long as the mounted drive is accessible.

Accessing the shared folder is now a breeze:

The volume label of the shared drive will be the same as the value specified in the mount command of XFS. The amount of free disk space will be most likely 377,487,360 bytes as NFS v1 (and MS-DOS 6.22) was not designed for today’s large hard drives. A flashing “<” character will be displayed on the top right of the screen while the shared drive is being accessed.

In my tests, XFS191 consumes far less conventional memory than Microsoft Network Client, allowing me to run many large programs. A small issue is that files copied from NFS shared drives will always have the read-only attributes that must be cleared via the attrib command. This also happens with files copied from CD-ROM drives mounted via MSCDEX but does not happen with Microsoft Network Client shared drives. Also, when performing directory listing on a large directory, the listing sometimes pauses for a few seconds as data is being exchanged, which also does not happen with Microsoft Network Client. Despite these minor inconveniences, you should not have any issues reading or writing to the shared drive and with a good network connection, the shared drive will just be as good as a local drive.

One last thing to know is that XFS191 will work well with folder names containing only lowercase alphanumeric characters. All names should be 8.3 compliant. Uppercase characters, special characters such as underscore or even dots in folder names will cause the names to be escaped with ~. This will not affect data integrity but will cause the original names to be lost. To avoid this, I have developed a tool to recursively convert all file/folder names in the current directory to lowercase, which can be downloaded here. Just run the tool from the folder to be shared via NFS and you are all set!

A copy of the modified source code for the NFS server can be downloaded here. I fixed a bug that causes issues accessing sub-directories. Another version which can be run on Mono to work on Linux can be downloaded here. In the Mono version, path separator has been modified appropriately.