jcarron2 wrote on 2022-04-30, 01:47:

I have a NE2000 type network card, which I believe I have working, as I can see the ne2000.com setup app detects and shows the network cards mac address properly at 300h/IRQ9.

I recently posted on here about a sound card which was detected happily by Windows but which I could get no audio out of, and it turned out it had jumpers missing. Network cards certainly had jumpers too, so I wouldn't assume the card is working perfectly just because of detection, for example it might require jumpers to select the connector, even if it only has one connector soldered.

Of course the hanging issue you saw suggests that there are probably other issues, but I wanted to point out that the card might be to blame too.

I'd be inclined to try out some more friendly and well-documented software with your card to verify that it works, something like Windows 95 which has pretty robust hardware detection and a TCP/IP stack without too many quirks. It's nice to know that at least part of the hardware and software chain is known to be working!

Are you familiar with using Wireshark on another machine to check what packets the DOS machine is sending?

Does anyone have any experience with this software ? Google has come up pretty much empty, except for a few notes/copies of using this software for Quake1 TCPIP in DOS.

I've merely heard of it before, don't have any experience with it. I did a bit of looking around myself, and while I don't want the headache of a rare TCP/IP stack myself, it sounds like it's impossible to find out there, so it seems you have something that a lot of people would find really interesting!

I Googled the term "ETHDEV interface vector" which you referred to below and found a manual, did you know about this? https://www.cs.cmu.edu/afs/cs/project/cmcl/li … ew/sftp/foo.txt

B. I can only use this software for a 3c503 card type?

That should not be the case, both the manual and http://cd.textfiles.com/itools/APPLIC/NCSA/PC … ISC/PKTDRVR.TXT say that the B&W stack supports packet drivers (although they could be referring to different versions), and the manual also says it supports ODI and NDIS drivers (that's basically covering every type of driver available for DOS I think!).

Under BWCUSTOM -> Hardware Customization -> I have IRQ set to 9, IO address set to 300h, however I am not sure what "Shared memory address" or "ETHDEV interface vector" should be set to.
For now I have set ETHDEV interface vector to 0x7c, as that is what seems to work with the ne2000 card, shared memory address I left at default D800h.

As I understand it, NE2000 cards don't use shared memory, so as per the manual you should set the "Shared memory address" to 0 I think.

The manual talks about the interface (interrupt) vectors. It sounds like when you set it to 0x7C, you should expect that interrupt, 0x7D and 0x7E to be used too since you're using NFS. I had a quick look at https://fd.lod.bz/rbil/zint/index.html to see what Ralf Brown's Interrupt List says about what kinds of things use those interrupt vectors but nothing jumped out at me as being a likely problem for you. Perhaps you could use some software like McAfee's ProView to figure out what (if anything) is using various interrupts before you load the stack.

But I think I see a problem here: if ETHDEV.PKT is a shim between the stack and the packet driver, then I don't think you should be telling the stack about the IRQ and IO address for your card, only the packet driver needs that information. And you're telling the stack to use interrupt 0x7C, but you're also telling the packet driver to use that interrupt as far as I can tell (c:\net2\ne2000\ne2000 0x7c), so I think the stack is configured to expect a B&W driver such as ETHDEV.PKT on that interrupt but it's finding a packet driver instead. I get the impression from the documentation that it should be able to set up your CONFIG.SYS and AUTOEXEC.BAT for you with a placeholder packet driver entry GENERIC.COM for you to change to point to your NE2000 driver, is that what you did to get this setup?

Any ideas? Or is there some more modern solution for older era machine that can do this ? I've looked into brutman mTCP, but it doesn't seem to offer NFS or SMB ....

Yeah, NFS would be very nice to have, but I don't think it was offered by many TCP/IP stacks for DOS, and probably not by any free ones.

Other options I'm aware of:
- Microsoft Network Client for MS-DOS version 3.0 which is mentioned a little in https://jeffpar.github.io/kbarchive/kb/094/Q94069/; I'm not sure how many third-party TCP/IP applications work with that stack, but it's part of the MS Client stack which supports SMB. Many modern online instructions for networking between DOS and Windows refer to that client since it uses NetBIOS over TCP/IP which is supported by Samba and more modern versions of Windows, whereas older MS DOS clients only supported NetBIOS Frames (NBF, also incorrectly known as NetBEUI) which Samba doesn't support.
- Waterloo TCP (WatTCP) and Watt-32: http://wiki.freedos.org/wiki/index.php/Networ … reeDOS_-_WATTCP has some information (that page also has links to some other stacks)
- KA9Q NOS and its descendants: http://wiki.freedos.org/wiki/index.php/Networ … _DOS_networking covers this a little and says it can act as an FTP server. It provides its own multitasking but I'm not sure if you can run arbitrary DOS programs under it or only use its (rich, I think) set of internal tools.

I've read about and/or played with all of those but only a little, mostly I just use SMB over NBF to an old Windows server running in a VM.

Novell LAN WorkPlace 5.0 for DOS/Windows includes a version of the Beame & Whiteside NFS client which I have used - you can see my notes/screenshots on it here

I found the main challenge to getting it to work is you need an Authentication Server running on your network somewhere. LAN WorkPlace included the source (and binaries) for the Beame & Whiteside authentication server and with a bit of effort I was able to compile it on Debian but I couldn't get it to actually work. I ended up installing NetBSD in a VM as NetBSD still includes a copy of the Sun PC-NFS Authentication Server which appears to be compatible with Beame & Whiteside NFS. With that done I was able to NFS Mount shares on my linux server.

That said I don't believe this NFS client is really practical to use for the same reason the Microsoft Network Client for DOS isn't worth using: they both use an unreasonable amount of conventional memory given available alternatives. The Microsoft clients memory usage is bordering on absurd - it really seems like they put no effort in. Additionally the Microsoft Network Client won't work with much in the near future - both Samba and Microsoft are dropping support for early versions of the SMB protocol.

If you want network drives I think the best solutions are:

• EtherDFS. Open source. DOS 5.0+ only (no windows support). Requires 8K of conventional RAM plus whatever your network card packet drive needs. 8086/8088+. Server software is Linux only.
• The NetWare client. You can use this with a real copy of NetWare in a VM (NetWare 3.x and 4.x is pretty cheap on ebay) or you can install Mars NWE on Linux (like Samba but it emulates a NetWare 3.x file server rather than a Windows file server).

My personal preference is the NetWare option. NetWare clients exist for DOS 3.0+, OS/2 1.2+, Windows 3.x/95/98 and Windows NT 3.5x/4.0/2000/XP/2003 and they're all very easy to setup. And on DOS 5.0+ with a 386 or better processor the 32bit DOS/Windows 3.x client with a 32bit ODI driver uses only 4KB of conventional memory if its unable to load high automatically. This leaves you around about 173KB more free conventional memory than the Microsoft client. And it also includes a pretty decent TCP/IP stack though available software is pretty limited - Novell sold TCP/IP applications separately (LAN WorkPlace - NFS client, FTP client/server, X server, terminal emulators and other misc utilities).

Yes, memory usage for the MS Client for DOS is bad, and EtherDFS and NetWare client are both much more friendly in terms of RAM! I imagine that all TCP/IP stacks for DOS are going to be memory hogs given that the protocol seems to be more complex.

davidrg wrote on 2022-04-30, 06:43:

[*] EtherDFS. Open source. DOS 5.0+ only (no windows support).

I assumed that if you mounted something from DOS, it would still be accessible from within Windows 3.x, is that not the case? Or are you just saying that there is no Windows user interface for mapping drives?

doshea wrote on 2022-04-30, 07:30:

Yes, memory usage for the MS Client for DOS is bad, and EtherDFS and NetWare client are both much more friendly in terms of RAM! I imagine that all TCP/IP stacks for DOS are going to be memory hogs given that the protocol seems to be more complex.

davidrg wrote on 2022-04-30, 06:43:

[*] EtherDFS. Open source. DOS 5.0+ only (no windows support).

I assumed that if you mounted something from DOS, it would still be accessible from within Windows 3.x, is that not the case? Or are you just saying that there is no Windows user interface for mapping drives?

The 32bit netware client for DOS includes a TCP/IP stack that lives in protected mode so doesn't impact conventional memory use at all. This is how the netware client uses so little too. Problem is not much DOS software supports it. There is an sdk but the license probably isn't GPL compatible. It does include winsock support for windows applications though (no Microsoft TCP/IP stack for windows required).

As for EtherDFS, AFAIK the drives work from windows 3.x, there is just no gui. I assume it doesn't work with Windows 9x and it won't work with OS/2 or windows NT/2000/XP.

Thanks for the ideas, you have some good points I should have checked before just assuming this was all working. I am familiar with wireshark, and will give that a quick test to make sure things are actually working as expected!

Testing with W95 is a good quick option too, at least that will confirm if things are working as expected or not!

It does sound like its an interesting piece of software, if it works, it has a lot of neat little utilities and network performance/monitoring applications that I've found that go with it (bwshow, bwmon) , there appear to even be source for building modules for other OS. Hopefully I can get this, or something else going!

I will need to spend sometime to go through the info you shared, as there is a quite a lot to digest! (thank you for sharing!).

Will post back in a few days once I've caught up!

Thanks,
Jonathan

doshea wrote on 2022-04-30, 06:13:

I recently posted on here about a sound card which was detected happily by Windows but which I could get no audio out of, and it […]
Show full quote

jcarron2 wrote on 2022-04-30, 01:47:

I have a NE2000 type network card, which I believe I have working, as I can see the ne2000.com setup app detects and shows the network cards mac address properly at 300h/IRQ9.

I recently posted on here about a sound card which was detected happily by Windows but which I could get no audio out of, and it turned out it had jumpers missing. Network cards certainly had jumpers too, so I wouldn't assume the card is working perfectly just because of detection, for example it might require jumpers to select the connector, even if it only has one connector soldered.

Of course the hanging issue you saw suggests that there are probably other issues, but I wanted to point out that the card might be to blame too.

I'd be inclined to try out some more friendly and well-documented software with your card to verify that it works, something like Windows 95 which has pretty robust hardware detection and a TCP/IP stack without too many quirks. It's nice to know that at least part of the hardware and software chain is known to be working!

Are you familiar with using Wireshark on another machine to check what packets the DOS machine is sending?

Does anyone have any experience with this software ? Google has come up pretty much empty, except for a few notes/copies of using this software for Quake1 TCPIP in DOS.

I've merely heard of it before, don't have any experience with it. I did a bit of looking around myself, and while I don't want the headache of a rare TCP/IP stack myself, it sounds like it's impossible to find out there, so it seems you have something that a lot of people would find really interesting!

I Googled the term "ETHDEV interface vector" which you referred to below and found a manual, did you know about this? https://www.cs.cmu.edu/afs/cs/project/cmcl/li … ew/sftp/foo.txt

B. I can only use this software for a 3c503 card type?

That should not be the case, both the manual and http://cd.textfiles.com/itools/APPLIC/NCSA/PC … ISC/PKTDRVR.TXT say that the B&W stack supports packet drivers (although they could be referring to different versions), and the manual also says it supports ODI and NDIS drivers (that's basically covering every type of driver available for DOS I think!).

Under BWCUSTOM -> Hardware Customization -> I have IRQ set to 9, IO address set to 300h, however I am not sure what "Shared memory address" or "ETHDEV interface vector" should be set to.
For now I have set ETHDEV interface vector to 0x7c, as that is what seems to work with the ne2000 card, shared memory address I left at default D800h.

As I understand it, NE2000 cards don't use shared memory, so as per the manual you should set the "Shared memory address" to 0 I think.

The manual talks about the interface (interrupt) vectors. It sounds like when you set it to 0x7C, you should expect that interrupt, 0x7D and 0x7E to be used too since you're using NFS. I had a quick look at https://fd.lod.bz/rbil/zint/index.html to see what Ralf Brown's Interrupt List says about what kinds of things use those interrupt vectors but nothing jumped out at me as being a likely problem for you. Perhaps you could use some software like McAfee's ProView to figure out what (if anything) is using various interrupts before you load the stack.

But I think I see a problem here: if ETHDEV.PKT is a shim between the stack and the packet driver, then I don't think you should be telling the stack about the IRQ and IO address for your card, only the packet driver needs that information. And you're telling the stack to use interrupt 0x7C, but you're also telling the packet driver to use that interrupt as far as I can tell (c:\net2\ne2000\ne2000 0x7c), so I think the stack is configured to expect a B&W driver such as ETHDEV.PKT on that interrupt but it's finding a packet driver instead. I get the impression from the documentation that it should be able to set up your CONFIG.SYS and AUTOEXEC.BAT for you with a placeholder packet driver entry GENERIC.COM for you to change to point to your NE2000 driver, is that what you did to get this setup?

Any ideas? Or is there some more modern solution for older era machine that can do this ? I've looked into brutman mTCP, but it doesn't seem to offer NFS or SMB ....

Yeah, NFS would be very nice to have, but I don't think it was offered by many TCP/IP stacks for DOS, and probably not by any free ones.

Other options I'm aware of:
- Microsoft Network Client for MS-DOS version 3.0 which is mentioned a little in https://jeffpar.github.io/kbarchive/kb/094/Q94069/; I'm not sure how many third-party TCP/IP applications work with that stack, but it's part of the MS Client stack which supports SMB. Many modern online instructions for networking between DOS and Windows refer to that client since it uses NetBIOS over TCP/IP which is supported by Samba and more modern versions of Windows, whereas older MS DOS clients only supported NetBIOS Frames (NBF, also incorrectly known as NetBEUI) which Samba doesn't support.
- Waterloo TCP (WatTCP) and Watt-32: http://wiki.freedos.org/wiki/index.php/Networ … reeDOS_-_WATTCP has some information (that page also has links to some other stacks)
- KA9Q NOS and its descendants: http://wiki.freedos.org/wiki/index.php/Networ … _DOS_networking covers this a little and says it can act as an FTP server. It provides its own multitasking but I'm not sure if you can run arbitrary DOS programs under it or only use its (rich, I think) set of internal tools.

I've read about and/or played with all of those but only a little, mostly I just use SMB over NBF to an old Windows server running in a VM.

Thanks for the info here, the link on your page has some very helpful information here, as well as your experience in getting it going!

I may look into the NetBSD implementation you mentioned for the authentication server if I can get anywhere with this... Do you recall which version of NetBSD you used at the time ?

Understandably the high conventional memory use would turn most people away, but it is inconsequential for my use - I would simply setup 2 different boot options in config.sys/autoexec - one with network support, and the other without. MSDOS reboot so quickly, I can switch between the two pretty easy, if I'm careful maybe able to use QEMM to load the sys files into high memory, and just start up the TSR's from the autoexec upon demand...?

I have not heard of EtherDFS - I have much reading and catching up to do here ! As Doshea asked, if the mapping is complete before windows is loaded, I wonder if the drive letter would be available within Win31 ?

I have an old copy of Novell Netware something here, but I have little exposure to it, the MARS option as you mentioned maybe a far better idea for me, especially given the fact you point out the Netware client is very mature for MSDOS/Win31 stuff. Will need to get a bit more familiar with those to be able to follow along..! Any good resources on the Novell side to get familiar with all the applications they offered separately ? NFS client , and X server sound kind of interesting!

At either rate, I was really hoping to just use this software as a small portable IP stack, but the authentication server aspect is sort of a bummer - Do you recall is that needed for just NFS support, or even TCP/IP support its required?

If you chose no authentication (aka security sin - but not as if it matters on this old stuff ), would it work without that I wonder ?

Thanks for the help!
Jonathan

davidrg wrote on 2022-04-30, 06:43:

Novell LAN WorkPlace 5.0 for DOS/Windows includes a version of the Beame & Whiteside NFS client which I have used - you can see […]
Show full quote

Novell LAN WorkPlace 5.0 for DOS/Windows includes a version of the Beame & Whiteside NFS client which I have used - you can see my notes/screenshots on it here

I found the main challenge to getting it to work is you need an Authentication Server running on your network somewhere. LAN WorkPlace included the source (and binaries) for the Beame & Whiteside authentication server and with a bit of effort I was able to compile it on Debian but I couldn't get it to actually work. I ended up installing NetBSD in a VM as NetBSD still includes a copy of the Sun PC-NFS Authentication Server which appears to be compatible with Beame & Whiteside NFS. With that done I was able to NFS Mount shares on my linux server.

That said I don't believe this NFS client is really practical to use for the same reason the Microsoft Network Client for DOS isn't worth using: they both use an unreasonable amount of conventional memory given available alternatives. The Microsoft clients memory usage is bordering on absurd - it really seems like they put no effort in. Additionally the Microsoft Network Client won't work with much in the near future - both Samba and Microsoft are dropping support for early versions of the SMB protocol.

If you want network drives I think the best solutions are:

• EtherDFS. Open source. DOS 5.0+ only (no windows support). Requires 8K of conventional RAM plus whatever your network card packet drive needs. 8086/8088+. Server software is Linux only.
• The NetWare client. You can use this with a real copy of NetWare in a VM (NetWare 3.x and 4.x is pretty cheap on ebay) or you can install Mars NWE on Linux (like Samba but it emulates a NetWare 3.x file server rather than a Windows file server).

My personal preference is the NetWare option. NetWare clients exist for DOS 3.0+, OS/2 1.2+, Windows 3.x/95/98 and Windows NT 3.5x/4.0/2000/XP/2003 and they're all very easy to setup. And on DOS 5.0+ with a 386 or better processor the 32bit DOS/Windows 3.x client with a 32bit ODI driver uses only 4KB of conventional memory if its unable to load high automatically. This leaves you around about 173KB more free conventional memory than the Microsoft client. And it also includes a pretty decent TCP/IP stack though available software is pretty limited - Novell sold TCP/IP applications separately (LAN WorkPlace - NFS client, FTP client/server, X server, terminal emulators and other misc utilities).

jcarron2 wrote on 2022-04-30, 18:10:

Thanks for the info here, the link on your page has some very helpful information here, as well as your experience in getting it […]
Show full quote

Thanks for the info here, the link on your page has some very helpful information here, as well as your experience in getting it going!

I may look into the NetBSD implementation you mentioned for the authentication server if I can get anywhere with this... Do you recall which version of NetBSD you used at the time ?

Understandably the high conventional memory use would turn most people away, but it is inconsequential for my use - I would simply setup 2 different boot options in config.sys/autoexec - one with network support, and the other without. MSDOS reboot so quickly, I can switch between the two pretty easy, if I'm careful maybe able to use QEMM to load the sys files into high memory, and just start up the TSR's from the autoexec upon demand...?

I have not heard of EtherDFS - I have much reading and catching up to do here ! As Doshea asked, if the mapping is complete before windows is loaded, I wonder if the drive letter would be available within Win31 ?

I have an old copy of Novell Netware something here, but I have little exposure to it, the MARS option as you mentioned maybe a far better idea for me, especially given the fact you point out the Netware client is very mature for MSDOS/Win31 stuff. Will need to get a bit more familiar with those to be able to follow along..! Any good resources on the Novell side to get familiar with all the applications they offered separately ? NFS client , and X server sound kind of interesting!

At either rate, I was really hoping to just use this software as a small portable IP stack, but the authentication server aspect is sort of a bummer - Do you recall is that needed for just NFS support, or even TCP/IP support its required?

If you chose no authentication (aka security sin - but not as if it matters on this old stuff ), would it work without that I wonder ?

Thanks for the help!
Jonathan

The authentication server is only required for the NFS client - it just seems to be something PC NFS clients of the era do. The other TCP/IP apps should work fine without it. I couldn't find any way to make it work without the authentication server - I tried turning off all security on the server but the NFS client still complained. I just grabbed the latest version of NetBSD - I was quite surprised they were still building and distributing this ancient app from the early 90s that, AFAIK, is only useful for DOS-era NFS clients. But its there! I don't think you need to install any packages to get it - it should be available as /usr/bin/rpc.pcnfsd. You may need to setup an NFS export on the machine running the pcnfsd for it to work correctly.

As for memory use, its pretty nice to just always have networking there and not have to reboot whenever something is needed. It also means you don't necessarily have to even install software locally - my 486 is running a bit low on space so some stuff is actually running off of the network and games that required data off of a CD get the data from the LAN now. That said I think playing around with the B&W TCP/IP stack is certainly worthwhile though if only to see what this probably quite rare collection of software like - if you get it going it would be neat if you put some screenshots and other details of it up somewhere!

I've not yet found a need to try EtherDFS myself but I'm pretty sure any drive letters it sets up are available from Windows 3.x. Given Windows 9x runs on top of DOS I wouldn't be too surprised if it was possible to make it work there too (you can certainly use the DOS real-mode NetWare client with Windows 95) but there are better options. BW NFS works the same way - the NFS client lives entirely in real mode and the GUI stuff just seems to be a friendly UI - any drives you map under windows are still there when you exit to DOS.

As far as NetWare goes, I can probably provide all the information you could want as I went through setting everything up from scratch quite recently and took an absurd number of screenshots and notes along the way. I'm currently running 3.12 and 4.11 under Linux KVM plus Mars NWE on a raspberry Pi for all my retro-networking needs:

• Installing NetWare 3.12 (3.11 should be pretty similar, 3.2 is an upgrade to 3.12 - install process looks like this)
• Installing NetWare 4.11 - this is by far the easiest thanks to hardware autodetection and automatic partitioning (if you let it)
• Installing the DOS/Windows 3.x client: 32bit, latest version (386+, DOS5+) or the 16bit latest version (286+, DOS 3.1+) - the windows integration looks much the same as the 32bit client, just no graphical login. The older NETX client that supports 8088/8086 CPUs and DOS 3.0 doesn't have an installer. You can also still use packet-driver based DOS utilities (like mTCP) as well as Windows Networking alongside the NetWare client but it does increase conventional memory use slightly due to the required shim TSRs.
• Installing the Windows 9x client on 98 SE, the NT client on NT 4.0 and the OS/2 client on the Non-connect version of OS/2 Warp 3
• If you have any classic Macintoshes, NetWare 3.12 has an AppleShare server (5 user limit), NetWare 4.11 changes the AppleShare user limit to be that of the server and also adds a proper full blown Mac client that uses MacIPX to talk NCP to the server (screenshots) - Mars NWE doesn't support Macs at all but there are AppleShare server implementations for linux.
• Mars NWE is abandoned by its original author but still works on modern Linux OK. I pulled the final release into github and added some notes on what I had to do to get it up and running. Its pretty easy: https://github.com/davidrg/mars_nwe/ - you can use this (shareware) graphical admin tool (Windows 3.x/9x/NT) to manage Mars NWE as well as NetWare 3.x.
• More details on LAN WorkPlace 5 and screenshots of all the Windows TCP/IP utilities it includes here. There are DOS versions of most of the utilities too (no X server for DOS) but I didn't bother exploring them in much detail. The X server screenshots are here.
• Network booting: DOS, Windows 95 and OS/2 - requires a network card with a Boot ROM.

RetroNAS is also worth a look - no Mars NWE support yet but it does bundle up EtherDFS, a DOS/Windows 3.x compatible Samba configuration, an AppleShare server and other useful things. If you want a small portable collection of TCP/IP apps for DOS there is mTCP. No NFS support though - I'm not aware of any free NFS implementations for DOS.

Thanks so much for all the help and guidance, the wealth of information is more than I could have ever hoped to find!

The info will take me a bit to digest! (information overload of the peanut gallery here).

I will keep you all posted with the progress on this, hopefully I can get it working and share how to do that.

For what its worth, I did manage to find a similar copy online posted (missing some modules though) with this google query 'intext:"index of" bwtcp' - the 2nd link to soulsphere 'qkeppp20.zip' .

Maybe there are more to find, will have a deeper look as I keep digging on this.

Jonathan

jcarron2 wrote on 2022-04-30, 18:10:

Understandably the high conventional memory use would turn most people away, but it is inconsequential for my use - I would simply setup 2 different boot options in config.sys/autoexec - one with network support, and the other without. MSDOS reboot so quickly, I can switch between the two pretty easy, if I'm careful maybe able to use QEMM to load the sys files into high memory, and just start up the TSR's from the autoexec upon demand...?

There are tools for loading device drivers on demand too, see this thread: How to load DOS device drivers from the command line? They might not work with all drivers, and might not support unloading even if they do support loading, but if you like this particular stack they might be worth trying.

Hey

thanks! I didn't realize those could be loaded without a reboot!

That should help out trial and error approach im giving a go now...

Jonathan

doshea wrote on 2022-05-01, 04:32:

jcarron2 wrote on 2022-04-30, 18:10:

Understandably the high conventional memory use would turn most people away, but it is inconsequential for my use - I would simply setup 2 different boot options in config.sys/autoexec - one with network support, and the other without. MSDOS reboot so quickly, I can switch between the two pretty easy, if I'm careful maybe able to use QEMM to load the sys files into high memory, and just start up the TSR's from the autoexec upon demand...?

There are tools for loading device drivers on demand too, see this thread: How to load DOS device drivers from the command line? They might not work with all drivers, and might not support unloading even if they do support loading, but if you like this particular stack they might be worth trying.

jcarron2 wrote on 2022-04-30, 01:47:

[ ... ] I've been trying to get MS dos 6.x working with network support, I have an old disk, which has a copy of Beame & Whitesi […]
Show full quote

[ ... ]
I've been trying to get MS dos 6.x working with network support, I have an old disk, which has a copy of Beame & Whiteside TCP stack (v 2.8, and v3.1), however I cannot get things to work at all.

I have a NE2000 type network card, which I believe I have working, as I can see the ne2000.com setup app detects and shows the network cards mac address properly at 300h/IRQ9.
[ ... ]

I just happened across this post, and wondered if you are still interested in doing this.

If you are, I wouldn't mind giving you some pointers, although it has been about 30 years since I did tech support for that product ...

-fred