_Krille_ wrote on Yesterday, 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 Yesterday, 22:38:

_Krille_ wrote on Yesterday, 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 Yesterday, 22:43:

_Krille_ wrote on Yesterday, 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 Yesterday, 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.