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

So it's been a month of nothing but the sound of crickets in this thread. I keep seeing the download counters for my releases increasing steadily but no feedback whatsoever (for me or for Mike). Are the downloads all made by bots or what?

Anyway, if you're NOT a bot then this might be of interest.

Speaking for myself, I think vogons could really use a "react" button so people can show appreciation for posts without having to actually reply and clog up a thread. I myself appreciate the update, and have been using mTCP NetDrive regularly, but I haven't tried the new version yet as the old one has been stable for me, and I've been working on fixing other issues with my setup.

Yeah, the lack of any feedback is interesting.

I write my hobby code for my personal satisfaction and if it benefits somebody else that is a bonus. Implementing the read-ahead feature in a safe way that doesn't result in data corruption was not a trivial amount of work, and on slightly faster hardware it was giving a 4 to 5x speed-up on reads. I was going to start on streaming writes next to speed those up, but given the lack of interest I've moved onto other things not related to mTCP.

Side note: The read-ahead code was test code to try to see if it was interesting to people or to confirm that it improved performance in other setups. I wouldn't reverse-engineer or re-implement such code - it's subject to change based on what I learn. I'd wait for a formal release before doing anything with it.

I've suggested "Kudos" or any kind of "positive-only" reaction/rating system for this forum for a while, but i haven't been able to persuade the decision makers to bring this feature into this forum...

I also use the full mTCP stack regularly, it is in my set of essential tools.

I agree, thumbs-up would be nice. But for what it's worth, whenever I have the time to fiddle with my old gear, mTCP and friends is a constant companion. My next project is updating the mTCP binaries on the Floppy Museum and adding NetDrive to the mix, so I can serve larger files. :)

_Krille_ wrote on 2025-05-28, 17:58:

Anyway, if you're NOT a bot then this might be of interest.

Consider shipping the documentation together with the software - online forums are often volatile, and it's simply more convenient to have all the related stuff packaged in one ZIP file.

Also, your NetDrive client isn't self-sufficient - it needs the server, the DHCP client, possibly something else.
In this case, it would be a good idea to clearly state which version(s) of the external stuff you have tested your client with, and can guarantee their compatibility.

Grzyb wrote on 2025-05-30, 17:56:

Consider shipping the documentation together with the software - online forums are often volatile, and it's simply more convenient to have all the related stuff packaged in one ZIP file.

Also, your NetDrive client isn't self-sufficient - it needs the server, the DHCP client, possibly something else.
In this case, it would be a good idea to clearly state which version(s) of the external stuff you have tested your client with, and can guarantee their compatibility.

Well, it is a drop-in replacement for Mike's driver with the release date indicating which version it is compatible with. For example, the latest release from Mike says "mTCP NetDrive (Apr 28 2025) by M Brutman (C) 2023-2025 (www.brutman.com/mTCP)" and if my driver says the same then you know that my driver is compatible* with Mike's. My driver also says; "Reverse Engineered by Krille" and gives another date - that is the build date of my driver and this can be used to determine which of my releases is the latest - if I ever need to release new versions to fix bugs or introduce new functionality without changing compatibility with Mike's software (the server and/or the NETDRIVE.EXE client software).

As for including documentation; a quick peek at the source (which, admittedly is not always included) should be sufficient IMHO but perhaps I should include a minimal README to explain the differences from Mike's driver.

Thanks for the feedback!

* At least this is true regarding the prebuilt binaries in my releases as well as the result from making the driver from source if you don't enable any additional defines in it. There are defines that you can enable which currently will make the driver incompatible with Mike's version of NETDRIVE.EXE but that's clearly stated in comments in the list of defines in the beginning of the source file. I am hoping that Mike will implement the changes required to NETDRIVE.EXE since they are simple changes and are all for reducing memory usage and increasing efficiency - I'm not a C programmer and would very much prefer not having to release a separate version of NETDRIVE.EXE as well.

(Reposting a shorter version of the original message ...)

Except in some cases your driver is not quite the same. You mention you can't unload the packet driver after a connection is made. You also don't use the secondary packet driver interrupt number, which I do for good reasons.

Also, the code I shared in April was a test to gather early feedback. I normally don't share code speculatively like that, and I never expected to see that reverse engineered. It was tricky code to write and even before getting feedback from others (good or bad) you reverse engineered it and released your own version. I hope you did all of the testing that I did and were careful with the code, as it's subtle and can easily cause data corruption problems if something is out of place. I'm not going to share test code like that again because it's bad enough if I expose somebody to a bug, and I don't want other people getting hit by additional bugs due to the reverse engineering and reimplementing.

mbbrutman wrote on 2025-04-29, 01:17:

Test code that has read-ahead caching is available. If you are using NetDrive and are slightly curious, please give it a shot a […]
Show full quote

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

The new cache feature has made a massive difference for me. Command and Conquer intro's used to stutter, now they are butter smooth. It took 10 seconds for the main menu to appear, now it takes 3 seconds. Well Done!

zuldan wrote on 2025-06-08, 03:58:

mbbrutman wrote on 2025-04-29, 01:17:

Test code that has read-ahead caching is available. If you are using NetDrive and are slightly curious, please give it a shot a […]
Show full quote

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

The new cache feature has made a massive difference for me. Command and Conquer intro's used to stutter, now they are butter smooth. It took 10 seconds for the main menu to appear, now it takes 3 seconds. Well Done!

This may sound odd, but until I read your post, I hadn't thought of running large late DOS games directly from the drive. I've mainly used it to shunt files on and off the machine. With the speed good enough now, it makes me wonder how hard it'd be to hack MSCDEX.EXE to read from a CD image on the mounted drive, so we could have swappable CD images from network storage. Of course, analog CD audio wouldn't work so it probably wouldn't be much use in practice.