bjbdragon wrote on 2021-03-27, 04:35:

In desperation, I tried Microsoft Client but was drowned in terminology, commands, and configuration files I only vaguely understood. After days of fiddling I got nowhere.

Finally, I decide it's more work to dig through the far reaches of the Internet than to hack something up on my own.

I would have thought there would be modern instructions (quite possibly somewhere on this forum) for using Microsoft Client since it seems like a reasonably popular solution, despite the memory usage.

It took a few days as I really have never done DOS code, let alone resident stuff.

Well that's quite a learning experience then!

Apologies, I don't have any answers to your important questions here, I was instead thinking of some alternatives which I thought I'd share in case you or anyone else is interested in trying them.

My first thought was that having to construct IP headers you don't really want just to get the packets transported over a serial port seems a bit wasteful in terms of code size and effort when you could "just" use the serial port directly. However, I realised that EtherDFS would almost certainly want framing - it's surely not stream-based - so it would require some more complicated work. I imagine it might save a little RAM though, due to not needing a packet driver.

Another thought was: what about historical solutions for sharing over a serial port? For example MS-DOS 6 came with InterLink which did this kind of thing over a serial or parallel port, and apparently (based on a Google search) the client only required 8KB of RAM. Of course the server also runs on DOS, but I would imagine that you could run that in a virtual machine of some sort where it's sharing drives you've previously connected to via EtherDFS, Microsoft Client, etc. At least I hope that InterLink doesn't have any restrictions on re-exporting network drives; I don't imagine it would since I know that for some similar applications like pcAnywhere, serving as a bridge to your LAN was a feature. Of course requiring a bridging VM isn't as convenient as just having a server application, but on the other hand it might be possible to solve your problem without writing any code. I have had issues with emulators communicating with physical machines over serial where the emulator was running too fast though, so it might not be as easy to get working as one might hope.

Good luck with your project!

doshea wrote on 2021-03-28, 08:46:

I would have thought there would be modern instructions (quite possibly somewhere on this forum) for using Microsoft Client since it seems like a reasonably popular solution, despite the memory usage.

There seem to be modern instructions on setting it up... just not the serial line method with all the layers between packet driver, odi, ndis.

doshea wrote on 2021-03-28, 08:46:

My first thought was that having to construct IP headers you don't really want just to get the packets transported over a serial port seems a bit wasteful in terms of code size and effort when you could "just" use the serial port directly. However, I realised that EtherDFS would almost certainly want framing - it's surely not stream-based - so it would require some more complicated work. I imagine it might save a little RAM though, due to not needing a packet driver.

Yeah EtherDFS is based on Ethernet Packet driver framework so, yes it expects framing. And there are existing historical solutions that are very lightweight for doing a direct serial link. The first I played around with was simply a Linux terminal and the sx/b/z ccommands. (never did get zmodem to work).

doshea wrote on 2021-03-28, 08:46:

Another thought was: what about historical solutions for sharing over a serial port? For example MS-DOS 6 came with InterLink which did this kind of thing over a serial or parallel port, and apparently (based on a Google search) the client only required 8KB of RAM. Of course the server also runs on DOS, but I would imagine that you could run that in a virtual machine of some sort where it's sharing drives you've previously connected to via EtherDFS, Microsoft Client, etc. At least I hope that InterLink doesn't have any restrictions on re-exporting network drives; I don't imagine it would since I know that for some similar applications like pcAnywhere, serving as a bridge to your LAN was a feature. Of course requiring a bridging VM isn't as convenient as just having a server application, but on the other hand it might be possible to solve your problem without writing any code. I have had issues with emulators communicating with physical machines over serial where the emulator was running too fast though, so it might not be as easy to get working as one might hope.

I will certainly be trying out something like InterLink, or dosrifs2 at some point. I seem to recall DosBox-X not having the ARM dynarec setup properly... and definitely not going to want to run under full emulation.

As of now, I've got the 386 PC calling the modern computer over a US Robotics 56k external modem... it's not just hanging right off the COM2 port anymore. And the bottleneck is the COM port (several diagnostics software programs claim UART 16450 ... 1byte buffer - no wonder things are terrible!) but the modem has greatly increased the latency. And wow, EtherDFS seems to really not like it causing half of the files in a directory to not show up. Probably because 280ms ping times on raw Ethernet is pretty improbable. Of course, in a real IP network it's got to be able to handle some lag. Still working on trying to make it more robust.

I'm going to have to package up my changes so I can at least put them out there for anyone interested... it's by no means complete, in fact very broken in some ways but at least serves as a proof of concept for networking. However - I did discover that I'd need even more TSRs (pktmux, pktdrv) to even share the packet driver, so it's starting to look a little more bloated to me.

Thanks!

bjbdragon wrote on 2021-04-02, 05:06:

There seem to be modern instructions on setting it up... just not the serial line method with all the layers between packet driver, odi, ndis.

Oops, when I suggested that there were instructions, I forgot the context of it being over serial!

Yeah EtherDFS is based on Ethernet Packet driver framework so, yes it expects framing. And there are existing historical solutions that are very lightweight for doing a direct serial link. The first I played around with was simply a Linux terminal and the sx/b/z ccommands. (never did get zmodem to work).

Oh yeah, if mounting the remote filesystem isn't a requirement, there are a lot more options available. I've had trouble with zmodem when using emulation too, I think it might have been due to one or both of (a) the emulated system running too fast, and (b) when I had emulated systems talking to each other via a local TTY pair on Linux, I don't think there was any emulation of the serial control lines (e.g. hardware flow control). If I recall correctly, the older protocols send a single packet and then wait for a reply, but zmodem will send multiple unacknowledged packets so is more likely to exhaust buffers, etc. Not having a 16550 UART is probably not going to help either!

Another option is using Microsoft's RAS (Remote Access Service) which was their solution for NetBIOS (and some other protocols, but not TCP/IP, I think) over a modem. This is probably also hard to find information for online, but maybe old TechNet CDs contain articles about setting it up.

dosrifs2

Nice, I hadn't heard of that one before, thanks!