zuldan wrote on 2025-04-06, 16:11:

_Krille_ wrote on 2025-04-06, 14:42:

Grzyb wrote on 2025-03-31, 18:08:

Can't NETDRIVE.SYS provide its PD emulation at the same interrupt number as the real PD?

That's how my version works. See this.

So with your version I’ll be able to mount a drive plus play IPX network games like Command & Conquer at the same time? That would be awesome.

Is there another way to download it? Vcfed wants a username and password 🙁

I doubt that will work, sorry. But you could always try it I guess.

Hi,

I posted this over at VCFed but I see the download is mirrored here as well, so I'm duplicating that post here ...

Not to be too nit-picky here, but my code is GPL 3.0 and if you started with my code, then your code is also GPL 3.0. Which means you are bound by the GPL 3.0 license terms too:

• You have to ship the source code, not just the binaries.
• You need to include the GPL 3.0 license file in whatever you distribute.
• You need to attribute the original author and their work in whatever you ship.

Please update your download to be compliant with the open source license. Also, I would encourage you to do more testing. I do extensive testing on a variety of machines and virtual machines to ensure it works and doesn't corrupt data. I really don't want alternative versions of NetDrive doing something bad, and then I have to deal with the fallout or my project's name getting tarnished.

zuldan wrote on 2025-04-06, 16:11:

So with your version I’ll be able to mount a drive plus play IPX network games like Command & Conquer at the same time? That would be awesome.

A way to achieve that with virtually any software that uses packet drivers is pktmux:
http://cd.textfiles.com/pdos9606/NETWORK/TCPI … AL/PKTMX12I.ZIP

I use it for a number of things - to multitask different mTCP programs in desqview and to run multiple file sharing protocols at once.

Here's a new release of my driver, this time including the source code!

Coming soon ... better performance over long distances using read-ahead caching!

There are two things that limit the speed of NetDrive - the distance from the server and the speed of the DOS machine. This change tackles the distance problem.

On the same network the round trip time between a DOS machine and a server is pretty low (1 or 2 milliseconds), so the speed of NetDrive is fairly decent - a 386-40 can do almost 400KB a second. But with just 2KB of read-ahead cache I can get that number closer to 600KB a second. Slower machines don't benefit as much but even on the worst machine I have (a PCjr with a Xircom Ethernet adapter) I saw a 30% speed bump.

The difference really shows up on remote servers. That same 386-40 gets a 5x speed bump when doing reads to a distant server with just 4KB of cache. Even the PCjr sees a 2x improvement. That kind of speed makes things like shareware repositories and shared game drive letters across the Internet quite usable.

I need to write a small utility that will help provide the right setting for the read-ahead cache, but otherwise the feature is done and ready to go.

That's awesome! thanks for your continued push!

You are welcome!

These are the fun parts of the project - pushing the boundaries of what is possible. Instead of trying to do micro-optimizations to save a few microseconds (*) here and there I'm going for the much bigger targets.

The key observation here is that normal hard drive images have multiple sectors per cluster, and file reads are done by cluster. So if you know that DOS has to read 4 or 8KB for a cluster then avoid the Christmas rush and just start sending it what it needs after you see the start of the read. Unless the DOS machine is very slow or has a network card with a tiny amount of RAM, it generally reduces CPU load and cuts out the network wait time. You still have to wait one full round trip for the first packet to arrive, but then after that the other packets are probably in your read-ahead cache and ready to be used.

Testing against a local server, the 386-40 went from 390KB per second to 684KB per second using an additional 4KB of memory. Testing against a remote server it went from 20KB to 86KB per second. Playing CD-ROM based games using NetDrive+SHSUCD locally should feel like having a real 4x CD-ROM.

I'm going to post some test code soon and update my public server so that people can try it out for themselves. I'm looking forward to doing the DOS drive letter version of the old SIMTEL archive.

* And yes, minor tweaks to assembler opcode really only do save microseconds - that is not an exaggeration.

mkarcher wrote on 2023-12-11, 21:54:

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.

Yoghoo wrote on 2023-12-12, 10:26:

Tried it today with devload and sysload to start netdrive.sys from the command line instead of the config.sys.

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.

I saw discussion about this issue here, but no solution. I've got one for anyone interested. For the typical case where you have a single CD drive and you want to load a single netdrive, and you want the netdrive to use the drive letter following the CD drive (IE, CD drive is "D", netdrive is "E"), here's what you do:

1. In config.sys, request two netdrives rather than one:

1DEVICE=C:\TOOLS\MTCP\NETDRIVE.SYS -d:2

2. In autoexec.bat, use the "DRVOFF.EXE" tool to blat the CDS entry for the netdrive mount at the desired CD drive letter prior to loading MSCDEX.EXE:

1C:\TOOLS\DRVMOD\DRVOFF.EXE D:
2C:\DOS\MSCDEX.EXE /D:CDROM /L:D

3. Now mount your netdrive using the second mount point rather than the first:

1C:\TOOLS\MTCP\NETDRIVE.EXE connect <IP:Port> <File> E:

Everything works perfectly this way, since network redirectors sit "above" physical drive access, so netdrive is unaware that anything has happened. If you do attempt to issue a netdrive connect command against the "overloaded" drive letter, the current driver seems to gracefully reject it, considering it to not be a netdrive, presumably because it checks the CDS entry first.

The details for why this all works are in the brilliant "Undocumented DOS" book here: https://archive.org/details/Undocumented_DOS, which is also the origin of DRVOFF.EXE, with the source included in the book. I couldn't find a handy download link for the original discs from this book publicly accessible on the net, but I did find a copy of DRVOFF.EXE randomly here: https://github.com/Fortyseven/RA_1993/blob/ma … UTIL/DRVOFF.EXE

DivByZero wrote on 2025-04-28, 17:55:

I saw discussion about this issue here, but no solution. I've got one for anyone interested. For the typical case where you have […]
Show full quote

I saw discussion about this issue here, but no solution. I've got one for anyone interested. For the typical case where you have a single CD drive and you want to load a single netdrive, and you want the netdrive to use the drive letter following the CD drive (IE, CD drive is "D", netdrive is "E"), here's what you do:

1. In config.sys, request two netdrives rather than one:

Copy code to clipboard

1DEVICE=C:\TOOLS\MTCP\NETDRIVE.SYS -d:2

2. In autoexec.bat, use the "DRVOFF.EXE" tool to blat the CDS entry for the netdrive mount at the desired CD drive letter prior to loading MSCDEX.EXE:

Copy code to clipboard

1C:\TOOLS\DRVMOD\DRVOFF.EXE D:
2C:\DOS\MSCDEX.EXE /D:CDROM /L:D

3. Now mount your netdrive using the second mount point rather than the first:

Copy code to clipboard

1C:\TOOLS\MTCP\NETDRIVE.EXE connect <IP:Port> <File> E:

Everything works perfectly this way, since network redirectors sit "above" physical drive access, so netdrive is unaware that anything has happened. If you do attempt to issue a netdrive connect command against the "overloaded" drive letter, the current driver seems to gracefully reject it, considering it to not be a netdrive, presumably because it checks the CDS entry first.

The details for why this all works are in the brilliant "Undocumented DOS" book here: https://archive.org/details/Undocumented_DOS, which is also the origin of DRVOFF.EXE, with the source included in the book. I couldn't find a handy download link for the original discs from this book publicly accessible on the net, but I did find a copy of DRVOFF.EXE randomly here: https://github.com/Fortyseven/RA_1993/blob/ma … UTIL/DRVOFF.EXE

Nice workaround! I'm using NetMount at the moment (https://github.com/jrohel/NetMount) if I'm not using the mTCP FTP tools. NetMount does not need a config.sys entry at all and just works from the dos prompt so no more drive problems.

Test code that has read-ahead caching is available. If you are using NetDrive and are slightly curious, please give it a shot and let me know how it works for you.

• https://www.brutman.com/mTCP/download/mTCP_Ne … 5-04-28_DOS.zip
• https://www.brutman.com/mTCP/download/mTCP_Ne … _2025-04-28.zip

Depending on your machine speed and server distance it can be as much as 5x faster, with just a 4KB read-ahead cache. Remote connections see the best improvement, but even faster DOS machines on a local network will see good improvement.

I'm looking to get some feedback on the new feature - how easy it is to use, and what kind of speed-ups you might get. Most people probably don't have a remote server to test against so I have updated the one at brutman.com (port 2002) with the new code. So if you have the new device driver, you can test against that to see what kind of speedup you get. In theory you can get the full 5x speedup if you are slightly distant from it.

For measuring the speedup use the new ND_CAHE.EXE program, which is included in the DOS download.

Thanks,
Mike