Hi there! I'm just a layman here, but I think you can’t go wrong with an EtherLink III network card. It has drivers for about any OS.
About actual network software, I'm not certain.
I do use WfW 3.11 as a network software for DOS PCs.
For actual browsing, I do use a simple packet driver and Arachne web browser (and Minuet, just for fun)..
NewDeal Office also has some networking, but is more tricky to set up.

What I already realized is that Samba does only support NT1 support which means Windows XP works but 98 does not easily.

Samba does or did support the old SMB1, but it was named "CIFS" in config file - not SMB1!

Edit: Just double checked..
The following values seem to be available:
CORE, COREPLUS, LANMAN1, LANMAN2, NT1, SMB2_02, SMB2_10, SMB3_00, SMB3_02, SMB3_11, SMB2_FF
https://www.samba.org/samba/docs/current/man- … smb.conf.5.html

Jo22 wrote on 2025-11-26, 11:51:

Hi there! I'm just a layman here, but I think you can’t go wrong with an EtherLink III network card. It has drivers for about an […]
Show full quote

Hi there! I'm just a layman here, but I think you can’t go wrong with an EtherLink III network card. It has drivers for about any OS.
About actual network software, I'm not certain.
I do use WfW 3.11 as a network software for DOS PCs.
For actual browsing, I do use a simple packet driver and Arachne web browser (and Minuet, just for fun)..
NewDeal Office also has some networking, but is more tricky to set up.

What I already realized is that Samba does only support NT1 support which means Windows XP works but 98 does not easily.

Samba does or did support the old SMB1, but it was named "CIFS" in config file - not SMB1!

Edit: Just double checked..
The following values seem to be available:
CORE, COREPLUS, LANMAN1, LANMAN2, NT1, SMB2_02, SMB2_10, SMB3_00, SMB3_02, SMB3_11, SMB2_FF
https://www.samba.org/samba/docs/current/man- … smb.conf.5.html

I am using the NT1 value and I have the problem that Windows 98 SE is not able to access the share for some reason. It can see it but it does not work. But this maybe has to do with the fact that I am not setting a password for my username. The Windows 2000 server share has no problem with that at all.

Currently my plan was to simply take one of these CF to IDE adapters which come in the format of a ISA card so you can hotswap the CF card in the back of the computer when its powered off and transfer data on the card, power it on and have the files. Better than burning a CD.

If I may ask, how does WfW network shares work? Do you go to a share by \\IP\share or do you have to browse a network group and can you map network drives? I have never seen how networks are managed in Windows 3.1.

If you can see the shares it would seem like you already half way to having a working network so lets troubleshoot that first?

For best results have your workgroup name the same across all computers.
Logon to each PC with the same username, ideally with a password, but can simply be a single character

This is because Win3x/9x handles share logins different to NT versions of windows.
NT versions expect the username to be in domain\username format, which is not the default for the non NT versions.
By having your workgroup and username the same, this will still satisfy the NT format.

Blank passwords broke somewhere around XP or Vista, it can be made to work but simply hitting 1 at login is much easier fix.

WFW doesn't have a nice way of browsing the network, you'll need to map a drive to \\IP\Share
Or
Share C:\ of the Pentium and use a more modern PC to access that, eg on your Win2k server go to \\IP of Pro\C

SMB1 does work even in Windows 11, but starts getting tricky from Windows 7 up requiring changes to registry or enabling services. A Win2k server while not strictly necessary is definitely not a bad idea!

Hi,

There are a few DOS options, here's a few I've used:

If you need "shared" directories:

- You can extract the networking components from Wfw3.11 and they run fine under DOS.

Note that this uses and older version of SMB which is now considered hackable and is therefore disabled in modern OS. You can however enable it.

- Mbrutmans MTCP netdrive supports a fairly standard TCP network share.

- I've used one called NEOS.NET (which is still available) and worked well for DOS<>DOS but as far as I know it's not supported by anything newer.

Note that the above will all require network configuration and setup to allow them to co-exist on your network with other systems.

===

If all you need to do is transfer files:

- My own DDLINK is a file transfer program for DOS that works over Networt, Serial or Parallel ports.

It is a single 17k DOS program, needs no .DLLs etc, does not have to be "installed", and requires no setup. It also has a decent (IMHO) operating interactive interface which lets you easily pick/view/transfer files/directories on either system.

(for network you also need a "crnwar" packet driver - a small TSR to interface to the network, lots are available for many cards)

As it's a DOS program (16 bit .COM), it doesn't run directly on newer OSs, but it does run well in DosBox - this is how I move stuff to/from my DOS systems.

chinny22 wrote on 2025-11-27, 04:29:

If you can see the shares it would seem like you already half way to having a working network so lets troubleshoot that first? […]
Show full quote

If you can see the shares it would seem like you already half way to having a working network so lets troubleshoot that first?

For best results have your workgroup name the same across all computers.
Logon to each PC with the same username, ideally with a password, but can simply be a single character

This is because Win3x/9x handles share logins different to NT versions of windows.
NT versions expect the username to be in domain\username format, which is not the default for the non NT versions.
By having your workgroup and username the same, this will still satisfy the NT format.

Blank passwords broke somewhere around XP or Vista, it can be made to work but simply hitting 1 at login is much easier fix.

WFW doesn't have a nice way of browsing the network, you'll need to map a drive to \\IP\Share
Or
Share C:\ of the Pentium and use a more modern PC to access that, eg on your Win2k server go to \\IP of Pro\C

SMB1 does work even in Windows 11, but starts getting tricky from Windows 7 up requiring changes to registry or enabling services. A Win2k server while not strictly necessary is definitely not a bad idea!

Thanks a lot. I will try that definitely.

DaveDDS wrote on 2025-11-27, 05:04:

Hi, […]
Show full quote

Hi,

There are a few DOS options, here's a few I've used:

If you need "shared" directories:

- You can extract the networking components from Wfw3.11 and they run fine under DOS.

Note that this uses and older version of SMB which is now considered hackable and is therefore disabled in modern OS. You can however enable it.

- Mbrutmans MTCP netdrive supports a fairly standard TCP network share.

- I've used one called NEOS.NET (which is still available) and worked well for DOS<>DOS but as far as I know it's not supported by anything newer.

Note that the above will all require network configuration and setup to allow them to co-exist on your network with other systems.

===

If all you need to do is transfer files:

- My own DDLINK is a file transfer program for DOS that works over Networt, Serial or Parallel ports.

It is a single 17k DOS program, needs no .DLLs etc, does not have to be "installed", and requires no setup. It also has a decent (IMHO) operating interactive interface which lets you easily pick/view/transfer files/directories on either system.

(for network you also need a "crnwar" packet driver - a small TSR to interface to the network, lots are available for many cards)

As it's a DOS program (16 bit .COM), it doesn't run directly on newer OSs, but it does run well in DosBox - this is how I move stuff to/from my DOS systems.

Thanks a lot. I will try to get a network card and see how far I come on DOS.

mombarak wrote on 2025-11-27, 07:14:

Thanks a lot. I will try to get a network card and see how far I come on DOS.

FWIW - they might be considered very "old school" (kinda perfect for DOS) - if you can fine one, I've always had good luck with NE2000 network cards.

Very common, lots of things recognized them, lots of companies made "NE2000 compatible" cards, NE2000 packet driver is easy to get/reliable.

- even the edition of DosBox that I use implements access to the network via a "virtual" NE2000 card.

Samba works for me with min client version set to LANMAN1. I have a NAS share which all my retro machines running anything from MS Net Client 3.0 for DOS all the way up to XP can access. The only problem children are Windows 98 and ME - they require one extra special samba config option - add "strict sync = no" to the global config.

DaveDDS wrote on 2025-11-27, 05:04:

- Mbrutmans MTCP netdrive supports a fairly standard TCP network share.

This probably needs to be clarified ... mTCP looks more like ATA over Ethernet or iSCSI than a network share. It gives you a drive letter over the network, but that drive letter is not shared at the same time with another system. DOS sees it as a logical drive letters, and it behaves more like a Zip drive or a some other hard drive than a file share. (It presents itself as a block device, so DOS treats it the same way as other block devices.)

I interpret "network share" as file level file sharing over a network, like NFS or SMB.

mbbrutman wrote on 2025-11-28, 02:09:

This probably needs to be clarified ... mTCP ...

Thanks for adding detail, I was kinda hoping you might pop into this thread as it seem relevant.

I did play a bit with netdrive at one point, enough to know that it works and was reasonable at transferring files, but I've never used it as my "standard/usual" way to talk to DOS systems.
-- to be honest, I never liked dealing with TCP config and keeping track of what's on the network (a lot of stuff comes/goes on my lab net all the time) - yeah DHCP works, but a lot of the early DOS stuff didn't implement/use name servers (which can be more work to "get right" than end-to-end file transfer code), and needed to address by IP (which can change with DHCP).

I found TCP fairly painful in DOS - which is one of the main reasons I tend to use my own DDLINK for transfer stuff on/off DOS.
(DDLINK IDs systems by the unique MAC address built into the network card - It's effectively an end-to-end client/server, originally designed to transfer over parallel or serial direct connections. When run on a network the server listens for a broadcast from a prospective client (looking for a server) and thereafter it's all targeted packets, effectively a direct wire between the two ends)

In a similar vein I did write TFTP.COM at one time which could be run as a server or client using DHCP - the server told you it's assigned IP address when it started, which you could then use at the client to connect to it.
-- been years since I used it much, but I think there was a mode where you could give the server a name, and the client could use a broadcast to find it - but in the end, since I almost never need a routable protocol in DOS, DDLINK won (at least for me) because if it's simplicity, reliability and I was easily able to implement additional DOS file management functions (like find_first/find_next, get/set attrs & timestamp etc. which are not part of the TFTP protocol) which gives DDLINK a much nicer and more capable user interface.

mbbrutman wrote on 2025-11-28, 02:09:

... I interpret "network share" as file level file sharing over a network, like NFS or SMB.

Agreed, but most users just see a drive over the network and don't know/care how it is accomplished.

Which does bring an interesting question - (sorry I didn't use it enough to run into any of these issues, I just tested that it worked)

If you are doing sector access - that's kinda bypassing the DOS file system on the server.... How do you handle non-FAT drives on server? (or FAT32 on DOSs with only FAT16 support)

And ... how to you handle simultaneous access from local/network clients. DOS kinda assumes/needs drives not to be low-level accessed by anything other than it's own (internal) file system.

When you "share" a drive, do you lock it so that no-one else can access it? (this seems to be what INTERLNK does)

Do you implement some sort of sector locking method allowing multiple network users to access different files (and what about directories)
seems like you would have to do a lot of work to implement much of the file system and keep it synced to DOS?

Regarding filesystems and shared access:

On the client side, DOS just sees a mass storage device that uses 512 byte sectors. The filesystem to be used depends on the DOS version and the size of the image, but it's always going to be some variant of FAT because this is DOS. By implementing NetDrive as a block device driver I was able to get it to run on all versions of DOS that support installable device drivers without having to do things like make it aware of the DOS version number or play with non-documented DOS data structures. It just works.

On the server side it's just a file that is an image of the partition. The server side doesn't know or care whether it is FAT12, FAT16 or FAT16B - it's just 512 byte reads and writes into a file, and it really has no idea of what is in that file. If there were clients for Amigas or other machines the server would be fine. (I need to make the sector size variable, as right now it assumes 512 byte Sectors.)

There is no concurrent access allowed because that would be logically equivalent to two machines trying to write to the same (virtual) hard drive; the machines don't know about each other so that is just going to cause corruption. The only exception is read-only access; two machines can use and access a single image on the server if that image is marked as read-only.

The server side can also send new writes to a journal file. This is used to implement the "undo" feature - imagine you make a mistake and delete something you needed, or you made a configuration change or installed software and then you changed your mind. NetDrive allows you to go back in time and undo those changes, right from the DOS command line. I don't know of any other shared filesystem or network attached storage for DOS that can do that.

For public facing servers I implemented a party trick that allows multiple clients to connect to the same image and do writes. It also uses journal files, but in this case instead of having one journal per drive image there is a shared drive image and one journal per open client. The writes from a client go to its journal file, making those writes private to the client. This gives the clients the illusion of having a read-write drive letter. (The writes for that client disappear when the client disconnects, and the underlying image never gets modified.)

Regarding TCP, IP and UDP:

While I grew up on DOS 2.1, I was also exposed to Unix decades ago and that's why I started with the classic Unix programs first - FTP and Telnet in particular. NetDrive is actually only using UDP, not TCP, but the IP configuration that you speak of is required for both. Even with UDP and IP in the device driver the executable code in the driver is less than 3KB in size; most of the rest of the 6KB of used space is for an incoming packet buffer and three stacks, which are needed to make it reliable across a range of DOS versions. DHCP does make client configuration much easier and my servers rarely move so accessing my servers by name works well and I don't care what address the clients are temporarily using.

Using IP and UDP makes it routable, which is a feature I really like - any DOS machine in the world can access a server running on the Internet, which is a neat party trick. For a proof-of-concept I have an almost complete copy of the SIMTEL archive available on a public NetDrive server. Instead of FTPing to it, grabbing a file, and then unzipping it locally you can literally connect to it as a drive letter, find something you like, unzip it right on the server, run it from the server, and decide if you like it or not. If you don't like it you can delete it or just go try something else. It's not as fast to transfer data as FTP is, but for DOS users it's a more natural way to interact with a downloads section. While the proof of concept works, I've not publicized it because the speed is highly dependent on proximity to the server. I have code that fixes that, but it's stalled waiting on other things.

---

NetDrive is closer to a Zip drive that you move around than a shared filesystem. One machine accesses it at a time, and the only way to share is to move the drive to another system. But because it is software and it is using networking, that can happen in seconds and without rebooting. And you can add anywhere from 10MB to 2GB per drive letters, and up to 24 drive letters. And that virtual Zip drive can be in Alberta Canada while you sit in California. And it has an undo feature, and a few other tricks.

And regarding IP addressing - yes, client addresses can change with DHCP, but it shouldn't be too taxing to give the sever those clients use a fixed address.

But even if you don't want to it can be fairly simple. I use FTP for filesharing and run the server on the old systems, letting me use a nice GUI client on my modern desktop. How do I know what IP they have? Well, mtcp DHCP client tells you 😉

mbbrutman wrote on 2025-11-28, 05:20:

... On the server side it's just a file that is an image of the partition ...

Ahh.. that explains it.. (I didn't play with it much and don't recall what I had to do - very used to working with images because I run DOS in VMs a lot)

And you "lock" it so no other network client can access that image at the same time.
So the server side has to "mount" the image if you want to inject/extract files from it on the server?

So netdrive really is more about using network storage as a local drive and not so much about sharing data between systems.
- I often do a similar thing ... running DOS in a VM with a drive image mounter from another system on my network (this has the advantage that you can boot form it!) - on the "server" side it's just a file, protected by the usual OS file-level protections - if mounted read-only, multiple clients can read the drive, if read/write only one client can access it.

Any particular reason you didn't go with a file level approach using DOS's "network redirector" (Yeah, early DOS didn't have that, but I don't think it's unreasonable to require a more recent DOS for networking)

I've thought about using a network redirector approach to making a DDLINK server appear as a client drive. (Just hasn't been worth the effort given how little I use real DOS systems these days)

dionb wrote on 2025-11-28, 10:32:

And regarding IP addressing - yes, client addresses can change with DHCP, but it shouldn't be too taxing to give the sever those clients use a fixed address.

But even if you don't want to it can be fairly simple. I use FTP for filesharing and run the server on the old systems, letting me use a nice GUI client on my modern desktop. How do I know what IP they have? Well, mtcp DHCP client tells you 😉

Yes, if you have a dedicated server it's reasonable to set up a static IP, but a problem for temporary servers that you frequently move around (as it often the case in lab systems - yesterday I needed access to files on system A, today I need B and tomorrow I might need C)

At least with my DOS IP stuff I allowed them to accept an IP address as "[[[n1.[[n2.[.n3]]].n4 so you only had to enter as much of the IP that is different from your own - makes it much easier to enter IPs on your same subnet.

But .. .sometimes you don't have ready access to the system console to see what IP address it gets.
For example: I have an old "Aastra PBX" which has an internal CF card (looks like an IDE drive) It originally ran a custom XP but is enough PC like that I run DOS on it, and have it on a remotely controlled power plug. So... I can turn it on from upstairs, move files to it, then get them later, possibly from the basement (or anywhere else in the house).

And I did make some of my DOS IP stuff have a configurable name, and respond to an IP broadcast of a certain type if it contained that name - made it easy to find a system by name on the local net.

DaveDDS wrote on 2025-11-28, 13:12:

[...] Yes, if you have a dedicated server it's reasonable to set up a static IP, but a problem for temporary servers that you f […]
Show full quote

[...]
Yes, if you have a dedicated server it's reasonable to set up a static IP, but a problem for temporary servers that you frequently move around (as it often the case in lab systems - yesterday I needed access to files on system A, today I need B and tomorrow I might need C)

At least with my DOS IP stuff I allowed them to accept an IP address as "[[[n1.[[n2.[.n3]]].n4 so you only had to enter as much of the IP that is different from your own - makes it much easier to enter IPs on your same subnet.

But .. .sometimes you don't have ready access to the system console to see what IP address it gets.
For example: I have an old "Aastra PBX" which has an internal CF card (looks like an IDE drive) It originally ran a custom XP but is enough PC like that I run DOS on it, and have it on a remotely controlled power plug. So... I can turn it on from upstairs, move files to it, then get them later, possibly from the basement (or anywhere else in the house).

And I did make some of my DOS IP stuff have a configurable name, and respond to an IP broadcast of a certain type if it contained that name - made it easy to find a system by name on the local net.

Tbh that sounds rather self-inflicted chaos rather than anything inherent in the solution. Being able to store all relevant files in a single location is one of main benefits to networking stuff...

That said, if a device doesn't have a UI, check in your DHCP server. A lot of routers with built in server domain automated OUI lookup on the MAC addresses of clients, so it's generally fairly easy to spot the IP allocated to something exotic.

dionb wrote on 2025-11-28, 14:01:

Tbh that sounds rather self-inflicted chaos rather than anything inherent in the solution. Being able to store all relevant files in a single location is one of main benefits to networking stuff...

I do have a server ... but not worth all the overhead in interfacing to it from DOS systems. where I don't access "modern" things... Many of my DOS systems (like my ImageDisk system) specifically don't want "blobs of stuff" loaded in the background which can activate and disrupt real-time performance.

And... as I mentioned, It's a lab environment - more often that not "transient" files ... eg: I write some code to generate a certain test pattern of accesses and want to move it to another DOS machine to do the same test there. I make some notes on one machine (while testing something on another), then want to move it to that system for easy reference during further testing - there's lots of cases where I want to move something from one system, to another without going through a server.

That said, if a device doesn't have a UI, check in your DHCP server. A lot of routers with built in server domain automated OUI lookup on the MAC addresses of clients, so it's generally fairly easy to spot the IP allocated to something exotic.

Sure... go to and boot up a Winblows machine, launch an internet browser, go to the router admin page, hunt around for the login information, try and guess which is the DOS system I'm testing on...

Or.. just run DDLINK /S (server) on one, and DDLINK (client) on the other and move the file.

So many people have forgotten that networking has useful lower levels below IP (I know it's hard to understand, but networking and IP are not the same thing!)

DaveDDS wrote on 2025-11-28, 12:35:

Ahh.. that explains it.. (I didn't play with it much and don't recall what I had to do - very used to working with images becaus […]
Show full quote

mbbrutman wrote on 2025-11-28, 05:20:

... On the server side it's just a file that is an image of the partition ...

Ahh.. that explains it.. (I didn't play with it much and don't recall what I had to do - very used to working with images because I run DOS in VMs a lot)

And you "lock" it so no other network client can access that image at the same time.
So the server side has to "mount" the image if you want to inject/extract files from it on the server?

So netdrive really is more about using network storage as a local drive and not so much about sharing data between systems.
- I often do a similar thing ... running DOS in a VM with a drive image mounter from another system on my network (this has the advantage that you can boot form it!) - on the "server" side it's just a file, protected by the usual OS file-level protections - if mounted read-only, multiple clients can read the drive, if read/write only one client can access it.

Any particular reason you didn't go with a file level approach using DOS's "network redirector" (Yeah, early DOS didn't have that, but I don't think it's unreasonable to require a more recent DOS for networking)

I've thought about using a network redirector approach to making a DDLINK server appear as a client drive. (Just hasn't been worth the effort given how little I use real DOS systems these days)

Correct ... the image of the DOS filesystem can be mounted by things like Linux. There are tools for Windows but I have not tried them.

The block storage approach works on all versions of DOS, including DOS 2.1. My PCjrs use DOS 2.1 on occasion, so I wanted to include them - many of them don't have any sort of hard drive storage. In theory it works on the non-BIOS compatible MS-DOS versions too if you change the networking layer code and the timer interrupt code to whatever the system has available to it. The block storage approach also lets you do things like block level caching using the standard DOS BUFFERS command and disk caches, which is something that anything going through the network redirector can't do. And I'm generally using no more than 1 or two DOS systems at a time, so only being able to have one machine mount an image at a time is not an issue.

If you implement something using the network redirector you are going to need to be aware of DOS specific version differences. It has been done before; I just like the block based approach for its simplicity.

DaveDDS wrote on 2025-11-28, 16:50:

[...]
I do have a server ... but not worth all the overhead in interfacing to it from DOS systems. where I don't access "modern" things... Many of my DOS systems (like my ImageDisk system) specifically don't want "blobs of stuff" loaded in the background which can activate and disrupt real-time performance.

The great advantage to using packet drivers in DOS is that you don't need to load them unless specifically needed.

[...]

Sure... go to and boot up a Winblows machine, launch an internet browser,

What are you posting this with? Lynx for DOS? Chances are anyone reading here is already running a browser on some modern platform (Linux in my case fwiw)

go to the router admin page, hunt around for the login information, try and guess which is the DOS system I'm testing on...

Yes, it's entirely possible you also don't know your login and the vendor of the system you don't know the IP address of, but let's not assume OP is a complete moron.

Or.. just run DDLINK /S (server) on one, and DDLINK (client) on the other and move the file.

So many people have forgotten that networking has useful lower levels below IP (I know it's hard to understand, but networking and IP are not the same thing!)

My day job is spent almost entirely at layer 1 and 2.When I get home and want to mess around with old stuff, I don't want to have to worry about topologies or indeed specific technologies. I happen to like the convenience IP gives me there.

I'm not saying you shouldn't be using your networking option. You do whatever works for you. But please don't ridicule other perfectly workable options that work well for others.