Somebody actually went ahead and put in a lot of effort to do the work ahead of me to add that feature, and he got it working today. So technically it's definitely feasible, but I haven't had a chance to get to work on it myself. (As tempting as it is, I'm not going to reuse that work because we have very different coding styles and I want to do the work myself.)

In the short term I want to add a read-ahead feature to make remote servers perform better and the packet driver emulation layer to allow other network programs to run at the same time. But I won't have anything for a few more months because these things take time and a lot of testing.

-Mike

mbbrutman wrote on 2024-08-30, 02:35:

Somebody actually went ahead and put in a lot of effort to do the work ahead of me to add that feature, and he got it working today. So technically it's definitely feasible, but I haven't had a chance to get to work on it myself. (As tempting as it is, I'm not going to reuse that work because we have very different coding styles and I want to do the work myself.)

In the short term I want to add a read-ahead feature to make remote servers perform better and the packet driver emulation layer to allow other network programs to run at the same time. But I won't have anything for a few more months because these things take time and a lot of testing.

-Mike

Thanks for the heads up. I'm proud to see someone put a lot of effort to do the work ahead of you and I appreciate it! I'm looking forward to see the read-ahead feature and the packet driver emulation to be implemented soon. 😀

For the time being, I'm gonna have to hold off on using NetDrive for a while. 😄

There is always EtherDFS if you need a network drive and want to run other packet driver applications at the same time.

mbbrutman wrote on 2024-08-30, 04:05:

There is always EtherDFS if you need a network drive and want to run other packet driver applications at the same time.

Thanks for the heads up. I appreciate it. 😀

I had some fun with netdrive and made a gentoo ebuild repo to provide netdrive as a systemd service which can be found here:
https://github.com/ccharon/netdrive

After everything worked to my liking on the server side I switched over to the client and wanted a convenient netdrive setup at boot. The problem there is, sometimes I boot with a scsi zipdrive so the drive letter of the first netdrive is moving.

To be able to find the netdrive i thought of something like this (in autoexec.bat)

(typed from memory so it might be slighly off)
...
C:\TOOLS\FNDRV.EXE /L NOTATTACHED
C:\NET\NETDRIVE CONNECT myserver:8086 disk.dsk %FNDRV%
...

So there is a tool needed that is called FNDRV.EXE that accepts a Label as parameter and then puts the first drive letter with the correct label into an env variable FNDRV so i can use it.

so I made a lib to write into the environemt and the fndrv.exe that enumerates the drives and looks for labels.
Lib: https://github.com/ccharon/dos-programming/bl … VIRO/ENVIRO.PAS
FNDRV: https://github.com/ccharon/dos-programming/bl … NVIRO/FNDRV.PAS

The program is tested on MSDOS 6.22 with command. com as shell (4dos is not working)

Why am I writing all this?
Because I can find every Drive by label except the netdrive provided drives ... int 21h, ah=44h, al=0dh dos call does not seem to find drive details. (this part of the code:
https://github.com/ccharon/dos-programming/bl … DRV.PAS#L41-L80)

using DIR F: for example i can see the not connected drive with the label NOTATTACHED but my program can not find it by its label using the dos interrupt calls.

Has anyone delved deep enough in this rabbit hole to provide suggestions? hehe maybe i can even "ask" the netdrive TSR for the first drive letter?
All i want to do is to know which drive letter is the first netdrive 😜

All code compiles and runs under Turbo Pascal 7 for DOS

INT 21 AH=44 subfunction 0D is "generic IOCTL", which the NetDrive device driver does not implement. (It is optional and seldom used, so I left it out.) If you want to detect a NetDrive device letter do the following:

DOS allows you to do IOCTL reads and writes to a device using function AH=44, subfunction 04. If you specify a NetDrive drive letter it responds with 8 bytes. The 8 bytes are two far pointers (16 bit offset and 16 bit segment for each pointer). You need to provide a buffer for the device driver to write those two bytes to. My C program does this and the code looks like this:

1  ; DOS wants DS to be the data segment for the 8 byte buffer and DX to be the offset.
2  ; Set those registers up before this point.  This call will write into that buffer.
3  mov ax, 4404h
4  int 21h
5  jnc goodresult
6  mov ax, 0
7goodresult: ; Continue from here ...
8  ; AX should have 8 in it and your buffer will be filled in.

If the call fails the "carry bit" is set. That will result in AX getting set to 0. If the call succeeds then AX will have the number of bytes that were written into the buffer, which for NetDrive currently is 8. If you are lazy you can stop if you see AX=8 after the DOS call. For extra credit, take the first pointer that comes back, subtract 10 bytes, and you will find "NETDRIVE".

I tried your suggestion and it worked. Thanks a lot!

I dropped the whole label search for interrupt call you suggested.
https://github.com/ccharon/dos-programming/bl … RO/FRSTNDRV.PAS
(if anyone is interested, next to the FRSTNDRV.PAS is the FRSTNDRV.EXE ... but i won't be responsible if this eats your dog or worse)

at the end of my autoexec.bat i added:

C:\NET\FRSTNDRV.EXE
C:\NET\NETRDRIVE connect server:8086 disk.dsk %FRSTNDRV%

Depending on the presence of the zip drive, the netdrive gets mounted as E: or F: Great!

One thing I noticed ... when i forget to disconnect the netdrive prior reboot it can only reconnect after i restarted the server. would it be possible to have some unique id that identifies the client and if the same client calls again simply allow a new connection? if there was some state that needed preserving on the clientside it was lost at reboot. and if there is some state at the serverside it can be reset or reused if the clientid is the same.

Finally to understand what I did there ... Is it right to assume that the interrupt call gives back some control structure that would be used by netdrive.sys? and because you know your data structures i can substract 10 bytes because there is something like a header or even the name field of your driver?

If the client drops the connection because of a crash or a reboot the server has no way of knowing that. So the session remains open on the server side. On the server side you can use the "kill" command at the console to flush out an orphaned session without restarting the server. You can also set a session timeout which works well in the case where you shut down the DOS machine and come back a few hours later or another day; setting the server side session timeout will allow it to clean out dead sessions automatically. (You are running it as a daemon so you might want to enable that.)

I used to have an 'auto' reconnect when a client tried to connect and there was already a session open from that client. That made sense when there was only one drive letter, but with multiple drive letters the behavior can become confusing so I disabled it. I'll be able to re-add it in the future but it will be less "auto" - I want it to be something that is explicitly configured per machine and image so there are no strange behaviors. I haven't done that yet because the user interface work takes a while to "get it right" and I don't want to have to make large behavior changes later because I rushed now.

The EXE program does the heavy lifting to connect the server to the device driver, and it stuffs all of the networking information into a shared data structure. DOS doesn't provide an easy way to find a device driver, but the IOCTL call makes up for that - just make the call and if you do it against a NETDRIVE device you get back the pointer to the shared data structure that the EXE program needs. The "go back 10 bytes" thing works because it's a convention that I adopted; the 10 bytes are actually 8 bytes for 'NETDRIVE' and a two byte version number. That trick will always work as long as I remember not to separate the two pieces of data. ;-0

I have somebody who thinks I'm a terrible person because the IOCTL code in the device driver is taking up about 53 bytes. The alternative is to start scanning memory, or to use the undocumented DOS data structures that have offsets that change with each DOS release. The IOCTL is clean and elegant, and it's far more powerful than what I'm using it for here.

I guess I will go with the session timeout. Thanks for the broader view on this matter.

And for :
“I have somebody who thinks I'm a terrible person because the IOCTL code in the device driver is taking up about 53 bytes.”

I hope me asking about this did not stir up some conflicts. I was just curious about why things worked the way you told me and do not really know about “good behavior” in ms dos environments . 😄

For my part, I enjoy using your netdrive. You got me when I was able to use SPEEDISK which was impressive and useless at the same time. 😂
Also it motivated me to dig out Turbo Pascal

Oh no, that conflict has been going on a few weeks. ;-0

The design trade-offs are a big part of the planning for a project like this. When I first started sketching out NetDrive in my head I had a "chicken and egg" problem - the device driver would be loaded first before the packet driver, but they needed a way to find each other. The third program (the EXE) using IOCTL to find the device driver allowed it to make the connections, while also keeping the size of the device driver small. I've never used IOCTL on DOS before.

The later IOCTL call that you bumped into "generic IOCTL" was an answer to DOS not knowing how to handle newer types of storage devices that were not handled by a BIOS. That call allows one to query a device to find it's geometry and properties, and also to format tracks on the device. But it's complicated and it didn't exist until DOS 3.2. It's also optional so I went with my own disk formatter on the server side instead of trying to make DOS's format work.

It's funny you bring up speed disk. Speed disk actually does make things faster on the server side for the same reason it does with a physical disk. Unless it's a journaled drive that you can use the 'go back' feature on. On those the "commit" feature on the server side basically is a defrag.

Greetings!

It is now possible to use mTCP NetDrive and other mTCP programs at the same time! But before I unleash this on the world, I need some additional testing help. If you are interested in seeing the code early and helping out, please send me an email at mbbrutman at gmail dot com. You will get a link to a zip file that includes a test version of all of the code.

I've been testing it since late August and it works great. But I'm paranoid about testing, hence the extra effort here.

Thanks!
Mike

mbbrutman wrote on 2024-09-19, 02:21:

Greetings! […]
Show full quote

Greetings!

It is now possible to use mTCP NetDrive and other mTCP programs at the same time! But before I unleash this on the world, I need some additional testing help. If you are interested in seeing the code early and helping out, please send me an email at mbbrutman at gmail dot com. You will get a link to a zip file that includes a test version of all of the code.

I've been testing it since late August and it works great. But I'm paranoid about testing, hence the extra effort here.

Thanks!
Mike

I sent in my impressions of that test version by email, a bit late, but better than never!

Thank you for the testing - it is appreciated!

I released the new mTCP yesterday. It's basically the same thing you tested, but you probably want to update just to be on the same code as everybody else.

Running under 86Box, I have the NE1000 packet driver on packet interrupt 0x60 and NETDRIVE.SYS on packet interrupt 0x61. The MTCP-based network apps are working with NetDrive enabled now that.

However, non-MTCP based network apps such as Twibright Labs Links browser, the Arachne browser still do not work with the latest NetDrive driver. I'm still getting a Host not found error when trying to access Google via Links in text mode, by the way.

But other than that, thanks for the hard work on NetDrive so far. I appreciate it! 😀

I cheated a bit to keep the device driver simple, so what NetDrive is presenting is not a full packet driver. If the programs that try to use it request all packets they will work fine with it. If they try to request IP packets specifically and then ARP packets specifically, they will not work.

I will probably improve that code in a future version to make it more widely compatible, but it's a lot of extra work.

mbbrutman wrote on 2024-10-25, 02:45:

I cheated a bit to keep the device driver simple, so what NetDrive is presenting is not a full packet driver. If the programs that try to use it request all packets they will work fine with it. If they try to request IP packets specifically and then ARP packets specifically, they will not work.

I will probably improve that code in a future version to make it more widely compatible, but it's a lot of extra work.

Thank you for the heads up! I can't wait improvements to mTCP NetDrive even though it'll be plenty of extra work. 😀

I've just configured netdrive in my Amstrad PC1512, adding a more or less period correct 20Mb drive. The server in a raspberry pi 4, running current Raspberry Pi OS for arm64. I barely managed to cram all the network drivers (for a 3COM Etherlink III, the config program is almost 300K) in a 360K floppy, which loads netdrive and gives control to the virtual hard disk. It works flawlessly, and it has multiplied the computer's functionality while keeping it more or less period correct. Thank you very much!

There was some initial difficulty. For some reason, the PC1512 didn't like images created with netdrive create hd 20 fat16 ... Every time I used one such image, the hard disk would get garbled, losing capacity, and being filled with files with special characters in the name and impossible sizes. The server didn't report any errors or retries. I tried two different, identical cards in different slots, with the same results. I tried different image sizes, from 10 to 40MEG. Same results. So I tried a virtual hard disk in my 386SX and DOS 6.22, in case it was some problem with the server. The 386 worked perfectly with netdrive generated images! So it was some issue with the PC1512. Finally, I tried creating the image file with dd if=/dev/zero of=./pc1512.img bs=1M count=20, and then parted pc1512.img (commands: mklabel msdos ; mkpart primary fat16 1MEG 100% ; quit), and finally mkfs.msdos -v 20.img. With this image, the PC1512 has been working flawlessly for several hours.

Thank you very much again. I love that netdrive allows me to use a hard disk in my XT without having to use definitely anachorinc compact flash or XTIDE.

What version of DOS are you using on the Amstrad? The symptoms you describe sound like the Amstrad was interpreting the drive as a FAT12 drive and not FAT16.

Oh it is right in the picture.

When you used net drive to create the image did you specify FAT16 or FAT16b? DOS 3.2 can only use FAT12 or FAT16. If you give me the exact command you used I should be able to recreate it on DOS 3.3.

Hi. It's MS-DOS 3.2 from the Amstrad install disks. I used fat16, thinking fat12 inefficient. I didn't use fat16b because I wanted a small hard disk. I'll try to replicate the issue again and report.

That would be great ...

• DOS 2.x only has FAT12 available
• DOS 3.x has FAT16 available. (Original FAT16, still limited to 32MB drives but more efficient than FAT12.)
• Compaq DOS 3.31 has FAT16B available too. (Up to 2GB partitions.)
• DOS 4.x and up have FAT16B available

DOS is kind of stupid and it tries to tell the difference between FAT12 and FAT16 by checking the number of clusters on the device. Below a certain number it is FAT12, and above that number it is FAT16. So you might have found an edge case where NetDrive created a legal FAT16 volume, but DOS is confused by it and is interpreting it as FAT12. If you give me the exact command line I'll be able to confirm that. (And fix it ...)

Otherwise, it was nice to hear good news ... and I'm sure that NetDrive is going to perform far faster than the native drive.