I haven't used MS-DOS Kermit, but having a quick look at the manual connecting will involve something like the following:

1set tcp address 192.168.0.42
2set tcp subnet 255.255.255.0
3set tcp primary-nameserver 192.168.0.1
4set tcp gateway 192.168.0.1
5
6set term type Ansi-bbs
7set port tcp bbs.example.com
8connect

MS-DOS Kermit has its own built-in TCP/IP stack which you've got to configure and have a packet or ODI driver loaded for it to use. And I assume you'll need to ensure no other TCP/IP stack (like the windows one) is currently loaded. To save having to enter all that config every time, you can put those commands in MSKERMIT.INI and they'll run every time you start kermit.

To get a list of all available terminal types, enter: set term type ? - in C-Kermit and MS-DOS Kermit, the ? character gives you a list of valid options at that point in whatever command you're typing. You can also abbreviate commands "set ter ty a" instead of "set terminal type Ansi-BBS" - you only need to type enough characters to not be ambiguous.

Once connected, you can hit Alt-x to switch between terminal emulation and the command screen. So to quit you'd hit Alt-x to switch to the command screen, then run the exit command.

Perhaps worth noting just in case someone thinks of trying it, MS-DOS Kermit won't work properly under 32bit windows - for that there is this: https://github.com/davidrg/ckwin/ (windows 95+, NT 3.50+, screenshots)

I think everybody is making this too complicated.

The BBS server and the client need to agree on the following:

• Code page: 437 was used for the original PCs, later machines had more options due to changes in EGA and VGA
• Encoding: Older machines assumed 7 or 8 bit characters. UTF-8 can use more bits to express far more characters.
• Telnet vs. Raw: Telnet is a protocol and it has options such as echoing, line mode, etc. A true "telnet" server or BBS expects it's clients to adhere to the protocol. An older system that was designed for modems that is hiding behind something newer that provides TCP/IP sockets is probably not speaking the Telnet protocol, or the thing in the middle is and is hiding it from the older system.
• Carriage returns and new lines. The Telnet protocol is pretty clear about this - a new line is a CR LF combination. Which is the same as it is on DOS, but not on Unix or other systems. A terminal emulator needs to be flexible and let you choose to match the server.
• Cursor movement, color, screen clearing, etc: These are all properties of the terminal type you are choosing to emulate. The server and client have to agree on the terminal type.

mTCP Telnet works from DOS because it does both the real Telnet protocol or "raw" connections, and that can be forced/selected on the command line. It assumes CP437 but it also can be told how to send and receive the UTF-8 encoding for Unicode, and it does some limited character mapping to make Unicode usable. It lets you select your new line sequence, and it emulates a simple "ANSI" or "PC ANSI" style terminal.

Just find something in Windows that can handle that, or a server that lets you turn those features on and off as needed. Once you get to a TCP/IP socket nothing is really going to want to mess with the data stream because that is too much work.

I tested with PCEM V16/MS-DOS 6.22/Mtcp telnet. The same BBS that produced garbled graphics in Telix 1.15d for Windows/Procomm Plus for Windows 3 worked perfectly. This BBS has all kinds of ANSI graphics and animations.

At least this rules out that PCEM was causing the problem. Windows for Workgroups TCP stack? I have yet to log on to a telnet server that lets me select which code page I'm using, most auto detect terminal type by having you press a key on the keyboard.

But please, anyone else that wants to do some of their own testing feel free to contribute.

If there is an option to set the system or terminal type from the BBS, use that instead. There is no telling what the auto-negotiate is trying to do.

One difference between telnet and an old school phone BBS is that telnet may pass a $TERM environment variable to the server, so that could be part of what makes things go awry when they didn't in old times

Older terminals (VT100) would respond to a Ctrl-E with a string that identified the terminal and gave some status. Early systems could have used that mechanism but it's quite obsolete now.

Success!

I hit all the search engines and came up empty. Silly me, I should have just asked at the one place that could provide help with this subject - a BBS!

I applied the following settings in Procomm Plus 3 for Windows 3.1 and now the BBS works perfectly, including all the ANSI art and animations.

So the answer is yes, you can use Windows 3.1/Windows for Workgroups to connect to telnet ANSI BBSes with Procomm Plus 2/3 for Windows. Nothing to do with codepages or DOS/Windows 3.1, it's all on whatever limitations the terminal program you're using.

I managed the same thing with using Telix for windows with winsock and a packet driver, but for the life of me I can't register it (since the company is gone). I have the shareware version 1.15D and besides the time limit, hiding the macro bar is disabled, which is super annoying.

Does anyone have the retail version 1.15D they could share? This version is important because previous versions didn't have telnet.