_Krille_ wrote on 2025-07-16, 22:36:

Grzyb wrote on 2025-07-15, 12:54:

It seems necessary to keep two versions of the driver (6,144 vs. 10,672 Bytes of memory used), eg. NDSMALL.SYS and NDFAST.SYS.

A better solution is to provide the read-ahead cache size as a parameter on the CONFIG.SYS command line. Then you can decide yourself exactly how much memory you want to spend on the read-ahead caching. In other words, a compromise between transfer speed and memory usage. The next (not yet released) version of my driver works this way.

Seems a good idea.

It is possible for a driver to allocate extra memory during initialization, but not after init, eg. when connecting the drive, right?

Grzyb wrote on 2025-07-16, 22:38:

_Krille_ wrote on 2025-07-16, 22:13:

mbbrutman wrote on 2025-07-15, 15:48:

The longer term solution is to have the device driver dynamically adapt to network conditions and adjust the read-ahead cache on the fly.

This is simply not possible. Once the device driver has initialized, its size can not be changed.

I guess the idea is not to change the DRIVER size, but only the CACHE part.

Unfortunately, can't avoid wasting memory when current cache size is lower than the maximum reserved in the driver.

Yeah, reducing the cache size without also freeing memory would be pointless.

Grzyb wrote on 2025-07-16, 22:43:

_Krille_ wrote on 2025-07-16, 22:36:

Grzyb wrote on 2025-07-15, 12:54:

It seems necessary to keep two versions of the driver (6,144 vs. 10,672 Bytes of memory used), eg. NDSMALL.SYS and NDFAST.SYS.

A better solution is to provide the read-ahead cache size as a parameter on the CONFIG.SYS command line. Then you can decide yourself exactly how much memory you want to spend on the read-ahead caching. In other words, a compromise between transfer speed and memory usage. The next (not yet released) version of my driver works this way.

Seems a good idea.

It is possible for a driver to allocate extra memory during initialization, but not after init, eg. when connecting the drive, right?

The only legal documented DOS functions that can be called during initialization are functions 01h to 0Ch, and 30h, so none of the memory allocation calls (48h to 4Ah) are allowed. There are undocumented exceptions to this - for example, I use function 52h in my driver to be able to display the first NetDrive drive letter under DOS 2.x.

After initialization you wouldn't be able to do memory allocations either, if nothing else because the foreground application might (and probably will) have all memory allocated to itself so any attempts to allocate more memory will fail because there is no free memory available.

If this code gets released ... exactly three people have tried it and told me about it so far.

There will always be two versions of the device driver:

• One version that doesn't have the read-ahead cache feature at all.
• One version that has the feature, and lets you choose the maximum cache size at initialization time.

That way people who don't want to use the cache feature don't pay for the extra overhead. (Even with the cache size set to 0 the code would still be in the driver, and parts of it would still be running, and that's not desirable.)

And for the version that does support caching, I want it to be able to set the read-ahead parameter dynamically.

_Krille_ wrote on 2025-07-16, 23:50:

Yeah, reducing the cache size without also freeing memory would be pointless.

From what I understand, the point is that *sometimes* the maximum (4 KB) is not optimal.

In my experiments - both local, and using that brutman.com on the other continent - the best performance was always at 4 KB.
But I guess it may be different in other conditions.

The only legal documented DOS functions that can be called during initialization are functions 01h to 0Ch, and 30h, so none of the memory allocation calls (48h to 4Ah) are allowed. There are undocumented exceptions to this - for example, I use function 52h in my driver to be able to display the first NetDrive drive letter under DOS 2.x.

So how do you make your driver use different amounts of memory depending of the command line parameter?
There's plenty of drivers that work this way, eg. VDISK.SYS/RAMDRIVE.SYS.

At initialization time the driver tells DOS where to load the next device driver. If the driver tells DOS to load over itself, that means the driver failed to install. Otherwise, the driver points at memory far enough way to protect the code that it needs and any data structures. For example, if you have 4KB of code and 1KB of data, the initialization code will tell DOS to load the next device driver 5KB away.

One neat trick is that since the initialization code only runs once, you can place it at the end of the driver and then tell DOS to load the next device driver on top of the start of the initialization code. Or use that as the start of your RAM data area.

NetDrive already does this - the amount of memory to support a drive letter is something like 96 bytes. So if you install just one drive letter you get the smallest possible size, while reserving 24 drive letters takes up 96*24 more bytes in memory. Adding a parameter to reserve RAM for cache is trivial - it just wasn't needed for test code.

The benefit of the cache RAM depends on your conditions. On my local network a 386-40 gets much more improvement from the first one or two KB of cache RAM than it does for the next 1 or two KB of cache RAM. For DOS systems it makes sense to have the cache RAM be the same as the cluster size, as that is what DOS is going to request. Up to 8KB would make sense. More would suffer from the law of diminishing returns.

Is there any update on the availability of a Windows driver?

Also,

mbbrutman wrote on 2024-01-08, 21:11:

• Add code to detect (and reject) opening the same image multiple times in read-write mode.

I know I can set a timeout on the server but perhaps the client should check with the server it's connecting to to see if it has any existing sessions and to resume them(or close+reopen) if the client needed to reboot or crashed or something. I was setting up netdrive today and was so confused by it complaining that it can't open the image read-write again.

I don't know of anybody working on a Windows driver. I'm not even going to try it - Windows internals is above my pay grade. (If it were properly documented and there was an active community of people who could help it would be possible, but that's not what we have.) I have forced Windows 98 to use a network drive, but it disabled 32 bit IDE access, my CD-ROM, and you would need a second network card if you wanted Windows networking at the same time. But it worked ...

The ability to lock a hard drive to a specific client is on the near-term todo list. That will allow you to resume a session by just connecting again, without having to kill the session on the server.

This quote is from here. I'm not a member there so I'll ask my questions here instead.

mbbrutman wrote:

I have found and fixed the bug; I did not disable interrupts while DOS was copying data from the cached read-ahead blocks, and newly arriving read-ahead blocks were arriving at the same time, stepping on what was being copied from the cache.

I don't understand how this can happen. For each transfer* the server sends (at most) enough sectors to fill up the read-ahead cache and then a final packet with the first couple of sectors. How can there be additional sectors arriving while the cached sectors are being copied? Nothing is sent by the server unless the client requested it, so how can this be?

* With transfer I mean the sectors transferred under the same Unit Sequence. Speaking of Unit Sequence; I've been meaning to ask you about a possible bug I found a long time ago;

1seg000:15A1 _ServerCommandEightyReturned:           ; CODE XREF: seg000:14CBj
2seg000:15A1                 mov     ax, pPreviousDriveData
3seg000:15A4                 cmp     pCurrentDriveData, ax
4seg000:15A8                 jz      short loc_15AD
5seg000:15AA                 jmp     _ExitReceiver
6seg000:15AD ; ---------------------------------------------------------------------------
7seg000:15AD
8seg000:15AD loc_15AD:                               ; CODE XREF: seg000:15A8j
9seg000:15AD                 mov     ax, [bx+12]
10seg000:15B0                 cmp     ax, wUnitSequence
11seg000:15B4                 jb      short _ExitReceiver    <--- BUG?

The Unit Sequence in the packet is compared with the saved value in wUnitSequence (identifying the current transfer) but the packet is only discarded if the sequence number in the packet is lower than the expected value. Shouldn't that be an exact match? E.g. JNE instead of JB? As I understand it the sequence number cannot actually be higher (at least not until the next transfer) so it really shouldn't matter but it looks weird to me.

Okay, I did launch Windows 3.0 File Manager and I have found that drives I through L are treated as regular hard disk drives even if it's connected using mTCP NetDrive.

Would it be possible to find a way to treat the connected hard disk drive images that are redirected over a network as a true network drive and display network drive icons, instead of hard disk drive icons...or is it not possible?

Thanks in advance. 😀

How would a DOS device driver know or care how Windows presents it on a GUI?

As far as Windows (and DOS) is concerned, this is a block mode device. Neither have any concept that there is a network behind it. That is completely different than the "Network Redirector" interface, which presents a filesystem view of a remote filesystem, not a low-level block view.

Dear mbbrutman,

Is there maybe now any plan to publish mtcp server for openwrt platform ? I would assume this could spread usage as lot of people might use openwrt router to connect their retro machines?

Thanks

Marco wrote on 2025-11-03, 06:23:

Dear mbbrutman,

Is there maybe now any plan to publish mtcp server for openwrt platform ? I would assume this could spread usage as lot of people might use openwrt router to connect their retro machines?

Thanks

Good suggestion! Seconded. 👆🏼

Although enabling that in a home router might pose a security risk, if configured incorrectly. For one thing, it would be good to package it with a default configuration that never binds the service to the WAN port.

Marco wrote on 2025-11-03, 06:23:

Dear mbbrutman,

Is there maybe now any plan to publish mtcp server for openwrt platform ? I would assume this could spread usage as lot of people might use openwrt router to connect their retro machines?

Thanks

Hi,

I'd like to be able to help but it takes a lot of time to develop and support things like mTCP and NetDrive, and I can't take on any more side projects. I'm happy to entertain feature requests because those help everybody, but packaging for individual environments is a huge time sink.

It's open source ... See if you can do it yourself, and ask me questions if you get hung up on an problem with the code.

Mike

Anybody had sucess running the server with Windows 7 with Vxkex?

Thanks for clarification Mbbrutman

The Docker image available from https://hub.docker.com/r/smeed/netdrive by smeed has not been updated to the last version of mTCP/Netdrive, and the build script does not work on the new bin server files (2025-01-10) available from Brutman.com.

So I went ahead and made a new build myself using a modified version of the script. Sharing it here if anyone is interested.

Confirmed working on my Synology NAS.

@mbbrutman. I see the read-ahead version is not available for download any longer, is there any specific reason?

1# ---- BUILD
2FROM busybox AS unpack
3
4ARG NETDRIVE_SERVER_VERSION=2025-01-10
5
6WORKDIR /unpack
7
8# get the multiarch binary and unzip it
9ADD https://www.brutman.com/mTCP/download/mTCP_NetDrive_server-bin_${NETDRIVE_SERVER_VERSION}.zip /tmp
10RUN unzip /tmp/mTCP_NetDrive_server-bin_${NETDRIVE_SERVER_VERSION}.zip -d /tmp
11RUN mv /tmp/mTCP_NetDrive_server-bin_${NETDRIVE_SERVER_VERSION}/* .
12
13# and create a generic entrypoint
14RUN echo "$(uname -s)/$(uname -m)" > arch.txt \
15 && case "$(uname -s)/$(uname -m)" in \
16         "Linux/x86_64")  FILE=netdrive_linux_amd64   ;; \
17         "Linux/aarch64")  FILE=netdrive_linux_arm64  ;; \
18         # "Darmin/arm64") FILE=netdrive_darwin_arm64 ;; \ <-- In docker on arm it will do Linux/aarch64 and will run just fine
19    esac \
20 && mv ${FILE} netdrive
21
22# ---- RUN
23FROM alpine:3
24
25# we need some libc for Go binaries to run
26RUN apk add libc6-compat
27
28
29WORKDIR /app
30COPY --from=unpack /unpack/ /app
31RUN mkdir /images
32
33# create a logfile which points to stdout
34RUN ln -sf /dev/stdout netdrive.log 
35
36EXPOSE 2002/udp
37ENV NETDRIVE_LOG_LEVEL=info
38
39ENTRYPOINT ["/bin/sh", "-c", "/app/netdrive -log_file netdrive.log -log_level ${NETDRIVE_LOG_LEVEL} serve -headless -image_dir /images -port 2002"]

As a workaround for the client restart/shutdown issue when running in headless mode I plan to setup a script to restart the docker container on my NAS so I can Telnet in from my retrocomputer and it executes on login. Saves me from getting my modern laptop/machine and login to my NAS.

vetz wrote on 2026-01-11, 20:40:

@mbbrutman. I see the read-ahead version is not available for download any longer, is there any specific reason?

I got very little feedback about how it was working for people, which is a sign that there was very little interest in it. This year I might give writes the same treatment, and make them faster. If I do that I'll try again with distributing test code.

-Mike

mbbrutman wrote on 2026-01-12, 01:49:

vetz wrote on 2026-01-11, 20:40:

@mbbrutman. I see the read-ahead version is not available for download any longer, is there any specific reason?

I got very little feedback about how it was working for people, which is a sign that there was very little interest in it. This year I might give writes the same treatment, and make them faster. If I do that I'll try again with distributing test code.

-Mike

Read ahead version has been working great. Massive speed improvement. I use it as the standard on all my DOS machines (too many).

mbbrutman wrote on 2026-01-12, 01:49:

vetz wrote on 2026-01-11, 20:40:

@mbbrutman. I see the read-ahead version is not available for download any longer, is there any specific reason?

I got very little feedback about how it was working for people, which is a sign that there was very little interest in it. This year I might give writes the same treatment, and make them faster. If I do that I'll try again with distributing test code.

-Mike

That is really unfortunate, and I guess I'm part to blame there as well. For me it was a bit of a hassle to set it up as I'm using the server inside a docker container, but now I'm able to build new versions myself. A large motivating factor here was to enable me to test the read-ahead functionality.

The read-ahead function will eventually get out; it just makes more sense now to do the same for writes too before I release it. Depending on the machine and the distance to the server it increased the speed by 5x, which is something I need/want for usage with public servers.

There is also plenty of other work to be done too, but I'm having problems finding the time to get to all of it. But rest assured, it's not dead.