The DOS SMB1.0 stack is period software, but that, plus the nic driver, will consume every scrap of your upper memory and then some.

You are better off using modern stuff, like mbrutman's mtcp.

https://www.brutman.com/mTCP/

That gets the job done, without breaking the bank.

It only needs a packet driver, which are *substantially* smaller than ndis2 drivers. Packet drivers should be on the same dos driver diskette as an ndis2 driver, usually for use with novell's odi model. You dont need anything more than this packet driver to use netdrive.

But, if you insist on the path of pain and perdition...

You will need:

DOS NDIS2 driver diskette for your NIC.
Microsoft Lan Manager for DOS disk set.
greater than 128kb of free upper memory.
enable SMB1.0 features on your windows box / network share
thick skin

(I'd provide links, but the ndis2 drivers are nic specific, and the lan manager for dos set is still under copyright, and maybe not proper to link to here.)

You can look into Brutman's netdrive as well. Works great on my PCjr, 8086, 386, etc. systems. Requires mTCP as well to work

Here's one of Brutman's YouTube videos about it
https://www.youtube.com/watch?v=86QSxJO8otI&t=3s

Period correct would be the "Microsoft Network Client 3.0" which can be found as stand alone package or on NT Sever CD in the \CLIENTS\MSCLIENT folder
https://youtu.be/_eOImLHa-Tw?si=-nLHa0uawYPNwaBN

or
Microsoft LAN Manager 2.2c
https://youtu.be/oqMzF41dyvk?si=NQABF5xphYb-jMhD

or my personal choice Windows for Workgroups

all 3 do use a lot of memory, however no need to load the drivers if your not going to use the network, I have a "net.bat" file I run if and when I need the network which is less then half the time.
SMB is slow but convenient as it's built into windows. XP plays nice with these old clients as long as you set up your network in a way XP can understand. That is make sure everyone is in the same workgroup and makes life much easier if you use the same username/password across all computers. (Password is recommended, even if its only 1 character as sometimes windows gets confused with a blank password)

FTP is another period correct option but not built into windows, you would need to run a ftp server such as mtcp above. FTP is quicker and easier to get working with different generations of OS's but personally don't find it as convenient as SMB.

If you want to transfer files over the network, the absolutely easiest and IMO convenient thing is to use FTP server on your vintage systems. Then just connect to this server with a client from your modern system. It is simple and you don’t need to make any changes to your modern systems or resources. And you get to use modern FTP clients with drag and drop UIs and whatnot.

I have this kind of setup for every of my DOS systems and most othe win9x boxes. I can’t live without DOS networking and floppy hassle is something that I definitely don’t miss from the past.

I'd agree that MTCP + either the ftp client or the ftpsrv server is the better way to do this.

The DOS packet drivers for most NIC's are tiny, most can be loaded/unloaded on demand, and the MTCP suite works brilliantly.

The easiest route is probably to run the ftpsrv server on the DOS pc, and then a modern FTP client on your modern PC (e.g. filezilla or something similar that does drag and drop), that way you don't need to keep an FTP server running constantly. You can of course do it the other way and use the MTCP ftp client, even though I'm a command line junkie I still think it's easier to initiate transfers for more than a handful of files from a desktop interface.

The only disadvantage is that you don't get a network drive to launch things from... but with all of the cheap options for mass storage on retro computers now, is that really the best option? I'd argue possibly not...

megatron-uk wrote on 2025-09-23, 09:27:

The DOS packet drivers for most NIC's are tiny, most can be loaded/unloaded on demand, and the MTCP suite works brilliantly.

Unless you happen to be the poor soul that happens to own a 3c905C. The new revisions of the 3c90x packet driver are broken beyond what I was willing to repair, causing random issues like lock-ups when loading ethdosfs. The old revisions of the 3c90x packet driver do not support the "C" revision (which technically is a 3c920 lan-on-mainboard chip adapted to use on adapter cards instead of a successor of the 3c905b).

If ypu don't need a "shared folder", just to transfer files and want small:

DDLINK: Easily move files between/To/From DOS systems

About 17k .COM - no other supporting files (except packet driver for network),
uses no EMS/XMS etc. Does not stay in memory.

Can transfer over network, parallel or serial connection.

megatron-uk wrote on 2025-09-23, 09:27:

I'd agree that MTCP + either the ftp client or the ftpsrv server is the better way to do this. […]
Show full quote

I'd agree that MTCP + either the ftp client or the ftpsrv server is the better way to do this.

The DOS packet drivers for most NIC's are tiny, most can be loaded/unloaded on demand, and the MTCP suite works brilliantly.

The easiest route is probably to run the ftpsrv server on the DOS pc, and then a modern FTP client on your modern PC (e.g. filezilla or something similar that does drag and drop), that way you don't need to keep an FTP server running constantly. You can of course do it the other way and use the MTCP ftp client, even though I'm a command line junkie I still think it's easier to initiate transfers for more than a handful of files from a desktop interface.

The only disadvantage is that you don't get a network drive to launch things from... but with all of the cheap options for mass storage on retro computers now, is that really the best option? I'd argue possibly not...

This, i want to have a network drive, i'm not interested in a FTP solution. For easy share file i can use compact flash, floppy disk, Zip 250 ecc.... just to experiment to use a network drive for fun, for copy file and use it with ghost

Do you need to create a ghost image? What does that get you over and above an archive of your drive created by recursively copying the entire directory structure using FTP?

You could even do incremental "images" using FTP. It's not like Windows where you want to capture registry state, installed drivers, etc. Reinstalling a DOS system is as simple as formatting a drive (of any size), sys-ing it and then copying your folder structure back.

You can certainly do what you are asking, but as others have already said; SMB in DOS is clunky and very memory hungry - if you go that route I'd probably consider adding a dedicated config.sys/autoexec.bat menu entry solely for that purpose.

megatron-uk wrote on 2025-09-23, 09:27:

The only disadvantage is that you don't get a network drive to launch things from... but with all of the cheap options for mass storage on retro computers now, is that really the best option? I'd argue possibly not...

I’d argue that having DOS systems networked really takes away much of the mass storage issues too.

Majority of my DOS systems still use HDDs, either what they originally shipped with or something that can be used without overlay software or XTIDE bootrom.

I have zero reasons to try to maximize HDD capacity, because file transfers are so effortless with FTP. If I don’t need or use something, I just delete it and possibly backup setting files or save games for future use. And I can easily again transfer the program later on to the HDD if I want to. There is just no need to hoard stuff on the HDDs.

Now, before I started to do this, I often kept software on HDD as long as possible, because re-installing it is a hassle itself. Or at the minimum I wanted to keep install floppies at hand, which meant bunch of disks needed to be stored. CD-RWs can be handy, until you have a system without optical drice or drive doesn’t support those.

Networking and FTP is just a godsend and thankfully 10baseT ISA cards can be easily found and aren’t even expensive.

I used to make DOS boot disks to load windows NT from an SMB file share for a large corporation once upon a time using the LAN manager client. I did it on a pretty regular basis, a couple times a year in the late '90's, pretty much every time someone started ordering from a PC line with an incompatible NIC. And every time I had to start editing the protocol.ini. It felt like blind trial and error. It was much more challenging than the NetWare boot disks I did in the mid 90's. And we were using some old garbage NICs back then.

The DOS lan manager stack requires at least three fat device drivers in the config.sys. Getting the names and hardware config and the static IP right in the protocol.ini file was tricky. And I remember getting burned because I didn't have everything in the path. It would do bootp reliably, but didn't work with every DHCP server. Netbeui was an easier if your network and file server can handle that, but that protocol has almost disappeared from memory. And the difficulty of getting a modern windows OS to work with the old SMBv1/CIFS can be a challenge in and of itself

NetWare was easier on the client side, but who wants to run a NetWare server? Masochists and sysadmins with Stockholm syndrome, that's who!

A packet driver with mTCP is probably the way to go these days if you can find a working packet driver. Works with DHCP and modern SMB stuff.

For sake of completeness, there used to be Microsoft Workgroup Add-On for MS-DOS and Microsoft Workgroup Connection, too.
But they didn't support TCP/IP yet. They were rather meant for the conventional Workgroup networking via NetBEUI.
Anyway, just mention it in case someone reads about them online.

Microsoft KB 122297 says:

Microsoft Network Client version 3.0 replaces Microsoft Workgroup Add-On for MS-DOS and Microsoft Workgroup Connection.
It is the preferred MS-DOS client, except for remoteboot configurations.
Microsoft will continue to make the Microsoft Workgroup Add-On for MS-DOS available for customers who want its file and print server capabilities.

https://jeffpar.github.io/kbarchive/kb/122/Q122297/

CharlieFoxtrot wrote on 2025-09-23, 13:12:

I’d argue that having DOS systems networked really takes away much of the mass storage issues too. […]
Show full quote

megatron-uk wrote on 2025-09-23, 09:27:

The only disadvantage is that you don't get a network drive to launch things from... but with all of the cheap options for mass storage on retro computers now, is that really the best option? I'd argue possibly not...

I’d argue that having DOS systems networked really takes away much of the mass storage issues too.

Majority of my DOS systems still use HDDs, either what they originally shipped with or something that can be used without overlay software or XTIDE bootrom.

I have zero reasons to try to maximize HDD capacity, because file transfers are so effortless with FTP. If I don’t need or use something, I just delete it and possibly backup setting files or save games for future use. And I can easily again transfer the program later on to the HDD if I want to. There is just no need to hoard stuff on the HDDs.

Now, before I started to do this, I often kept software on HDD as long as possible, because re-installing it is a hassle itself. Or at the minimum I wanted to keep install floppies at hand, which meant bunch of disks needed to be stored. CD-RWs can be handy, until you have a system without optical drice or drive doesn’t support those.

Networking and FTP is just a godsend and thankfully 10baseT ISA cards can be easily found and aren’t even expensive.

If you dont mind the sacrifice of 64k of umb, the use of a stacker or drivespace 3 cvf, xmsdsk, and an (s)ftp client can get you a lot of mileage.

Using drvspace.sys with the /move argument can reclaim a good chunk of this sacrifice.

Basically, your config.sys loads the xms and ems managers, relocates the drvspace.bin driver to xms, and loads the packet driver or anything else you need.

Autoexec.bat then loads xmsdsk, calls the (s)ftp client, and pulls a single .000 file, and writes it to the ramdrive.

Calls attrib on this file to set it hidden and system.

Calls scandisk with the undocumented /mount argument on the ramdrive, which mounts the cvf at that drive letter. (If the ramdisk was drive X:, the compressed volume will become dtive X:, and the host ramdisk will become H: by default. Configurable by messing with drvspace.ini)

Loads anything else you need (mscdex, mouse driver, soundcard init routines, whatev)

a ram hosted cvf can even be used to house windows this way.

Anachronistic machines with 'entirely too much ram in them' can easily host these with room to spare. Be sure to put the ramdisk at the top of memory with the /t argument with xmsdsk.

I love watching these discussions ... it s helpful to see all of the alternatives and how people are using things.

Re: 3C905C: In general the card and packet driver work well but the packet driver is cursed in a few ways which made it difficult to get it working with NetDrive. (It is the only packet driver where I had to work around bugs in the packet driver.) If you are just using mTCP and NetDrive it is fine. Other software might have to change to work around the packet driver bugs. (See https://www.brutman.com/Device_Drivers/Device … Collection.html for the version of the packet driver that I use.)

I think one of the big use cases for NetDrive that people are missing is quick, additional storage that doesn't require moving hardware around or rebooting. This week I wanted to clone my Turbo C++ development environment onto another machine. To do that I mounted a "scratch" disk via NetDrive, used xcopy to do a recursive file copy to it, unmounted it, remounted it on the other machine, and then copied what I wanted onto the local drive. That's about six steps total and it was fast. There are not too many ways you can add 2GB (or more!) of storage to a DOS machine without requiring a reboot ... It's also a great way to do backups.

In the next version of mTCP I'm going to add a small utility that copies a DOS partition on a machine to a NetDrive device. That will make it even easier to do a backup. Just boot, load a packet driver, run the utility, and every sector of the DOS partition will be copied to the remote server.

Oh, so much information!!! Since I'm very new to networking under DOS, it will take me forever to analyze every post. I don't care much about memory consumption because I would only load what's necessary to have a network drive when needed. Nowadays, there are many ways to move data; what I was looking for was simply because this route intrigued me. I know FTP is the simplest way, but I don't need a simple way; I already have one by removing the compact flash from the computer and inserting it into the Windows 10 system to copy everything I want in a matter of seconds.

I hope I have time to experiment, but between work and two kids, I have very little. I know it's unethical, but if someone could give me those 10 clear and simple steps to do it, I could do it. Then, once I see it work, I can experiment without the frustration of not seeing anything work for weeks.

thanks a loooot

mbbrutman wrote on 2025-09-23, 16:50:

I love watching these discussions ... it s helpful to see all of the alternatives and how people are using things. […]
Show full quote

I love watching these discussions ... it s helpful to see all of the alternatives and how people are using things.

Re: 3C905C: In general the card and packet driver work well but the packet driver is cursed in a few ways which made it difficult to get it working with NetDrive. (It is the only packet driver where I had to work around bugs in the packet driver.) If you are just using mTCP and NetDrive it is fine. Other software might have to change to work around the packet driver bugs. (See https://www.brutman.com/Device_Drivers/Device … Collection.html for the version of the packet driver that I use.)

I think one of the big use cases for NetDrive that people are missing is quick, additional storage that doesn't require moving hardware around or rebooting. This week I wanted to clone my Turbo C++ development environment onto another machine. To do that I mounted a "scratch" disk via NetDrive, used xcopy to do a recursive file copy to it, unmounted it, remounted it on the other machine, and then copied what I wanted onto the local drive. That's about six steps total and it was fast. There are not too many ways you can add 2GB (or more!) of storage to a DOS machine without requiring a reboot ... It's also a great way to do backups.

In the next version of mTCP I'm going to add a small utility that copies a DOS partition on a machine to a NetDrive device. That will make it even easier to do a backup. Just boot, load a packet driver, run the utility, and every sector of the DOS partition will be copied to the remote server.

One thing I would like to have is a statically compiled ARMHF binary of the linux version of netdrive's server.

I could run it natively on my consumer-grade trash-tier NAS that way.

I suppose I could build my own from the provided source, but having some premade would be nice.

Edit-- the existing ARM-5 binary is not friendly this way.

Being a hyper-minimal embedded linux, it really NEEDS all the libraries to be statically linked. Otherwise you get dumbness like this

Being able to run the netdrive server there would be very very convenient. (I can get it to run automagically with some voodoo on this appliance.)

AlessandroB wrote on 2025-09-23, 19:18:

I know it's unethical, but if someone could give me those 10 clear and simple steps to do it, I could do it. Then, once I see it work, I can experiment without the frustration of not seeing anything work for weeks.

thanks a loooot

My post above had how-to videos included, on real hardware as well not virtual machines.
Personally I'd recommend Windows for Workgroups.
1. Because it's the about the only reason I use that version of Windows now.
2. Having a GUI (Windows File Manager) makes things so much easier.

If you don't want to use Windows then I'd go with Network Client 3.0 only because it has a bit more info on the net.

Need to know what network card you have in the dos PC for the correct network driver to use.

AlessandroB wrote on 2025-09-23, 19:18:

Oh, so much information!!! Since I'm very new to networking under DOS, it will take me forever to analyze every post. I don't care much about memory consumption because I would only load what's necessary to have a network drive when needed. Nowadays, there are many ways to move data; what I was looking for was simply because this route intrigued me. I know FTP is the simplest way, but I don't need a simple way; I already have one by removing the compact flash from the computer and inserting it into the Windows 10 system to copy everything I want in a matter of seconds.

I hope I have time to experiment, but between work and two kids, I have very little. I know it's unethical, but if someone could give me those 10 clear and simple steps to do it, I could do it. Then, once I see it work, I can experiment without the frustration of not seeing anything work for weeks.

thanks a loooot

Because you haven’t actually used DOS networking before, I suggest you make the basic install first and make sure you have a working configuration. That is the absolute start of everything. Install the card, configure it, install packet driver and mtcp and after running the dhcp, check you have the TCP/IP networking running and working. Then you can continue with the more exotic stuff when you understand how the networking works in DOS and what is needed for the functionality.

I think you have all the relevant information here already to setup network drive by other users here, but it may be diffiult to grasp it all because you have zero experience with DOS networking to begin with. Although setting DOS networking isn’t rocket science, I have installed NICs from several different manufacturers, but they are all a bit different how they are set up.

wierd_w wrote on 2025-09-23, 22:41:

One thing I would like to have is a statically compiled ARMHF binary of the linux version of netdrive's server. […]
Show full quote

One thing I would like to have is a statically compiled ARMHF binary of the linux version of netdrive's server.

I could run it natively on my consumer-grade trash-tier NAS that way.

I suppose I could build my own from the provided source, but having some premade would be nice.

Edit-- the existing ARM-5 binary is not friendly this way.

Looking at your screen shot, it seems the system doesn't even recognize the executable format, and falls back to execute it as shell script. The executatble is a statically linked ELF file, so basically it is what you request. I wonder whether the EABI5 vs. EABI7 distinction is what makes your system reject the executable, or something more convoluted is going on:

1user@host:~$ file netdrive_linux_arm_5
2netdrive_linux_arm_5: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, Go BuildID=rBzoyRokZKCcbqneGv9t/Acr5LH3vpwfUOaNsR5wK/uxqdd5VOTEXmFH4SZX2O/tIfb2uV2L6GeegVAMQNN, stripped