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.
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.
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".)
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 haven't tried it yet, but now it may be possible to play IPX multiplayer games from NetDrive disks...
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
EDIT: I used a slightly different version of the packet driver, but because it happens everywhere, I figure it does not matter. Anyway, I tried this one now, and nothing changed: https://theretroweb.com/drivers/158
Celeron 266
DM9PCIPD
NetDrive 2025-01-10 works fine.
The new version, however, fails when writing:
The attachment nd26.png is no longer available
But the same new version works fine on another machine:
Pentium III 800EB
E100PKT
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
But the same new version works fine on another machine:
Pentium III 800EB
E100PKT
Correction: it fails on this machine as well, but it's harder to observe - sometimes it successfully writes even large files, sometimes not:
The attachment error.png is no longer available
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
Grzyb - Did you try using "Retry" when you got those messages? If so, what happened?
No storage device is guaranteed to do what you ask every time; transient errors are possible. If those are being caused by network congestion or the read-ahead caching being too aggressive, then hitting Retry should get you past that specific transient error. That is perfectly normal behavior. If the machine locked up or the drive letter was never usable again then I would consider that to be a problem.
If it is a transient error, retry your test but reduce the size of the allowed read-ahead. Your server might be flooding your client.
Ringdingwrote on 2026-09-11, 18:14:I just did the most basic installation of https://winworldpc.com/download/40c38f3a-5518 … c3-a4e284a2c3a5 and https://winworldpc […] Show full quote
EDIT: I used a slightly different version of the packet driver, but because it happens everywhere, I figure it does not matter. Anyway, I tried this one now, and nothing changed: https://theretroweb.com/drivers/158
I've installed DOS 6.22 and BC from your links. I'm using VirtualBox with the PCNet packet driver.
The only time I can get it to hang is if I tell SmartDrv to enable the write cache for drive d. When I do that it hangs every time. If I don't do that, it works every time.
Can you confirm that you are getting the hang when write caching is enabled? (Read caching is obviously fine.)
Now using the Celeron, where I'm confident that the old version works without problems...
The attachment zero_ra.png is no longer available
It's seriously broken.
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
Now using the Celeron, where I'm confident that the old version works without problems...
The attachment zero_ra.png is no longer available
It's seriously broken.
I need to know if it is making any progress ... please look at the server side and use the status command there while this is happening. If you retry and the server doesn't report any more blocks being read or no commands come in, then it is broken on your system as opposed to a transient error. If it makes progress, then it's a transient error.
Are you still using the ODIPKT setup when you do this?
Can you confirm that you are getting the hang when write caching is enabled? (Read caching is obviously fine.)
I don't tell it. It is just on by default. But yes, it is on.
Well, that's interesting because on my system it is not on by default. I have to explicitly tell SmartDrv to enable write caching when turning it on for drive D. And the DOS install added the /X flag to SmartDrv which disables write-behind caching for all drives. So I have no idea why your system things write caching should be turned on.
Also, this is not a problem with the new code. The 2025-01-10 version of Netdrive behaves the same way. Write caching is generally fine, and I can copy files around on D from the command line with no problems. But starting BC causes the hang.
In 2003, I voted in favour of joining the European Union. However, due to later developments - especially the restrictions on cash usage - I have withdrawn my support. DOWN WITH THE EU!
