ethflop - a network-backed floppy emulator for DOS

[mateuszviste]

How is this better/more desirable than accessing a network drive?

I'd call it mostly a personal preference thing, but there are a few reasons why I prefer ethflop over EtherDFS in *some* situations:
- 2K resident size (on a PC that has less than 200K of available RAM, every byte counts)
- amount of addressable data is limited to the mounted diskette, so if things should go very bad very quick (virus? crash? whatever), I'm not risking the entire content of my network drive
- preserves the "floppy" aspect of the experience - nice for running software that was originally distributed on a diskette
- much simpler under the hood, so there is zero risk that the software being executed will get confused because of some filesystem-related incompatibility
- can be mounted as write-protected - I like to do it when mounting my antivirus floppy image. In the event that I am scanning an infected system, I don't risk infecting the antivirus floppy image itself

 

[Eudimorphodon]

>>> The thing is that ethflopd requires access to raw sockets for crafting its own Ethernet frames, that's quite a low-level feature that is not necessarily part of whatever the W10 linux system provides.

That probably does rule out just running it on the W10 Linux subsystem unless some rumored recent improvements opened up some of its limitations. I remember when I first played with Ubuntu on it you could "ping" but you couldn't run traceroute or anything else that went even a step deeper because netlink and raw sockets weren't allowed. (Apparently even Ping didn't work initially.)

 

[gslick]

>>> The thing is that ethflopd requires access to raw sockets for crafting its own Ethernet frames, that's quite a low-level feature that is not necessarily part of whatever the W10 linux system provides.

Winpcap (or Win10pcap) is the thing to do this. I used it many years ago to talk at the raw level actress Ethernet.

That is what I was going to suggest myself if someone had the motivation to try porting this to run on Windows.

I had WinPcap installed on my Windows 10 system that I use to run SIMH. It quit working a while ago after a Windows update. I uninstalled it an installed Npcap instead to get things working again.

nmap.org/npcap/

I don't know anything about the API provided by WinPcap / Npcap. It must provide a low level enough interface to sending and receiving Ethernet packets that, for example, an emulated SIMH VAX running on a Windows 10 system can send and receive MOP, LAT, LAST/LAD and DECnet packets on the physical Ethernet interface.

 

[Trixter]

I'd call it mostly a personal preference thing

Fair enough. It's not for me, but for people who like to preserve the floppy-only experience, they'd like it. The only use I would personally have for it is for running/testing applications that are hard-coded to reference A: for their program code locations (they can be cracked, but it's a pain).

I appreciate that the TSR is now finally in assembler. Time to convert EtherDFS over to assembler?

 

[mateuszviste]

Fair enough. It's not for me, but for people who like to preserve the floppy-only experience, they'd like it.

Most, if not all, practical situations can be addressed with EtherDFS alone. Still, under-2K resident size is nice.
EtherDFS is minimalist already, but ethflop takes the minimalism to another level. And I like minimalism - that is reason enough for me to use ethflop instead of EtherDFS (when applicable).

I appreciate that the TSR is now finally in assembler.

It's not really a "finally" matter - should I re-do EtherDFS today, I'd still re-do it in C without hesitation. It's a matter of effort vs result vs time. ethflop is a very minimalist approach, and as such I had enough time budget to do it in full assembly. In comparison, EtherDFS is a highly complicated beast, doing it in asm would easily take (me) months of writing and debugging.

Time to convert EtherDFS over to assembler?

Nope, still not. Sorry.

 

[Shadow Lord]

Hi,

This is definitely a very cool utility. There has been a need/req. for a software floppy emulator that this could fill (i.e. when you don't feel like writing 12 disk images to actual floppies to install a program). A couple of quick questions/suggestions:

1. What happens if a system already has two floppy drives (say 3 1/2" and 5 1/4") already installed? Can the emulated drive letter be changed/moved?

2. I know there has already been a discussion regarding IMD disks - however, any possibility of adding IMD format as a non-protected format? I use IMD to make all of my disk images so to use this utility I would have to convert the file to IMG. It would be nice if we could just load IMD files (and with the full knowledge that no special direct access disks would work).

3. As others have said a disk change facility would be nice. Nothing elaborate - maybe something like this: All the disks would be placed in one directory and named in some prescribed way (say files are in WIN311 directory and disk are name 01.img, 02.img, 03.img - 11.img you get the idea). Then all the TSR has to do is trap two hot keys (say "ctrl +" and "ctrl -"). The TSR would then step up/down in the file name and load the disk. I am not a programmer so I am not sure how much bigger this would make the TSR's footprint. However, it should be less then a routine that pops up a dialog box asking for the name of the image each time. Of course it would be limited to install disk sets but that is when you would need it most.

 

[Eudimorphodon]

3. As others have said a disk change facility would be nice. Nothing elaborate - maybe something like this: All the disks would be placed in one directory and named in some prescribed way (say files are in WIN311 directory and disk are name 01.img, 02.img, 03.img - 11.img you get the idea). Then all the TSR has to do is trap two hot keys (say "ctrl +" and "ctrl -"). The TSR would then step up/down in the file name and load the disk. I am not a programmer so I am not sure how much bigger this would make the TSR's footprint. However, it should be less then a routine that pops up a dialog box asking for the name of the image each time. Of course it would be limited to install disk sets but that is when you would need it most.

I guess I'd like to pile on here and say that disk change support is what would really make this a killer app for doing software installations, etc, on machines that are floppy impaired. (A thing I'm dealing with right now.) I wouldn't mind if it was implemented on the server side instead of within the TSR. (IE, some way to send a signal to the daemon to tell it to switch disk images.)

 

[Eudimorphodon]

...

Re: my previous comment, I figured out a trashy poor-man's version of implementing disk change on the server side. (Maybe it was obvious but a previous comment in this thread said don't touch the images while the daemon's running.) As a test case I was able to install Windows 3.11 from floppy images by mounting a "bait" floppy image read-only through the ethflop TSR, and as the installation progressed and asked for subsequent disks I simply did this:

cat diskmage_whatever_number.image > bait.img

No doubt it's not a kosher thing to do but it apparently didn't upset the running daemon's file descriptors enough to break anything.

 

[keenerb]

...

Re: my previous comment, I figured out a trashy poor-man's version of implementing disk change on the server side. (Maybe it was obvious but a previous comment in this thread said don't touch the images while the daemon's running.) As a test case I was able to install Windows 3.11 from floppy images by mounting a "bait" floppy image read-only through the ethflop TSR, and as the installation progressed and asked for subsequent disks I simply did this:

cat diskmage_whatever_number.image > bait.img

No doubt it's not a kosher thing to do but it apparently didn't upset the running daemon's file descriptors enough to break anything.

Fantastic Eudimorphodon. I was really hoping some sort of workaround could be found for multi-floppies.

 

[keenerb]

This is working pretty great. I'm curious what happens if you mirror your boot floppy to a ethflop image and swap during boot...

 

[mateuszviste]

Re: my previous comment, I figured out a trashy poor-man's version of implementing disk change on the server side. (Maybe it was obvious but a previous comment in this thread said don't touch the images while the daemon's running.) As a test case I was able to install Windows 3.11 from floppy images by mounting a "bait" floppy image read-only through the ethflop TSR, and as the installation progressed and asked for subsequent disks I simply did this:

cat diskmage_whatever_number.image > bait.img

No doubt it's not a kosher thing to do but it apparently didn't upset the running daemon's file descriptors enough to break anything.

It's cool, and I'm glad that works for you, but I cannot recommend such approach. It may work fine in your case, but this is quite risky. The thing is that ethflopd opens the diskette image and keeps an open file descriptor to it. Any external change of the image in the meantime *should* be reflected to ethflopd, but there is no guarantee of that, depending on how the operating system performs caching and processes parallel accesses to files.

The "proper" way would be to write a tiny "ethflop-control" linux tool that would be able to overload commands for any currently connected client (for example "ethflop-control 00:aa:b6:d4:e1:04 eject"). This is actually a relatively easy job, the only problem being that I have litle motivation to do it, since it wouldn't be useful to me at all. But maybe some day, if I have nothing else to do...

 

[keenerb]

If you get an opportunity to enable disk swapping that would be great. For me, it would change ethflop from a novelty to a hugely useful tool. Already hit a half-dozen instances where lack of swapping is killing me.

 

[Eudimorphodon]

It's cool, and I'm glad that works for you, but I cannot recommend such approach. It may work fine in your case, but this is quite risky. The thing is that ethflopd opens the diskette image and keeps an open file descriptor to it. Any external change of the image in the meantime *should* be reflected to ethflopd, but there is no guarantee of that, depending on how the operating system performs caching and processes parallel accesses to files.

Obviously it's not a particularly kosher thing to do, but... I could be wrong, but my vague understanding of the standard POSIX filesystem calls would be if you're not caching the image in RAM yourself, IE, every request from the client makes a filesystem call instead of relying on a buffer you're handling like an array, then any caches should have been flushed by the OS when the file is updated by the "cat" operation. (This is assuming, of course, that you cat-in the new file when the disk is "quiet", if you do it in the middle of a read operation then you'll probably get old data up to the next block boundary?) If you swapped it out in the middle of writing then, yes, that would be bad and would have very undesirable results. I've never tried this trick with the image mounted R/W, because I haven't had a use case for it but I am far more pessimistic about it working out.

Honestly about the only use case I have for this software is running installers that are hardwired to ask for a specific floppy or sequence thereof to be inserted under circumstances that don't allow dropping to a DOS prompt to issue a disk-change command, but, hey, different strokes for different folks.

 

[cr1901]

Well, this is a month- or 3- late, but I wrote a blog post on ethflop and how to use it. Short version, I'm extremely pleased with it and glad mateuszviste wrote it. So thank you :D! https://www.wdj-consulting.com/blog/ethflop/

 

[keenerb]

I've been using this for some time now.

I'm a HUGE fan, to the point where I'm considering pulling my drive controller and simply booting from a Gotek and using B: as my primary drive.

 

[superjer2000]

It's cool, and I'm glad that works for you, but I cannot recommend such approach. It may work fine in your case, but this is quite risky. The thing is that ethflopd opens the diskette image and keeps an open file descriptor to it. Any external change of the image in the meantime *should* be reflected to ethflopd, but there is no guarantee of that, depending on how the operating system performs caching and processes parallel accesses to files.

The "proper" way would be to write a tiny "ethflop-control" linux tool that would be able to overload commands for any currently connected client (for example "ethflop-control 00:aa:b6:d4:e1:04 eject"). This is actually a relatively easy job, the only problem being that I have litle motivation to do it, since it wouldn't be useful to me at all. But maybe some day, if I have nothing else to do...

I setup EtherDFS the other day and was in shock at what an awesome system it is, especially as I had struggled to get LANMAN up and running only to find it wiped out probably 250k of my RAM. I only stumbled upon a thread talking about EtherDFS by chance but I’m glad I did. I was trying to install some software using EtherDFS that spanned multiple disks but during the install process I realized it didn’t provide an opportunity to switch paths which was needed as I had copied the images to subdirectories So long story short I ended up finding ethflop but haven’t had a chance to install it yet.

I read this thread and noted it doesn’t support swapping disks and that the kludge offered here using cat isn’t recommended. I had a quick look at the ethflop Linux code and the recommendation by the author and think it would be pretty easy to adjust the code for the Linux server so it only runs in the foreground and presents CLI menu that lists the current cliententries which could then be selected by number and then an option to swap disks could be presented. This would then call the right routines in the server so it should be clean

If nobody else has done this or found a better way I’ll make the relevant tweaks but I thought I’d check first.

And thanks to the author for this great tool. Between this and MTCP I am loving my 5150!

 

[mateuszviste]

think it would be pretty easy to adjust the code for the Linux server so it only runs in the foreground and presents CLI menu that lists the current cliententries which could then be selected by number and then an option to swap disks could be presented. This would then call the right routines in the server so it should be clean

You are very welcome to adapt the code to your needs, but I have to say that the solution you propose is not something I'd be willing to integrate upstream. Having a daemon running in foreground and presenting swapping-disk-options for possibly several clients at the same time is definitely not something I'd like to see.

In my humble opinion, a saner option would be creating a small Linux tool that is able to send "eject / insert floppy" messages to etherflop-server on behalf of a DOS client (simply identified by its MAC).

 

[superjer2000]

You are very welcome to adapt the code to your needs, but I have to say that the solution you propose is not something I'd be willing to integrate upstream. Having a daemon running in foreground and presenting swapping-disk-options for possibly several clients at the same time is definitely not something I'd like to see.

In my humble opinion, a saner option would be creating a small Linux tool that is able to send "eject / insert floppy" messages to etherflop-server on behalf of a DOS client (simply identified by its MAC).

Thanks for your feedback - As I was thinking about it a bit more I was thinking the following would work well:

1. If the server is launched with the option to NOT daemonize the server would present a numerical list of current clients and loaded images. (I haven't actually run the software yet so an approximation of what I think it looks like based on the the server code). This would get reprinted whenever a client or image change occurs.

Connected clients and images:

1. [MAC ADDRESS 1] FLOPDISK.IMG
2. [MAC ADDRESS 2] OTHIMG.IMG
3. [MAC ADDRESS 3] INSTALDK.IMG

Select an entry to load a different image: 2

Available Images

1. GAME.IMG
2. APPLDSK.IMG
3. PAKUMAN.IMG

Select an available image or [E]xit:

2. When a new image is selected, the calls to eject and load a new image would be made. When run in this mode, all updates, messages that would typically be sent to the client would be redirected to the linux server.

3. If the process isn't run with the NOT daemonize argument nothing would be different.


This would be easier to use for my use case of ETHFLOP which is installing software. I default to EtherDFS for most other tasks. I am curious though what your aversion is to this type of option rather than a separate program? Given that you invented EthFlop, there is likely something you are considering that I am not. I guess I could do everything above via another program that somehow interfaces with EthFlop but the above seems like a pretty quick set of changes to the code you have written. (Which was incredibly easy to follow even for me who is anything but an accomplished C programmer).

Thanks for your feedback!

 

[mateuszviste]

I am curious though what your aversion is to this type of option rather than a separate program?

Your method would certainly work, I simply consider it bad design to run daemons in foreground and (even worse) expect them to have any kind of direct user interaction. That is why I was suggesting a separate tool that would feed ethflop-server with specific control instructions. It should be fairly easy to extend the ethflop (DOS) tool for that (but could even be web GUI in some "deluxe" version). The limitation of doing this in the ethflop client is of course that then one would require another DOS machine for controlling the eject/insert actions, that is why a separate Linux program might be more desirable.

I guess I could do everything above via another program that somehow interfaces with EthFlop but the above seems like a pretty quick set of changes to the code you have written.

I agree that quick and dirty hacks are usually easier/faster to create than elegant solutions, yes. ;-)

 

[keenerb]

I'd vote for some sort of "ethflopswap" linux app that would allow you to specify eject/insert of a new disk image.

My use-cases for ethflop really hit a wall with the inability to reliably swap disk images during installations.

A basic commandline "ethflopswap <client mac> <imagename>" would be 100% usable.

Something like midnight commander interface with list of clients on left, and a list of disk images on right, and you "tab" between the two and can insert/eject disk images would be PERFECT though. Maybe even include copy/rename/delete functions for local disk images? That's just my wishful thinking though, I'd be happy as a clam either way.