The world may not need another Telnet BBS, but I need a PCjr Telnet BBS. So it is coming. ;-0 A telnet BBS running on hardware that was current back in the heyday of the BBS is as authentic as it gets. And when the transition to IPV6 occurs, I'll be ready for that too.
When I add ICMP support I will add a ping command with some diagnostic capability. Besides responding to ping requests it is interesting to see what over traffic (both directed and broadcast) is being received by a specific machine. Initially I didn't think highly of another diagnostic tool that runs under DOS, but anything that makes setup and debugging easier is probably goodness.
This is very hard to do well, which is why it was left to commercial products. If people had used the DOS interrupts for reading the keyboard and writing to the screen it would be easy - hook the DOS interrupts to redirect the input and output and all is good. But very few programs did this. Performance was much faster through BIOS, and even faster with direct video writes.
I don't see much of a need for taking control of a DOS PC remotely anymore.
Here are the other things I'd like to do in the short term:
wiwa64 said:1. Add a broadcast, an echo and perhaps some more diagnostic features to turn it into a tiny tool for testing and debugging TCP/IP nets under DOS. This might not be terribly new, but still usefull and easy to do.
When I add ICMP support I will add a ping command with some diagnostic capability. Besides responding to ping requests it is interesting to see what over traffic (both directed and broadcast) is being received by a specific machine. Initially I didn't think highly of another diagnostic tool that runs under DOS, but anything that makes setup and debugging easier is probably goodness.
wiwa64 said:2. Turn it into a tool that allows to remotly control a DOS box via Telnet. To do this, the program would have to be able to go resident as TSR and hook into the timer interrupt, to regularly watch for incoming data. Any text coming from the remote client would have to be fed into the keyboard buffer and any changement on the screen (or the video buffer),
should be comunicated back to the remote end.
This is very hard to do well, which is why it was left to commercial products. If people had used the DOS interrupts for reading the keyboard and writing to the screen it would be easy - hook the DOS interrupts to redirect the input and output and all is good. But very few programs did this. Performance was much faster through BIOS, and even faster with direct video writes.
I don't see much of a need for taking control of a DOS PC remotely anymore.
Here are the other things I'd like to do in the short term:
- Enhance the test I just ran with some more user friendly features. I think I will use the code to demonstrate the PCjr on it's official 25th anniversary, which is November 1st.
- Create a small Telnet client with ANSI terminal support. NCSA is the 'gold standard', but it is a very big program.
- Create a small FTP client to make moving files easier. (I'm using Netcat to move files now)