The bad old days of messy DOS TSRs and expensive dialups
As I described yesterday, I used to run a BBS "back in the day", and dialing that one number could lead to a bunch of places. One thing I didn't mention was my Linux box. This is a tale about how I used to access it in a pinch, and a missed opportunity.
Sometimes, I'd be out in the world somewhere and I'd need to get into that system to do something. Back in those days, dialup SLIP cost a nontrivial amount of money (on the order of $3/hour or more), so I couldn't leave it nailed up. It had to be demand-driven, and that was my problem: how do you tell the machine to dial out when you can't get to it?
Well, there was always my BBS machine. It had a modem and it was on the same Ethernet as my Linux box. There was another problem, though: it ran Netware Lite with IPX over ODI drivers. I could never figure out how to make it run IPX over an ODI shim over a packet driver (some weird encapsulation issue), so it was one or the other.
Why did I care about Netware Lite? That's easy. My BBS machine was already full in terms of how many disks it could hold, and I had an auxiliary system which had a noisy but very helpful 40 MB (!) of additional disk space. Having it accessible over the network meant that much more breathing room for doing BBS stuff.
There was a program called DOORWAY which would let you get to a DOS prompt over the modem with a special password, and I could use that. Now I was sitting at "C:\>", able to push some packets over the network, but not able to do the TCP/IP my Linux box wanted to see.
One day, I came up with the solution. It was a truly nasty hack. The entire Netware Lite stack could be unloaded while in this DOS shell. It meant unloading client, server, ipxodi, the actual NIC driver (3c501 at one point, believe it or not) and lsl. Once all of those were gone, then I could load the packet driver and drop into NCSA telnet.
This got me a login prompt via telnetd and I was in business. I could su and kick off my SLIP script and a minute or so later would be able to telnet in from the outside - ssh hadn't been invented yet. After that, I'd just drop out of NCSA telnet and would be back at my DOS prompt.
Now I had a serious problem. I had evicted all sorts of things from "on top of" both DOORWAY and the BBS itself. Normally, memory on my machine looked like this:
0 [lsl] [3c501] [ipxodi] [server] [client] [BBS] [DOORWAY] [command.com]
But now... it was more like this:
0 [-- huge hole here --] [BBS] [DOORWAY] [command.com]
If I did "exit" to return to the BBS, it would lock up. There was no way to reload the drivers, either, since they would have loaded under all of that stuff in the space below my command shell! The only thing to do was reboot. The machine would come back up a minute or two later with everything squared away.
I should note for the purists that my memory scheme was actually a bit more complicated than that due to XMS and the HMA and QEMM's loadhi and all of that garbage, but it doesn't change the story. If you unloaded something, forget about getting it back. To be crystal clear, I don't miss that aspect of life on DOS at all.
I mentioned a missed opportunity above. I should have rigged up a second set of serial ports on the BBS and Linux box alike and then connected them with a null modem adapter. Then it would have been possible to just run a terminal program on my BBS on COM2 (COM1 being the modem, naturally) to hit the Linux box and bring up the SLIP.
If I had really thought about it, I could have actually used this to offer Linux shells to people way back before they were commonly available through ISPs. All it would have needed was yet another magic string given to my BBS frontend program. Then, instead of dropping into the fax receiver or GT netmail stuff, it could have just gone into a dumb program which shuttled data back and forth between serial ports.
Let's see here now. A dumb little program to effectively act as a "bent pipe" between two serial ports. Why does that seem so familiar? Oh, right.
Oops. Somehow, I never saw the connection at the time.