• Please review our updated Terms and Rules here

mTCP NetDrive: network attached storage for DOS 2.0 or better

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,420
mTCP NetDrive is a DOS device driver that allows you to access a remote disk image hosted by another machine as though it was a local device with an assigned drive letter. The remote disk image can be a floppy disk image or a hard drive image.

Use it to:
  • Add temporary extra space to a DOS machine.
  • Mount your library of floppy images directly on your DOS machine.
  • Create a repository of utilities or files that all of your DOS machines can share.
  • Provide a quick and easy backup target for Xcopy or Zip.
  • Add hard drive-like storage to machines that don’t have a hard drive.
Features:
  • A single device driver works with all versions of DOS starting with DOS 2.0.
  • It uses less than 6KB of RAM. (Add another 5 to 10kB depending on your Ethernet card.)
  • DOS 3.31 and up can use remote images up to 2GB in size. (Earlier versions of DOS are limited to 32 MB because they use FAT12 or original FAT16.)
  • The server runs on Windows (10 or 11) or Linux. No special permissions are needed.
  • The protocol uses UDP so you can use it on your private network or across the Internet. (Yep - start your own cloud storage business for DOS PCs!)
  • Network drives are standard raw disk images that can be manipulated using Linux tools.
If you use mTCP today it is as simple as installing the device driver and then running a command line program to attach or detach the remote storage.

Details and downloads can be found at http://www.brutman.com/mTCP/mTCP_NetDrive.html.
 
Thank you! This is awesome. The solutions from olden days tend to be clunky, memory-hungry, hard to setup a server for or all of the above. This is none of those.
 
Thanks. This was my first device driver for DOS, and it was quite a challenge. There was lots of software archeology to do.
 
How well does it interact with other users of mTCP at the same time, i.e. running NetDrive together with DHCP or FTSRV?
 
At this time mTCP NetDrive behaves like any other mTCP program; only one thing can use the Ethernet card at a time. You run DHCP first, then NetDrive, and while NetDrive is connected to a remote disk image that Ethernet card/packet driver are not sharable with other programs. It's a basic limitation of running IP or ARP over a packet driver.

However, I have a plan to make this possible in a future version. The device driver has to get the packets first to answer ARP and the UDP packets addressed to it. But there is no reason why it can't "masquerade" as a packet driver itself and pass the packets it is not interested in to something else. Basically, I'll be embedding what looks like a packet driver into the device driver to enable this pass-through to other networking programs.
 
mbbrutman said:
However, I have a plan to make this possible in a future version. The device driver has to get the packets first to answer ARP and the UDP packets addressed to it. But there is no reason why it can't "masquerade" as a packet driver itself and pass the packets it is not interested in to something else. Basically, I'll be embedding what looks like a packet driver into the device driver to enable this pass-through to other networking programs.
Click to expand...

There's an existing packet driver multiplexer floating around out there, that I know I played with at least once. (I think it was in the context of fiddling with NFS? Or was it EtherDFS? It's been a while.) Googling around it looks like it was PKTMUX.EXE. Link to documentation. In principle might this work with NetDrive?
 
The packet multiplexer might work. I was going to mention it, but decided against it; it makes things much more complicated.

The person who runs http://floppy.museum/ (down at the moment?) uses it to have the FTP server and HTTP server running on the same machine at the same time. But it has limitations and usability problems.
 
If a more general-purpose user friendly way to multiplex mTCP programs were to emerge I’d humbly suggest a candidate for the next device driver to stack on it would be an LPT port to network printer port redirector TSR. ;)
 
mbbrutman said:
However, I have a plan to make this possible in a future version. The device driver has to get the packets first to answer ARP and the UDP packets addressed to it. But there is no reason why it can't "masquerade" as a packet driver itself and pass the packets it is not interested in to something else. Basically, I'll be embedding what looks like a packet driver into the device driver to enable this pass-through to other networking programs.
Click to expand...

Any particular reason not to have a mode of operation where the TCP/IP stack itself can run as a TSR in a similar way to the Novell one allowing multiple applications (including a Windows WinSock implementation) to share it?
 
A TCP/IP stack as a TSR requires a lot of compromises on features and performance. I can't imagine trying to debug all of the strange problems people have had over the years without a good tracing facility. And it forces everybody to pay for the cost of a full TCP/IP stack when most of the time people run exactly one program that needs it, and that program only needs a limited number of features. It's also hard to debug and make it reliable.

I went with the library approach to avoid those headaches, and concentrated on proving good, reliable programs. For me, that was the right decision.
 
Very nice - will set this up later this weekend. Any chance of a FreeBSD version? I *think* I can run Linux executables on FreeBSD but it’d still be nice to go native.
 
deepthaw said:
Very nice - will set this up later this weekend. Any chance of a FreeBSD version? I *think* I can run Linux executables on FreeBSD but it’d still be nice to go native.
Click to expand...
Not this weekend but I'll have source code released soon enough.
 
If you are really itching to try it out, I have a public server running a demonstration disk in the middle of the US.

See the details here and look for bigdisk.dsk.
 
Tested it using the Linux emulation layer (or whatever it’s called) on FreeBSD and seemed to work fine. Hooray, and thank you so much @mbbrutman for this tool!
 
Oh, cool, that's good to know.

I plan to get the code reviewed and opened in the next few weeks - stay tuned.
 
I setup my FreeBSD server to mount my drive images into its local filesystem so it's easy to add stuff to them. Here's how I did it - steps are probably very similar in Linux but using different programs/commands.

First, I had to enable linux compatibility.

sysrc linux_enable="YES"
now reboot your machine or run:
service linux start

Go to the directory where you'll be storing your disk images. I haven't picked a good place yet so it's all in root's home directory (boo! hiss!)

create a FAT16 2GB hard disk image:
newfs_msdos -C 2047M -F 16 drive0.img

attach a "memory disk" (although really we're just mounting the hard drive image I just made)
mdconfig drive0.img
(this will return something like /dev/md0 - use that in the next steps)

mount the image under /mnt
mkdir /mnt/dos0
mount -t msdos /dev/md0 /mnt/dos0

share the drive(s)
./netdrive serve

I can now navigate directly into my drive0.img at /mnt/dos0 and add/remove/manage whatever I need to like any other local filesystem. I connect to it from my MS-DOS machine via:
netdrive connect 192.168.1.66:2002 drive0.img d:

It's probably a really bad idea to try and write to it from the MS-DOS system while you're doing this but I like to live dangerously. Next I'll export it via samba so I can just load whatever I want onto it from a workstation, and will probably setup multiple disk images based on what they contain.
 
Last edited:
I've made some changes to the server side:
  • I've added a "headless" mode for people who don't want to use the text UI. It's not a full Unix-style daemon but you can throw it in the background now and you can probably use "daemonize" on it.
  • An ARM version of the server is available now. (Somebody else already verified that it works on a Raspberry Pi without changes, but I wanted to do it myself to be sure.)
I'm also looking for more feedback and testing help. In particular I'm running a public server at brutman.com that you can connect to and play around with.
  • 200MB disk image: netdrive connect brutman.com:2002 bigdisk.dsk d:
  • 32MB disk image: netdrive connect brutman.com:2002 fat12.dsk d:
  • 2GB disk image: netdrive connect brutman.com:2002 hugedisk.dsk d:
The 32MB image is suitable for all versions of DOS including 2.x and 3.x. The 200MB image is FAT16B so you need to be running DOS 3.31 or greater to test it. The hugedisk.dsk image is mostly empty and it's just there for giggles. (Change the drive letter as needed.)

These disk images support writes too - feel free to play around with them. The writes are only visible to you during your session, so if something gets too badly messed up just disconnect, reconnect, and it will all be clean again.

Sorry, no source code yet ... I'm still actively making changes and trying to get more feedback on what I've already provided.

More details can be found at http://www.brutman.com/mTCP/mTCP_NetDrive.html.
 
You must log in or register to reply here.
Back
Top