Why weren't cool apps like this and the EtherDFS/ethflop utilities ever written and released back in the 90's? Is there a technical difficulty that a DOS server version would have been impossible? Was everyone just in a hurry to update their skills for Windows dev tools and didn't want to spend time on a developmental dead-end?

To be honest, I think because we didn't use network cards so often.
And if we did, it were BNC types with a bus topology (vs ring or star).

In the late 90s, torwards the end of the DOS era, RJ45/twisted-pair became more popular.

Null-modem cables and LapLink cables were good enough for smaller networks at home and in the office, too.
There were shareware tools like Comdrive, too.

Edit: Norton Commander 5.x and MS-DOS 6.x supported such connections too.
DOS had INTERLNK and INTERSVR, similar to LapLink.
File Maven 3 supports a serial connection, too.

Full-fledged network software like Little Big Lan existed, too. It could use serial, parallel, arcanet and ethernet connections, afaik.

Some also used Macs and the PhoneNet cabling. PCs could participate AppleTalk networks, too, with appropriate software.

Novell netware also was a factor throughout the whole 90s, but IPX/SPX wasn't so well supported on *nix systems.

They did exist for DOS. But perhaps the thing is that they were for enterprise environments as no one was kicking around the expense of ethernet at home for a couple machines when they had plenty of floppy disks already to the task. And soon Windows Networking took care of it for the average home user when ethernet started catching on.

+1

The 90s were wild times. There was a lot of experimenting going on.

In my country, it was all about ISDN and online services like T-Online or CompuServe.
The internet and TCP/IP were very nerdy stuff, I didn't hear about it until 1996 or so.

In the early 90s, in my country, PC networks generally used Novell (IPX), MS Lan Manager or then-new WfW 3.10 (which also was available as part of a network card kit).
Or one of the smaller solutions (Kirschbaum Link/Network).

Novell DOS 7 shipped with Personal Netware and offered Windows 3 support (graphical utilities), too.

The majority of home users was glad to have a humble serial connection, already.
There wasn't much to transfer, anyway.

BBS operators maybe had a dedicated server for storage, though.
And even 115KBit/s of a serial port were fast enough for that, considering that users called the BBS via, say, 19k2 modems.

Two-player mode in games usually supported modem/null-modem.
Commercial titles often offered IPX support, too.

Anyway, there also were power users of the time. Machinery in a factory, workplaces for CAD/CAM, hospitals, warehouses, etc.

These places already had similar infrastructure to what we have now.

Edit: Public utility, schools, universities and military also had "real" PC networks running at the time.

Doom can help finding more information about it, maybe, because it was famous for slowing down network performance.
https://doomwiki.org/wiki/Doom_in_workplaces

I'm actively testing the next round of server side changes:

• Fix the read-only file detection bug reported earlier.
• Implement a "headless" mode ... it's not a true Unix daemon but it will be closer. (You will be able to throw it in the background and cleanly terminate it with SIGTERM.)
• Add more robust signal detecting and handling (needed for the headless mode).
• Add code to detect (and reject) opening the same image multiple times in read-write mode.
• Fix some typos.

Yes, ethernet was definitely late 90s in the home. But even then, and when you go back to the early 90s, even fast modems to go online cost a bit of money. So certainly, serial port was the primary way to transfer data, and the applications out there were sufficient for this purpose. For sharing data BBSes were a good way to go. So yeah, everyone already had an option to skip floppy disks without needing ethernet applications, all that was needed was usually stuck on an I/O card was floppy and hard disk, along with serial or parallel.

keenerb wrote on 2024-01-08, 19:38:

Why weren't cool apps like this and the EtherDFS/ethflop utilities ever written and released back in the 90's? Is there a technical difficulty that a DOS server version would have been impossible? Was everyone just in a hurry to update their skills for Windows dev tools and didn't want to spend time on a developmental dead-end?

A few things have changed over the years:

• The new networking software encourages more people to try networking. Which in turn increases the demand for networking software. (It's a virtuous cycle.)
• 20+ years ago these were busted old DOS machines that were fun, but mostly just for giggles. In the present day they aren't just somebody's old crappy computer; they are a hobby item that gets attention and money.
• Running a server in your house has never been cheaper or easier.

Open source has a lot to do with it too - we are standing on the shoulder of giants.

I think that not long after our family got a second PC in around 1994, we picked up a copy of NetWare Lite and two NE2000 clones with enough coax cable to run down the hallway, but it wasn't too long before we upgraded to Windows for Workgroups and then started using the Workgroup Addon for MS-DOS instead of NetWare Lite because the integration on the Windows side was nicer (or at least I thought so).

I think that back then it was rare enough for a household to have even one PC, let alone two, and everything on computers was hard enough for your average user to get working in the days of DOS without adding networking to the mix, so I think that would put most people off, especially if they'd never experienced a LAN elsewhere. In our case though part of my father's job was doing NetWare admin, so that might have affected the decision!

For us it wasn't about making it easier to move files between machines, it was about mounting every drive from one machine on the other and vice versa, because hard drives were just so small back then that this meant you could run software which you didn't have space to install on the local drive. I did also run a very small BBS, and while it only had one node, being able to use the other PC's hard drives as extra storage was very useful for that too. Also, I think we only had one CD-ROM drive, and the network meant that the other machine could at least access the data off CDs, if not the audio.

keenerb wrote on 2024-01-08, 19:38:

Why weren't cool apps like this and the EtherDFS/ethflop utilities ever written and released back in the 90's? Is there a technical difficulty that a DOS server version would have been impossible? Was everyone just in a hurry to update their skills for Windows dev tools and didn't want to spend time on a developmental dead-end?

There was one package I'm aware of back then which fits into this sort of category: KA9Q NOS. It ran on DOS and other old platforms, had a TCP/IP stack, and could simultaneously act as an FTP, telnet and mail client and server over packet driver interfaces plus (the thing it was really written for) amateur packet radio. I think that by the time I learned about it I was already running an OS with TCP/IP built in (Windows 95) so I only ever had a quick look at it, I don't think I ever used it to connect to anything.

keenerb wrote on 2024-01-08, 19:38:

Why weren't cool apps like this and the EtherDFS/ethflop utilities ever written and released back in the 90's? Is there a technical difficulty that a DOS server version would have been impossible? Was everyone just in a hurry to update their skills for Windows dev tools and didn't want to spend time on a developmental dead-end?

For one, 100Mbit ethernet was not a thing. The RJ jacks were not a thing, most networks were token Ring etc.

For another, there was very little that could not be moved around with floppies. You are forgetting that at the time the average hard drive backup would fit as a backup onto 30-40 floppy disks.

KA9Q was how Internet early adopters in the UK began there interweb journey, Demon Internet provided it as the default client. Whilst early Win Trumpet did exist around them, it was awful it you didn't have a hardware FIFO uart so most people used KA9Q under DOS.

Usenet, email, telnet and FTP, all multitasking inside of it. Gopher sites could be accessed from telnet and you could also telnet and try out this thing called HTTP at CERN.

Is there any possibility of adding support for multiple remote images being mounted at the same time?

What about FAT32 support?

Thank you!

I will eventually add support for a second drive letter so that you can mount two images at the same time. Going to four isn't even that difficult, it just takes more room. (I need a few dozen bytes of storage for each connected drive letter to maintain state.)

FAT32 is slightly more work. The device driver really doesn't care, as it's just told to read and write sectors. But I have some error checking code on the server side that might need to be extended to support FAT32. (If I didn't do any error checking at all it would work as is.)

I've made some changes to the server side:

• I've added a "headless" mode for people who don't want to use the text UI. It's not a full Unix-style daemon but you can throw it in the background now and you can probably use "daemonize" on it.
• An ARM version of the server is available now. (Somebody else already verified that it works on a Raspberry Pi without changes, but I wanted to do it myself to be sure.)

I'm also looking for more feedback and testing help. In particular I'm running a public server at brutman.com that you can connect to and play around with.

• 200MB disk image: netdrive connect brutman.com:2002 bigdisk.dsk d:
• 32MB disk image: netdrive connect brutman.com:2002 fat12.dsk d:
• 2GB disk image: netdrive connect brutman.com:2002 hugedisk.dsk d:

The 32MB image is suitable for all versions of DOS including 2.x and 3.x. The 200MB image is FAT16B so you need to be running DOS 3.31 or greater to test it. The hugedisk.dsk image is mostly empty and it's just there for giggles. (Change the drive letter as needed.)

These disk images support writes too - feel free to play around with them. The writes are only visible to you during your session, so if something gets too badly messed up just disconnect, reconnect, and it will all be clean again.

Sorry, no source code yet ... I'm still actively making changes and trying to get more feedback on what I've already provided.

I'll think I'll switch to this thread for the feedback instead of mail; it makes more sense 😉

Overall feedback:
- My advice would be to add more warning / error messages
("Netdrive.sys not loaded", "Netdrive status on a drive which is not netdriven", "Please use the drive letter provided by netdrive.sys", etc.)
- Is there any particular reason you have to specify to drive letter? Can't this be read from netdrive.sys block driver?
- Adding a default port of 2002 on client, when not specifying port on client side
- mTCP default MTU size to change to 1200 (Any reason this is currently at 576?)
- Feature request for swapping floppy's on the server side

Specific feedback:
- It is working well enough in my ESX virtual machine running a vanilla full installation with FreeDos. Even from NL to US distances with added latency (albeit slow).
- Creating a disk with FAT16 with 200M fails with:
netdrive create hd 200 fat16 test.hd2
mTCP NetDrive by M Brutman (mbbrutman@gmail.com) (C)opyright 2023, Version: Jan 21 2024
Error: Specified size is too large for FAT16
But according to the docs "hugedisk.dsk: 2GB FAT16 disk, suitable for DOS 3.31 and up. Mostly empty." , so 200Mb should be fine
- On my a0751h running against my internal server it fails with
> CHKDSK on my netbook results in: " Processing cannot continue - File allocation table bad"
> Xcopy just crashes with an Jemmex exception 06; without Jemmex loaded it crashes without error.
Details:
- MSDOS 6.22
- Running with the ODIPKT driver
- Realtek NIC
- Onboard 160GB disk (Used for Windows 7)
- Booting from USB drive

Thanks for the feedback. Some quick responses:

• I think the warning message that asks the user if they specified the correct drive letter is sufficient. I don't want to add more code to scan for the device driver in memory, as that takes yet more RAM when the program runs and it's getting tight on a 128K machine as it is.
• You need to specify the drive letter because at some point I will add support for multiple drives to the device driver.
• The default MTU of 576 is the minimum required for IPv4. This is guaranteed to work across all networks and it was chosen to avoid IP fragments, which are memory and CPU intensive. It also works better for SLIP or PPP users. It has always been part of the documentation to increase this for performance reasons, not functional reasons. NetDrive is the first program to require a larger MTU setting for functional reasons.
• Floppy swapping on the server side: It's possible .. noted for another version.

On the specific feedback:

• The fact that it works across continents is amazing! From the NL to my server in the central US is nearly a 120ms round trip. That limits your data rate to a maximum of 8KB per second. (NetDrive tries to send 2 512 byte blocks per request. If DOS only requests a single 512 byte block that drops the data rate by half.) If somebody wants to setup a DOS shareware repository I suggest having a server in each major region to improve transfer times.
• Your failure to create a 200MB disk is a user error - there are three FAT options (FAT12, FAT16, and FAT16B) and you need to be using FAT16B, not FAT16. (There is a good discussion of this in the documentation. FAT16 is for DOS 3.0 to 3.3 which can make more efficient use of the disk but the disk is still limited to 32MB.)
• CHKDSK: I'd need more information to debug that, but as I wrote in email CHKDSK doesn't seem to present the "Abort, Retry, Ignore" option when there is a read error. In this case the read error could be a network timeout that causes a packet to be lost. The DOS critical error handler handles timeouts just fine but for some reason CHKDSK doesn't show it. I can assure you the image you are connecting to is fine and is not corrupted; I've run CHKDSK against it myself.
• Xcopy: Given that you are using an ODI packet driver shim, maybe there is something going wrong there? I'll try my FreeDOS virtual machine with JEMMEX to see if that works. Xcopy works fine with just a packet driver; that's how I populated these disk images.

Oh, one more quick test for the CHKDSK problem.

If you run NETDRIVE STATUS d: before CHKDSK it will give you packet statistics, including retries. Please run that first, then CHKDSK, and then get the statistics again. If the retry count went up then it's definitely CHKDSK getting a timeout, but not using the DOS critical error handler to give the user a chance to respond.

I'll try here in the US too, but it's more difficult because I have less of a chance of losing a packet at this distance.

mbbrutman wrote on 2024-01-25, 18:07:

Oh, one more quick test for the CHKDSK problem.

If you run NETDRIVE STATUS d: before CHKDSK it will give you packet statistics, including retries. Please run that first, then CHKDSK, and then get the statistics again. If the retry count went up then it's definitely CHKDSK getting a timeout, but not using the DOS critical error handler to give the user a chance to respond.

I'll try here in the US too, but it's more difficult because I have less of a chance of losing a packet at this distance.

Retries went from 0 (before chkdsk) to 8 (after chkdsk); it's weird though I am getting timeouts on my local network right?
(I am testing against my local server)

mbbrutman wrote on 2024-01-25, 18:04:

[*]Xcopy: Given that you are using an ODI packet driver shim, maybe there is something going wrong there? I'll try my FreeDOS virtual machine with JEMMEX to see if that works. Xcopy works fine with just a packet driver; that's how I populated these disk images.

The ODIPKT driver seems to work fine with htget (I use it regularly to copy another DOS project to this machine). But those are small files.
I will search for a packet driver for my NIC; so far I have not been succesful: PCI\VEN_10EC&DEV_8136

Retries on a local network should be rare, especially with modern hardware. Even on my older hardware (PCjr) I have to work hard to get a packet to drop, and I usually just give up and simulate that by throwing random packets away on the server side.

I don't have a lot of experience with the ODI packet driver shim. There was a previous thread here on Vogons where I helped somebody sort out performance problems with it; they were getting dropped packets too. The number and size of allocated buffers at the ODI level needed to be adjusted upward to resolve that problem.

Can you provide a reference link to that thread? I will check if can update my net.cfg accordingly and retry it on my netbook.
The quest for a working packet driver has failed.

Current config:
buffers 6 1600
envelope type ethernet_ii