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.
It's great if you need to mount/read install files from a remote location and don't want to copy them over first. In my 386 I only have a 330MB harddrive. Any CD based games or application I need to burn to a CD to be able to run/install. With this tool it can be done over the network.
appiah4: Obviously I'm a big fan of FTP. But in the DOS world things like file managers expect to use drive letters. You can use standard DOS commands (copy, xcopy, deltree) or run programs directly on the logical drive which is something you can't do with FTP. For machines like the PCjr there isn't even a local hard drive to copy files too.
Jo22: I've tested extensively on PC DOS. (MS DOS is covered by that.) I've tested lightly on FreeDOS. The device driver is not sophisticated because it has to be DOS 2.0 compatible, so if you have a DOS variant that claims to use the same device driver model then try it out. The only weirdness might be around the tiny RAM disk that I use to signal that nothing is connected; FreeDOS wasn't happy with it and other versions of DOS might not like it either.
Yoghoo: As pointed out already, just move the device driver around to get the drive letter that you'd like. The server side doesn't print the IP address, but you should be able to connect to it from DOS by name if you have DNS setup.
Vetz: I'm trying to keep the device driver as small and simple as possible. It also needs to be portable between the versions of DOS. A feature to reserve a drive letter might be possible, but also might require version dependent code. I'll look into it.
That doesn't work in (my?) case. The cdrom gets a drive letter in the autoexec.bat. So after the config.sys. I already put it all the way at the bottom of the config.sys but it always uses the first drive after the fixed disks. I like to use a drive letter after the cdrom. So like suggested earlier a parameter for the device driver which drive letter to use would be nice.
The technology used here does not support assignable drive letters. NETDRIVE.SYS is a standard DOS "block device driver". Each block device driver will provide one ore more partitions to DOS.The driver has no control over the drive letters, DOS just assigns them consecutively. Before interpreting CONFIG.SYS, an internal block device driver registers all DOS-type partitions on hard drives on the letters C:, D:, ..., and the first block device driver loaded will inevitably get the next letter after those partitions. If you need the NETDRIVE at a later letter, try using ASSIGN or SUBST to provide the letter of your choice.
I chose a device driver to keep things small and simple, which is the only way a 6KB device driver can work across all versions of DOS and still do some neat tricks. (Buffer space is about half of the driver.)
A TSR can choose to get a specific drive letter by messing with internal DOS data structures, but that is complicated and the code depends on which version of DOS you are using. A later version of this code could be packaged as a TSR, but right now it's a device driver.
This works nicely when not using a cd-rom driver. When using a cd-rom driver the netdrive.sys loads correctly but takes the drive from the already assigned cd-rom. And when it tries to mount the image with netdrive.exe it hangs after the packet driver is connecting. So this indeed confirms what mkarcher said above.
netdrive.sys didn't work, either. I tried to use devload, since I believe DOS Plus doesn't load DOS drivers (since it's CP/M-86 really).
Unfortunately, my copy of devload says it needs DOS 3 to 6. drvload says it needs DOS 3, too.
Of course, that's all too understanding. DOS Plus isn't a real DOS, after all.
But still, I felt like I have to test this. DOS Plus shipped with the Amstrad/Schneider PC1512 and PC1640.
So it used to be a very widespread DOS 2 compatible OS here in Europe.
Even though that MS-DOS 3.20 was also included, along with GEM.