MS-DOS Kermit Notes
This page contains some notes on using
MS-DOS Kermit (MS-Kermit for short) to transfer files
between a DOS computer and a modern Windows or Unix computer. Only
IBM-PC compatibles are discussed at this time as that is all I have to
test against, but older versions of MS-DOS kermit are available
for non-IBM platforms such as Act/Apricot and Victor/Sirius.
Kermit is worth considering because:
- It is open source. MS-DOS Kermit, Kermit 95 and C-Kermit are all available under the BSD license.
- Kermit 95 for Windows and OS/2 is actively maintained and available for nearly all 32bit and 64bit Windows and OS/2 releases so no need to get DosBox or other solutions involved.
- C-Kermit for Linux/MacOS/Unix is actively maintained and probably in your linux distributions repositories.
- Only a simple null-modem cable is needed. While a parallel port laplink cable will likely be faster given modern parallel ports, if speed is important then you're probably better off using a network (which Kermit also supports).
- The official implementations are well documented, so while there may be a learning curve it shouldn't be insurmountable.
Using Kermit 95 on Windows or OS/2, or C-Kermit on Linux/MacOS/Unix (or even MS-DOS Kermit on another DOS PC) on the other end is strongly recommended, and not just because I'm the maintainer of Kermit 95. Other Kermit protocol implementations, like the one included with Tera Term, tend to be missing important protocol features such as server mode which only makes things much harder.
For the purposes of transferring files, Kermit 95 and C-Kermit are interchangeable. Kermit 95 is just the Windows and OS/2 port of C-Kermit with a few dozen terminal emulations and an SSH client added. Unless otherwise noted, all Kermit 95 commands here should work on C-Kermit and vice versa.
Contents
- Latest MS-DOS Kermit Versions
- Making a Serial connection
- Making a Network connection
- Transferring files (either one at a time or recursively)
- Other Notes
- Documentation
MS-DOS Kermit Version
There are three releases of MS-DOS Kermit to be aware of. If you can fit it, version 3.16 is probably the way to go. Otherwise, grab either MSK315N.EXE or MSK315L.EXE from 3.15 depending on if you have a network or not. If you want to use MS-DOS Kermits terminal emulator, then you may want to combine a later release with files from 3.14.
| Version | Date | Link | Notes | ||||||||||||||||||||||||||||||
| 3.16 | 4 May 1999 | https://www.columbia.edu/kermit/ftp/archives/msk316.zip | This is the last release (it's called a beta, but is no longer considered one). Adds support for recursively transferring directories. Only available in the full-featured version (256,322 bytes), so you may struggle to fit it alongside MS-DOS on a 360K diskette or run it on PCs with limited memory. | ||||||||||||||||||||||||||||||
| 3.15 | 15 September 1997 | http://www.columbia.edu/kermit/ftp/archives/msk315.zip |
An update to 3.14, this release only contains updated .EXEs and
not all the other files that were included with 3.14. Available in
four variants all of which support transferring files:
|
||||||||||||||||||||||||||||||
| 3.14 | 21 March 1996 | http://www.columbia.edu/kermit/ftp/archives/msk314.zip |
This is the last full release including all the various
ancillary files and documentation for dealing with various
modems, keyboards, etc. None of this stuff is needed if you're
only using it to transfer files via null-modem cable or a
network. It was also available on diskette in the back of
Using MS-DOS Kermit (the contents of the diskette
matches the download archive). Available in three variants
all of which support transferring files
|
||||||||||||||||||||||||||||||
Setting up a Serial connection
This is the easiest and also the slowest option. Connect the two PCs with a good quality null-modem cable, and give Kermit on both computers something like the following commands:
set port com1
set speed 28800
set flow rts
On Kermit 95 and C-Kermit, you'll also have to give the set carrier-watch off command (Kermit 95/C-Kermit will remind you if you don't).
You can of course use higher or lower speeds than 28800 if your hardware can handle it. On my Turbo XT, 28800 is reliable and going faster doesn't provide any additional performance.
Using RTS/CTS flow control is important if there is a large difference in speed between the two computers to prevent the slower computer from being overwhelmed. Software flow control (XON/XOFF) may also work but is unlikely to be as reliable.
Setting up a Network connection
If you have a NIC, using that will provide much better performance and reliability than a null modem cable. While using other solutions like mTCP FTP may provide better performance over a LAN, using Kermit is still a reasonable option.
MS-DOS Kermits network features are discussed in chapter 16 of Using MS-DOS Kermit, page 195.
Getting MS-DOS Kermit on the Network
On the DOS PC, you'll need to load a packet driver for your network card before starting Kermit. Once you're in MS-DOS Kermit, you can use commands like the following to configure a static IP:
set tcp address 10.0.1.142
set tcp subnet 255.255.255.0
If you'd rather use DHCP, that is also possible as of MS-Kermit 3.15. To use DHCP, the command is set tcp address dhcp but note that DHCP doesn't actually happen until you take some action that requires the network (such as entering server mode or the terminal emulator). To find out the network address received from DHCP, you'll then need to escape back to the MS-DOS Kermit prompt and issue the show communications command.
Accepting incoming TCP/IP connections
To have Kermit accept incoming connections from another Kermit instance on the network, run:
| Kermit 95 C-Kermit |
MS-DOS Kermit |
| set host * 23 | set port tcp * |
On MS-DOS Kermit, you must also either enter server mode with the server command, or begin terminal emulation with the connect command to begin listening.
Making TCP/IP connections
To connect to another Kermit instance over a TCP/IP network, run the following command:
| Kermit 95 C-Kermit |
MS-DOS Kermit |
| set host /nowait 10.0.1.115 | set port tcp 10.0.1.115 |
As with listening for incoming connections, MS-DOS Kermit won't actually make the connection until you do something that requires it; enter terminal emulation, enter server mode, or execute a remote command such as remote space. The remote command won't actually complete unless you put the other computer into server mode once the connection is established.
Transferring Files
With the two computers connected via either serial or network, you can now begin to transfer files.
By default, Kermit want to convert any files it recognises as being text from the sending computers character set to the receiving computers character set. If you'd rather files transferred verbatim, give both ends the command:
set file type binary
In Kermit 95 and C-Kermit, you can also set where received files should go with the set file download-directory. If you run the command with no arguments, received files will be saved to your current directory (which you can change with the cd command). Otherwise, you can specify the location like below. MS-DOS Kermit always saves received files to your current directory.
set file download-directory C:\temp\backup
With that out of the way, you can tell one computer to:
send C:\autoexec.bat
and the other computer to:
receive
(you may not have to issue the receive command on the receiving computer depending on auto-download settings, etc).
Server Mode
If you're going to be sending more than one file, or would rather just work at one computer rather than switching between the two, you can use Kermits server mode.
If you place one of the Kermit instances into Server Mode, you can then do all of your work from the other Kermit instance. You can use the remote commands (such as remote cd, remote mkdir, etc) to navigate the filesystem of the other computer getting and sending files as you like.
To put Kermit into server mode, give it the server command. To exit out of server mode, press Ctrl-C. For example, on the MS-DOS PC we only need to run these commands for a serial connection:
C:\KERMIT> msk316
MS-Kermit> set port com1
MS-Kermit> set speed 28800
MS-Kermit> set flow rts
MS-Kermit> set file type binary
MS-Kermit> server
(MS-Kermit shows the server mode screen)
And then we can do everything else from Kermit 95 on the modern Windows PC computer:
K-95> set port com1
K-95> set speed 28800
K-95> set flow rts
K-95> set carrier-watch off
K-95> set file type binary
K-95> set file download-directory C:\temp
K-95> cd \v(home)Downloads
K-95> pwd
Long name: C:/Users/david/downloads/
Short name: C:/Users/david/DOWNLO~1/
K-95> remote pwd
C:\KERMIT
K-95> remote cd
C:\
K-95> remote space
325632 bytes available on drive C
K-95> get autoexec.bat
(The file transfer screen appears as the file downloads to C:\temp\autoexec.bat)
K-95> send smc_wd.com
(The file transfer screen appears as C:\Users\david\downloads\smc_wd.com uploads)
K-95> bye
(MS-Kermit exits to MS-DOS)
Transferring files, recursively!
If you want to transfer entire directory trees in one go, you'll want to use the recursive option and ensure folder names are preserved rather than having all files dumped in your current directory or download directory. This requires MS-DOS Kermit 3.16 and server mode.
To ensure pathnames are preserved, you need to give MS-DOS Kermit the set send pathnames relative command (Kermit 95 and C-Kermit switch this on automatically when a recursive transfer starts). If MS-DOS Kermit is in server mode, and you're not sitting at the DOS PC, you can give Kermit 95 or C-Kermit the command:
remote kermit set send pathnames relative
This will transmit the command set send pathnames relative to the remote computer and have it executed so you don't have go and use the other keyboard!
You can then do something like the following to backup the entire C drive on the MS-DOS PC:
K-95> set file download-directory C:\temp\backup
K-95> remote cd C:\
C:\
K-95> get /recursive *
(All files and folders in C:\ on the remote PC are saved under
C:\temp\backup on your local PC)
The reverse also works - if you want to send a folder from one computer to another, the send command also has a /recursive option.
Transferring files, recursively, with old versions of MS-DOS Kermit
MS-DOS Kermit versions prior to 3.16 lack support for recursively sending and receiving directories. To achieve this, the MS-DOS Kermit 3.14 distribution includes a utility called XSEND.EXE in the UTILS directory for generating kermit scripts to do the job.
To generate the script, on the DOS PC run the following (note the lack of a space between the '-k' and the 'C:\'):
xsend -kC:\ > backup.ksc
This will generate a script in the current directory called backup.ksc containing the necessary commands to transmit all files under C:\ creating and switching directories along the way as necessary.
This utility is very old (~march 1991) and the resulting scripts don't really work well with modern versions of Kermit 95 or at all with C-Kermit. Perhaps I or someone else will update it eventually if there is interest/demand, but in the meantime it can be made to work!
The generated script uses the remote host command to create directories via the windows shell. This is slow (a console window will pop up on the computer running Kermit 95 each time this command is run) and disabled by default for security reasons.
So you have two options: Either replace all occurrences of remote host mkdir in the generated script with remote mkdir, or enable processing the remote host command in Kermit 95 with: enable host local.
Once you've made the changes so that the script can create directories, you can run it from MS-DOS kermit with the take command:
take backup.ksc
A version of this utility, as XSEND32.EXE, was also included with old versions of Kermit 95 but as those were commercial software and not freely distributable XSEND32.EXE is not available online.
Source code for XSEND.EXE, and presumably what XSEND32.EXE was based on, is available if needed (and the readme file).
Other Notes
- If you're transferring files over a network, you can give streaming mode a go. This may provide better performance over reliable connections. You can turn it on in MS-DOS Kermit 3.16 with set streaming on
- If you only want to send files that have changed since last time, use set file collision update (the default is to rename).
- If you find yourself running certain commands every time you start MS-DOS Kermit, you can place them in a file called MSKERMIT.INI alongside the MS-Kermit executable. Or you can grab the MSKERMIT.INI and MSCUSTOM.INI from the Kermit 3.14 distribution, and add your customisations to MSCUSTOM.INI. Seem Chapter 14 of Using MS-DOS Kermit for more information.
- If you want Kermit file transfers to go faster, there are some protocol settings you may be able to adjust. By default, the protocol is configured to prioritise reliability over speed, so on a reliable connection you may be able to get a bit more speed out of it. There are some notes here, but it may involve a bit of trial and error to see what works for your hardware and connection.
Documentation
MS-DOS Kermit has an excellent users guide titled Using MS-DOS Kermit which is well worth keeping handy:
- PDF version - no table of contents or images
- Paperback version on Amazon - if you get lucky, it may even have MS-DOS kermit on a floppy disk!
C-Kermit is documented by Using C-Kermit along with a series of supplements. Also well worth keeping handy:
- 2nd Edition PDF - Cover page and table of contents
- 2nd Edition PDF - content
- 2nd Edition Paperback version on Amazon
- 3rd Edition draft, partially updated for C-Kermit 8.0
- C-Kermit 7.0 Manual supplement
- C-Kermit 8.0 Manual Supplement
- C-Kermit 9.0 Manual Supplement
- Index to the "Using C-Kermit" PDF + supplements
Kermit 95 is based on C-Kermit and as such most of its commands are covered by the C-Kermit documentation above. Kermit 95-specific details are covered separately in its users guide:
Feedback
If you've got any questions, corrections or suggestsions for this page, either ping me (davidrg) on the vcfed forum, start a discussion on the Kermit 95 github page, or flick me an email (david at this websites domain name without the www bit).