mkarcher wrote on 2023-08-08, 20:22:

mateusz.viste wrote on 2023-08-08, 11:58:

Might also be interesting to look at how other projects solve this issue (DOSBOX, DOSEmu...) since they are obviously confronted with the same problem.

The project that put most likely most energy into this issue is samba.

Indeed. It works remarkably well with DOS/3.xx/95/98 clients. Just verified with the latest samba version shipped by debian.

If only MSCLIENT wasn't so damn buggy and leaky. I can get about 10 minutes of work in when writing code on a mounted share before having to reboot the machine due to leaked file handles. It's annoying as hell.
EtherDFS is a very welcome solution for this. I've yet to be brave enough to run WATCOM on a source directory on a share though 😀

It's a pity there are no good samba-equivalent netware server implementations for Linux as the DOS clients are so much better than the MS-NET one. But of the three implementations two are now unmaintained (Mars NWE, frommel) and development work seems to have stalled on the most recent portable one (nwserver). And interestingly like SMB the NetWare protocol can expose both short and long filenames to clients but none of the server implementations generate 8.3 filenames like Samba does. Mars NWE hides files with long names from DOS (but makes them visible to Windows 9x, NT and OS/2), while the other two I think just ignore anything with long filenames completely like EtherDFS does.

I assumed therefore the name 8.3 name mangling must be quite complex give only Samba attempted it but actually having a look at the Samba code it doesn't seem all that bad. Unfortunately being GPL it wouldn't be possible to borrow any of the code directly for EtherDFS without resulting in a GPL rather than MIT-licensed EtherDFS, but it might be worth a look for some inspiration/ideas: mangle.h, mangle.c, mangle_hash.c, mangle_hash2.c

I've tested your version Oerg866 but has issues reading files (both trying to copy or execute):

EDIT: I'm using FreeDOS 1.3, and discovered that COPY command works while XCOPY doesn't. I really want to execute without having to copy (but I guess that is too much 😅)

davidrg wrote on 2023-08-15, 02:33:

It's a pity there are no good samba-equivalent netware server implementations for Linux as the DOS clients are so much better than the MS-NET one.

....

I assumed therefore the name 8.3 name mangling must be quite complex give only Samba attempted it but actually having a look at the Samba code it doesn't seem all that bad.

Am I missing something here? I thought SAMBA was essentially SMB so it is accessible with the MS-Client or LAN-MAN Client. If the problem is the client (because it is leaky, requires too much memory, etc.) shouldn't the solution focus be on writing a NEW client for DOS based systems instead of creating new servers on other OSes? With all of these efforts, including EtherDFS, the authors are creating new servers. Is there a reason no one is just focusing on writing a better client?

Shadow Lord wrote on 2023-08-15, 16:01:

davidrg wrote on 2023-08-15, 02:33:

It's a pity there are no good samba-equivalent netware server implementations for Linux as the DOS clients are so much better than the MS-NET one.

....

I assumed therefore the name 8.3 name mangling must be quite complex give only Samba attempted it but actually having a look at the Samba code it doesn't seem all that bad.

Am I missing something here? I thought SAMBA was essentially SMB so it is accessible with the MS-Client or LAN-MAN Client. If the problem is the client (because it is leaky, requires too much memory, etc.) shouldn't the solution focus be on writing a NEW client for DOS based systems instead of creating new servers on other OSes? With all of these efforts, including EtherDFS, the authors are creating new servers. Is there a reason no one is just focusing on writing a better client?

I expect writing a high-quality client for a complex protocol such as SMB or NCP in a resource constrained environment like DOS is pretty hard as Microsoft has demonstrated and I assume part of why EtherDFS doesn't bother with running over TCP/IP. Novells clients are likely only as good as they are due to their huge market share at the time and the fact they supported DOS for so long (last client update was 1998 IIRC).

And if you're writing your own DOS client I don't know that implementing SMB over some other protocol actually provides any real benefits. Microsoft is actively discouraging use and deployment of antique SMB versions and is removing support from Windows. I doubt many Samba users are actually connecting DOS or Windows 3.x/9x/NT/2000/XP clients so that code is really just becoming an increasingly unnecessary maintenance burden and security risk at this point. I wouldn't be surprised to see Samba drop support in the future too - IIRC they've already removed some bits.

If you care about Windows (or OS/2) as well as DOS then I think picking up maintenance for one of the NCP servers for linux (marsnwe, frommel) or contributing to nwserver (modern, windows/linux, rust) makes more sense as the clients already exist and are already good. If you only care about DOS then something like EtherDFS is going to be vastly simpler and easier to maintain than writing either a better client or maintaining an old server for one of the more complex protocols like SMB, NCP or NFS.

I remember that NFS v1 for DOS used quite a bit less conventional memory than the MS client. All these clients were coded back in the mid 90s and optimization was hardly on their minds.
I'd personally like to see SFTP with modern ciphers (likely not for < pentium 😉 ) , NFS v4, at least SMB v2 coded with gcc-ia16 for <= 286 to start with. I happily fork over money for it.
If the thought that more memory is needed then as long as you replace older versions of Himem.sys you'll have way more than you'd ever need.
Likely mbbrutman would be the most knowledgeable about the feasability. Think he uses Open Watcom.

Personally I'm thankful for EtherDFS for its simplicity, just load a packet driver, point it at the server, and it just works. Other protocols would be, IMHO, unnecessarily complicated for the purpose of sharing files with a DOS client (and best discussed in a different thread).

jtchip wrote on 2023-08-15, 23:37:

Personally I'm thankful for EtherDFS for its simplicity, just load a packet driver, point it at the server, and it just works. Other protocols would be, IMHO, unnecessarily complicated for the purpose of sharing files with a DOS client .

Not really. I know people keep complaining about the MS Clients but in all honesty they are not that bad. With a properly tuned system you can get full drive mapping and a bunch of other goodies loaded in RAM and still have over 600KB free of conventional memory. YMMV.

jtchip wrote on 2023-08-15, 23:37:

Personally I'm thankful for EtherDFS for its simplicity, just load a packet driver, point it at the server, and it just works. Other protocols would be, IMHO, unnecessarily complicated for the purpose of sharing files with a DOS client (and best discussed in a different thread).

This. The idea is extremely good and simple. I think it only needs a bit more time of development and bugfixing.

davidrg wrote on 2023-08-15, 22:32:

And if you're writing your own DOS client I don't know that implementing SMB over some other protocol actually provides any real benefits. Microsoft is actively discouraging use and deployment of antique SMB versions and is removing support from Windows. I doubt many Samba users are actually connecting DOS or Windows 3.x/9x/NT/2000/XP clients so that code is really just becoming an increasingly unnecessary maintenance burden and security risk at this point. I wouldn't be surprised to see Samba drop support in the future too - IIRC they've already removed some bits.

Well if someone was to write a new DOS client I would think they make one that was compatible with SMBv2 and SMBv3 not just SMBv1. I mean if you are reinventing the wheel at least make it somewhat better? Or is there a reason you couldn't have a SMBv3 client under DOS (i.e. not enough processing power in your typical DOS machine for example...)

Shadow Lord wrote on 2023-08-16, 15:11:

davidrg wrote on 2023-08-15, 22:32:

And if you're writing your own DOS client I don't know that implementing SMB over some other protocol actually provides any real benefits. Microsoft is actively discouraging use and deployment of antique SMB versions and is removing support from Windows. I doubt many Samba users are actually connecting DOS or Windows 3.x/9x/NT/2000/XP clients so that code is really just becoming an increasingly unnecessary maintenance burden and security risk at this point. I wouldn't be surprised to see Samba drop support in the future too - IIRC they've already removed some bits.

Well if someone was to write a new DOS client I would think they make one that was compatible with SMBv2 and SMBv3 not just SMBv1. I mean if you are reinventing the wheel at least make it somewhat better? Or is there a reason you couldn't have a SMBv3 client under DOS (i.e. not enough processing power in your typical DOS machine for example...)

Getting a bit off topic for a thread on EtherDFS, but the biggest issue is TCP/IP which also affects NFS and pretty much any other modern protocol. Newer versions of SMB require TCP/IP which means your SMBv2 client needs a TCP/IP stack. Most free TCP/IP applications for DOS have a built-in TCP/IP stack that assumes its the only one running on the system - this is going to conflict with your TCP-needing TSR. To be able to run any TCP/IP applications at the same time as your SMBv2 client you'd need a TCP/IP stack that runs as a TSR itself - like the Novell or HP ones. It would make the most sense to pick the Novell one as it runs in protected mode, can provide TCP/IP to winsock applications under Windows and there is at least some DOS software that supports it, though much of it isn't free and its SDK license is problematic. But that still means things like mTCP can't co-exist with this SMBv2 client - users are limited to running DOS apps written specifically for your TCP/IP stack of choice plus windows apps if the chosen TCP/IP stack supports them.

So SMBv2 introduces a lot of compatibility issues with other software people may want to run, its probably going to use quite a lot of resources unless you go to the effort of shifting it to extended memory, and its going to be more complex to setup while not really doing anything EtherDFS can't (or couldn't fairly easily) do.

davidrg wrote on 2023-08-16, 20:48:

Most free TCP/IP applications for DOS have a built-in TCP/IP stack that assumes its the only one running on the system - this is going to conflict with your TCP-needing TSR. To be able to run any TCP/IP applications at the same time as your SMBv2 client you'd need a TCP/IP stack that runs as a TSR itself - like the Novell or HP ones. It would make the most sense to pick the Novell one as it runs in protected mode, can provide TCP/IP to winsock applications under Windows and there is at least some DOS software that supports it, though much of it isn't free and its SDK license is problematic. But that still means things like mTCP can't co-exist with this SMBv2 client - users are limited to running DOS apps written specifically for your TCP/IP stack of choice plus windows apps if the chosen TCP/IP stack supports them.

Hi,

Thanks for the multiple detailed answers and all the info. I will be bookmarking this thread for future reference! Yes, I see what you are saying. I would think a new client would need to be either based on Microsoft's TCP/IP stack or Mike's mTCP (size, still maintained). TBH while I can see the need for FTP, Whois, etc. my main use under DOS is file access off of my server and once in a long while printer sharing. As long as the client did drive mapping and did not break WfW I am happy to forgo all the other applications. My issue with EtherDFS is that it is very good at doing one thing but only that thing. If it could be made to map a share it would be much more useful IMHO. Heck even having a mechanism to step through a sequence of disks (for installing a multi-disk program) would be a huge improvement. A Linux only server also limits the audience somewhat. However, I understand the author's reasoning in keeping it simple and focused. So EtherDFS will stay as it is. Maybe Mike will eventually add a client to his mTCP suite! 😉

Yeah, for me the server is the show stopper. I also understand the reason why, but I don’t have the space for a (second) server besides the (Linux, but closed) NAS that I use. A Synology plug-in for EtherDFS (or NetWare) would be great, but I guess such a thing is infeasible.

You can "easily" use the EtherDFS server on a WSL instance inside Windows. The main issue remains the required FAT filesystem to avoid problems. Oerg866 solution works great but there are still some issues. For now I've solved all my problems by attaching an USB flash drive formated in FAT16 and using it as base folder 😅😂

Shadow Lord wrote on 2023-08-16, 22:11:

My issue with EtherDFS is that it is very good at doing one thing but only that thing.

I'll take that as a compliment. :-)

even having a mechanism to step through a sequence of disks (for installing a multi-disk program) would be a huge improvement.

EtherDFS is a filesystem-oriented thing, no disk. You might be confusing it with ethflop.

A Linux only server also limits the audience somewhat. However, I understand the author's reasoning in keeping it simple and focused.

Well, the major effort went into EtherDFS (ie. the client). The server part is basically a quick hack I did just so EtherDFS has something to talk to. It's Linux-only because I use Linux. It is not that I have something against Windows, or any other OS, it's just that I won't invest time into something that I won't ever use myself.
I'd be very glad if someone produced other-than-Linux implementations of ethersrv. It's an easy (albeit tedious) job without challenges, programming-wise. The only trick is that the OS must allow to send and receive raw Ethernet frames.

That being said, I was told (perhaps even in this thread) that ethersrv-linux works fine inside this windows "WSL2" thing, which effectively makes it windows-compatible.

mateusz.viste wrote on 2023-08-17, 23:01:

I'll take that as a compliment. :-) […]
Show full quote

Shadow Lord wrote on 2023-08-16, 22:11:

My issue with EtherDFS is that it is very good at doing one thing but only that thing.

I'll take that as a compliment. 😀

even having a mechanism to step through a sequence of disks (for installing a multi-disk program) would be a huge improvement.

EtherDFS is a filesystem-oriented thing, no disk. You might be confusing it with ethflop.

A Linux only server also limits the audience somewhat. However, I understand the author's reasoning in keeping it simple and focused.

Well, the major effort went into EtherDFS (ie. the client). The server part is basically a quick hack I did just so EtherDFS has something to talk to. It's Linux-only because I use Linux. It is not that I have something against Windows, or any other OS, it's just that I won't invest time into something that I won't ever use myself.
I'd be very glad if someone produced other-than-Linux implementations of ethersrv. It's an easy (albeit tedious) job without challenges, programming-wise. The only trick is that the OS must allow to send and receive raw Ethernet frames.

That being said, I was told (perhaps even in this thread) that ethersrv-linux works fine inside this windows "WSL2" thing, which effectively makes it windows-compatible.

Well I won't lie, an MSDOS version of the server would be absolutely amazing 😉

If TCP is too much hassle then how about TFTP? Afaik protocol is dead easy and ancient enough to have dos server (Novell WorkPlace TFTPD.EXE).

nvm too primitive, cant specify offset/range

EtherDFS is great. I am using it via RetroNAS.

Note that you CAN get it working over wifi if you have layer 2 bridging. My OpenWRT bridge didn't work (layer 3 I think), but I connected a spare Unifi AP in mesh mode to my network and connected the XT to that and it works fine with no configuration. There are probably other ways like using a VPN you can use for the same purpose.

I now have an 8088 that accesses my NAS over wifi.

Hmmm... Might be nice when combined with UniPCemu's dial-up PPP/SLIP packet server (providing dial-up PPP/SLIP server and a dial-up modem optionally (should also work with the WiFi232 dialing the server, which can also be done using a (modified for extra control lines using a second RS232 port, mentioned in a thread on this forum somewhere made by myself (with some help over IRC for ideas and verification) for the specs, basically a special RS232 splitter cable with a special termination plug (for some input lines) on the client side) RS232 cable and UniPCemu on the other RS232 port with UniPCemu setup to be acting as a dial-up modem)) and a MS-DOS PPP/SLIP(slip8250 from Arache for example) driver combined with this and the HTTP 1.0 proxy server that's somewhere on this.
That would be enough for easy network connection and PPP with IPv4 and IPX(though I've yet to find a PPP IPX driver for it other than what Windows 9x implements (tested and working with Doom95 IPX multiplayer)) and a full '95 style internet/dial-up experience!

Under MS-DOS, Arachne works great, and under Win95 both internet and IPX multiplayer work like a charm (as mentioned above)! Then adding this for modern Windows/linux machines for their network drive support... That's pretty much all you need!

Although I can't seem to find a PPP IPX driver for MS-DOS anywhere. Anyone knows of any (to use with etherppp and friends)?

superfury wrote on 2023-08-31, 10:40:

Although I can't seem to find a PPP IPX driver for MS-DOS anywhere. Anyone knows of any (to use with etherppp and friends)?

There are certainly IPX over PPP solutions for MS-DOS but the ones I'm aware of aren't free and I doubt they'd work with etherppp, etc. The ones I'm aware of are built to work with Novells 16bit NetWare DOS Client (IPXODI.COM, LSL.COM, etc) as that was the main reason you'd want to run IPX over PPP - to remotely connect to a NetWare server at work. Probably much easier to just run IPX over TCP/IP - this is what Novell ended up doing in the mid-90s.