I found two issues, one with the current version, and one with the testing version.

Testing version: Does not work with qemu slirp (user networking). I get many: "qemu: Slirp: Failed to send packet, ret: -1" lines. Therefore, I have not investigated further.

Current version: When smartdrv is activated for the netdrive, it tends to hang pretty quickly. My test case is running the Borland C++ DOS IDE from a NetDrive. Happens on real hardware and in qemu, the only difference being that in qemu, it hangs upon entering the IDE, while on real hardware, after leaving it. Happens with the Aug 2024 version and with the current one (Jan 2025); the testing one does not work on qemu slirp. Happens with both the E100B packet driver and the RTL8139 one. If smartdrv is loaded before the netdrive is connected, the problem is side-stepped, because smartdrv does not activate itself for the non-connected netdrive. Everything with MS DOS 6.22 in real mode (no EMM386). This might have been encountered by others, but I don't remember it being mentioned prominently anywhere.

Qemu:

The qemu message is an error message that basically says it tried to pass a packet to the host machine to send, and it could not. The test version of NetDrive isn't doing anything differently when sending packets, and it certainly should not be able to force an error message in an emulator. If you revisit this I'd like to know more about when those error messages appeared, and what NetDrive was doing at the time. (Was it the initial connect? Were you doing a performance test?) The error messages might be harmless and there just for debugging purposes.

I'm testing with 86Box here, which is different than qemu but it's also using SLiRP for packet handling. I'm not having any problems with it here even when doing performance testing.

SmartDrv:

I'm testing with a remotely connected drive that has SmartDrv enabled while in Windows 3.11 ... It's behaving normally and the status from SmartDrv show that it is getting cache hits. So I think it's working.

However, I'm also testing with a much newer version of the test read-ahead test code. My current version has larger stack sizes than the April test version, which can help in a complex environment. Would you be willing to test a newer version of the test code?

Regarding slirp: I thought it was during initial connection, but I rechecked now. It happens as soon as I do anything more than "dir" (run scandisk on the drive or run the Borland C++ IDE from it). Everything else remaining the same, with the released netdrive version these things work like a charm.

More testing: With a different packet driver it works, so there is no evidence that netdrive is misbehaving.

I prepared a new test version:

• DOS NetDrive binaries: http://brutman.com/mTCP/download/mTCP_NetDriv … 6-09-09_DOS.zip
• NetDrive servers: http://brutman.com/mTCP/download/mTCP_NetDriv … _2026-09-09.zip

Changes from the previous test version:

• 486 CPU detection added and default read-ahead for 386 systems reduced.
• Reduce the time interrupts are disabled when using write-verify on larger writes.
• Increased stack sizes; not related to performance but this helps in complex environments

It's been working perfectly for me in a few different environments. If you don't want to install the test server locally my public test server at brutman.com:2002 works. (Connect to "fat12.dsk" or "bigdisk.dsk".)

I have not tried your new versions yet.

Regarding smartdrv, I have not found a single installation that did not exhibit this behavior: Run BC++3.1 IDE (from netdrive), exit, load smartdrv, run again -> Hang

I have observed this behavior on:

• qemu+slirp, rtl8139
• Cyrix 486, rtl8019as
• P200MMX, E100B
• P-III 600, 3c509
• P4 2.8GHz, 3c940