Applications include fresh implementations of a DHCP client, FTP client and server, HTTP server, IRC client, Telnet Client, SNTP client, Ping, and some other goodies. (These are not stale ports of old code.) Everything runs in 16 bit DOS and the library is open source.
The target is retro-computing hobbyists and people stuck with embedded solutions that use DOS. A good FTP client can be a godsend in that situation.
The DOS TSR approach would make TCP/IP a common service for DOS programs. I went with the library approach for speed and customization purposes.
Other notable cards for older machines include the NE1000 (8 bit), NE2000, Intel 8/16, Western Digital or SMC 8000 series. Many PCI cards work well; just look for a packet driver. For those of you without real slots the Xircom PE3-10BT device is great, but they are getting more expensive in the wild.
SLIP and PPP work. PLIP works too, but I have not tested it myself.
And there are even packet drivers that allow for Token Ring and Arcnet to be used; they emulate Ethernet.
I also have a real NE1000 that I use in a Zenith Z-161 luggable, an XT class 8-bit isa machine. This is the machine I mostly use mTCP on.
https://github.com/Manawyrm/ISA8019
Seems like the common consensus is $10 scrapyard NIC plus Wi-Fi bridge. TBH, I was always surprised that the consumer Wi-Fi bridge was never a popular thing. You'd think it would sell more easily to customers, because most PCs have had Ethernet on board since like 2000, and even adding a USB dongle means having to bring new drivers in.
Now going full off tangent-- what happened to old wireless client hardware? If you go into any thrift shop, you're going to see a bunch of old 802.11g or n routers, but you usually don't see the adapters. I could see internal ones being scrapped with the PCs they were in, but I'd expect people who bought a new-spec router and matching adapter would replace them together.
I prefer to look at DOS as "stable."
I don't see the connection. Is this a reference to something from the 80s?
This superposition of statements is set against the backdrop of the tech idiom, "friends don't let friends" followed by some activity. [1]
This tech idiom is based on a decades-old advertising slogan, "Friends Don't Let Friends Drive Drunk," by MADD, Mother's Against Drunk Drivers. [2]
[1] https://www.google.com/search?q=%22friends+don%27t+let+frien...
What I have now can best be described as cooperative multitasking with custom contexts. Example: the FTP server and HTTP server keep track of each user connection, provide them a buffer, and know the state of the session and how far into the file they are that is being transferred. (True multithreading would generalize that kind of context as a set of registers and a stack for each thread.)
There's some osdev tutorials about how to enable multiple cores in DOS, iirc. I can dig them out, if you want. You're probably seriously overthinking this.
Right now you're polling, which is fine, because that's how all the high performance software works. One thread pre core, each thread rolling through a list of connections, checking if there's new data.
DOS isn't fully dead yet. I was assuming his code actually runs on modern machines.
Just read your bit on how focused you felt using that. Very interesting!
I still have my ATX big case pc and won't give it up for a laptop even though it makes no sense (well it does in that I can upgrade bits as I please).
However for the most part I associate computers with work and stress these days.
Reminds me of that era, when office computers didn't support TCP/IP at the system level: applications had to implement their own stack.
1990s-me used NCSA Telnet on the Mac every day.
https://en.m.wikipedia.org/wiki/NCSA_Telnet
Once Windows Sockets API was nailed down, a good TCP/IP stack was available on DOS as a system network driver. And IIRC Apple released a system service as well, as a System extension and Control Panel.
I'm not sure if that's stupid, but I've done a lot of things with raw ethernet frames, and used LWIP, but...I'd like to develop my own someday, just to "know" how it's all really supposed to work.