Category : C Source Code
Archive   : WKERMSRC.ZIP

Output of file : PCKERMIT.DOC contained in archive : WKERMSRC.ZIP

PC-DOS Kermit with Sliding Windows Rev 1.18
---------------------------------- 12/10/85

1. Source Code Implementation Documentation

By Larry Jordan and Jan van der Eijk
Revised by John Mulligan

The Kermit software modules contained in this package are
modified versions of the C-KERMIT 4C modules distributed by
Columbia University in June, 1985. The modules were modified to
work with the Lattice C compiler and The Greenleaf Functions to
produce Kermit software compatible with PC-DOS and MS-DOS. They
were also modified to add two new features to the software--file
attributes and sliding windows. File attributes have been in the
official Kermit Protocol specification for some time, but the
sliding windows concept has just been approved.

The 4C version of Kermit was chosen because it was written
for maximum portability to different operating systems, and it
was the most robust version available. The 4C version was
written for Unix and Xenix operating systems, but the
similarities with PC-DOS made it relatively easy to port to that
system. The 4C version contained all defined Kermit capabilities
except file attributes. None of these capabilities were removed
during our port of 4C to PC-DOS. Some functions had to be
rewritten for PC-DOS compatibility such as filename conventions
and wildcard filename expansion. Server support and non-protocol
related code, such as terminal emulation, was removed from 4C
during the port to reduce the size and complexity of the PC-DOS
Kermit module.

The Lattice C compiler was chosen because of its
compatibility with Unix C and because of the quality of code it
produces. The Microsoft C Version 3.0 would be a better choice
now because of its superior error-checking and Unix
compatibility; it was not available when we started the 4C port.
The function calls are compatible with Lattice C Version 2.15.
The modules could be compiled under Microsoft C 3.0 with few
changes. Microsoft provides the Lattice-to-Microsoft transition
header files.

[NOTE: Their is a reported bug in the Microsoft C Compiler which causes an
error in the Kermit Type 3 (CRC-16) Checksum algorithm. Beware!]

[NOTE: Lattice C allows nested comments, which are not allowed by Microsoft
C compiler. Their may be some instances of nested comments. LCKFNS3
has at least one area that was commented out that results in a nested

The Greenleaf Functions General and COMM Libraries were
chosen for file and communications I/O because the functions
provide all the necessary capabilities. The functions are
modestly priced and include source code. All uses of these
functions are noted in comments in the source code. A software
vendor can substitute another vendor's functions in place of The
Greenleaf Functions or use functions generated inhouse.

Unlike most communications software software and protocols,
Kermit does check parity if parity is enabled, and the protocol
will not function properly unless the selected parity matches on
both ends of the communications link.

Implementation of PCKermit

The PC-DOS Kermit provided in this package can be
implemented in one of two ways. A stand-alone version of the
software can be executed from the DOS command line or through a
software SYSTEM, FORK or SHELL call. A linkable version of the
software can be linked to smart terminal object modules and the
protocol executed from within the smart terminal program. The
linkable version can also be added to host or bulletin board
software. The software for both options is provided in the

Stand-Alone Kermit

A stand-alone version of the PC-DOS Kermit is included in
this package. The file is called PCKERMIT.EXE. This file was
created by linking the LCKMAIN.OBJ module to the other Kermit
modules. Execution of the stand-alone Kermit program requires
the same command parameters and carrier conditions regardless of
the execution method. The module runs as a "one-shot" execution
then returns to the caller. A single file or multiple files
(wildcard filename) are transferred until execution is completed
or the transfer is abnormally aborted. If execution is performed
by the user from the DOS command line, termination of PCKERMIT
returns control to PC-DOS. If execution is performed from within
a software package using a SYSTEM, FORK or SHELL call,
termination of PCKERMIT returns control to the next executable
statement after the calling statement.

The command syntax of the stand-alone Kermit program is
shown in Figure 1. An example of execution from the DOS command
line is as follows:

PCKERMIT -l COM1 -b 1200 -p n -m 8 -w -r

This same Kermit execution can be started from within a
Lattice C program with the following function call:

system(" PCKERMIT -l COM1 -b 1200 -p n -m 8 -w -r");

Both methods allow you to receive a file through serial port
COM1 at 1200 bps using no parity. They also request an 8 packet
sliding window from the sender and allow overwriting of
existing files. CRC-16 error-checking is automatically requested.
If sliding windows are not supported by the sending computer,
PCKERMIT reverts to "classic" half-duplex Kermit operation. If
the sender cannot support CRC-16 the next best common error-check
technique is negotiated.



PCKERMIT version 1.17, December 6, 1985
Usage: PCKERMIT [-x arg [-x arg]...[-yyy]..]]
x is an option that requires an argument, y an option with no argument:
-s file(s) send
-r receive
-a name alternate name, used with -s, -r
-h help - print this message
settings -- default
-l line communication line device ( COM1, COM2 ) [COM1]
-b baud line speed, e.g. 1200 [1200]
-p x parity, x is one of e,o,m,s,n [N]
-m size maximum window size to use ( <= 31 ) [31]
-n non binary file transfer, affect CR/LF
-t line turnaround handshake = xon, half duplex
-w write over preexisting files
-q be quiet during file transfer
-c carrier detect signal required to be present

Note 1: Use -d (debug) only if compiled with debug statements left in
place. (hidden option)

Note 2: If -t is used, -m should not be used.

Note 3: The usage of -w is reversed from standard Columbia CKERMIT.

Figure 1. PCKERMIT command syntax.


Regardless of the technique used to initiate operation of
the stand-alone Kermit program, the software requires the same
serial port and modem conditions. The Kermit module sets up its
own send and receive interupt buffers, but it does not establish a
carrier with a remote system. The user must initialize a
selected serial port with bit rate, parity, and stop bits then
establish a carrier with a remote host based on these parameters.
After the carrier is established and the remote Kermit is
started, the user can start the local stand-alone Kermit.

Linkable PC-DOS Kermit

The PC-DOS Kermit modules can be easily linked to existing
smart terminal or host software written in the C language.
Linking the modules to Pascal, compiled BASIC or assembly
language requires a thorough knowledge of both C and the terminal
or host program language. Before the linking is performed some
software changes have to be made.

The special link module is the LCKLINK.C file. This module
contains several local and global variables that must be
initialized. The variables can be initialized by reference to
parameters selected or established in the smart terminal program
or they can be hard coded for specific applications. All
variables that must be initialized are shown equal to question
marks. For example, the parity variable is shown as parity=????.
It should be noted that the LCKCLINK.C module replaces the
LCKMAIN.C module used to create the stand-alone PCKERMIT.

Another required change to facilitate direct link of Kermit
to other software is in the module LCKUSER.C. The function
"doexit()" must be modified to return to the smart terminal
program rather than exit to DOS. Specifically, the "exit();"
statement must be changed to a "return;" statement.

An existing smart terminal program should already contain
functions or procedures to set up communication buffers and to
initialize communication ports. A new software product may not
have these functions established. In any event, the LCKTIO.C
module must be modified to match the existing smart terminal
communication functions. The "ttopen()", "ttclose()" and
"ttvt()" functions should be studied, and the noted Greenleaf
communication functions modified as necessary. Existing
functions may be used to replace these functions. Code comments
and Greenleaf documentation should be studied before these
routines are modified--the sequence of the function calls in
these functions are sometimes critical to interupt buffer setup
and operation. A change in the sequence can either cause buffer
setup problems or cause the interupt sending or receiving of
characters to malfunction.

Finally, screen I/O performed by PC-DOS Kermit is done in
the LCKUSER.C module. A smart terminal vendor will probably want
to change the TTY style output to a special file transfer screen
format. All screen I/O are contained in the screen function.
The vendor can use display functions from a third party (i.e.,
Greenleaf or Blaise) or use functions written by the vendor to
perform fast, full screen color output. DOS or BIOS calls can be
used without slowing down the protocol as long as the calls do
not have to scroll the screen or produce elaborate I/O.

All PCKERMIT object files contained in this package were
compiled using the Lattice C small model. This model uses NEAR
calls in its code segment. If the PCKERMIT files are to be
linked to software compiled under other Lattice models, the C
source code must be recompiled using the selected model.

Files for PCKERMIT
[The LCK*.C naming convention stands for "Lattice C Kermit" files]

Filename | Description
LCKFIO C /* File I/O module */
LCKFNS1 C /* Protocol specific module 1 */
LCKFNS2 C /* Protocol specific module 2 */
LCKFNS3 C /* Windowing specific module */
LCKLINK C /* Module for linkable Kermit */
LCKMAIN C /* Main program for PCKERMIT */
LCKPROT W /* Protocol state table in Wart */
LCKPROT C /* Protocol state table in C */
LCKTIO C /* RS232 I/O and time module */
LCKUSER C /* User interface module */
LCKCMD H /* Command interface header */
LCKDEB H /* Debug header file */
LCKERM H /* PCKERMIT main header file */
LCKUSR H /* User interface header file */
STDIOS H /* Lattice and Greenleaf stdio.h */
PCKERMIT MAP /* Map file */
LCKWART C /* Wart source code */
LCKWART EXE /* Wart EXE file */
LCKWART DOC /* Wart documentation */

Referenced Products

The Greenleaf Functions

Greenleaf Software Inc.
2101 Hickory Drive
Carrollton, TX 75006
(214) 446-8641

Lattice C. Compiler

P.O. Box 3148
Glen Ellyn, IL 60138
(312) 858-7950

Microsoft C. Compiler

10700 Northup Way
Bellevue, WA 98004

Asynch Manager

Blaise Computing Inc.
2034 Blake Street
Berkley, CA 94704
(415) 540-5441


The following material supplements the section "Stand-Alone Kermit" (above):


During operation of the standalone PCKERMIT it
may display the following:

% Resend of last packet
. Is printed every FOURTH data paã­¢j5I
$HA tttributes packet (file length and creation date)
B End of transmission packet
F File Header
N NAK packet
Q Bad checksum or other packet error
S Send-Init packet
T Timeout
Z End of file packet


During a file transfer PCKERMIT responds (sometimes slowly) to
the following keystrokes:

CTRL-F to cancel File, CTRL-R to Resend current packet .
CTRL-B to cancel Batch, CTRL-K to abort Kermit and exit
CTRL-A for status report:

These functions are available even at the start of PCKERMIT before it
tells you they are available. In particular, Control-K can be used if
the "Send-Init" exchange does not seem to be working.

Please note that PCKERMIT checks the keyboard infrequently under some
conditions. WAIT at least 20 - 30 seconds before repeating a keystroke
in order to avoid stacking up repeated commands. This is particularly true
of CTRL-F (cancel file) where you might cancel more than one file.

Also, the Control-F and Control-B (cancel file and cancel batch) functions
sometimes require a NAK and a resend or a timeout before they actually
work. This is not a protocol problem, but is due to the way PCKERMIT
flushes it buffer before sending the abort packet. In some cases, the
flushing of the buffer truncates a packet and the following abort packet is
not seen as a separate packet.

Here is a more detailed explanation of the functions:

CTRL-F will cancel an individual file in a wildcard transaction,
but then continue with the next file in the batch.

CTRL-B will cancel the entire batch of files, according to
protocol, and then return you to the DOS prompt.

CTRL-K will abort the file transfer and return you to the DOS
prompt. PCKERMIT sends an Error packet indicating it is
aborting, but otherwise does not worry about protocol.

CTRL-R will resend the current packet; this can be used as a
manual timeout. With windowing is in effect, this feature should be
tried only as a last resort as it has not been fully tested.

CTRL-A will give you a status report on the screen. The items
covere are:

^A Status report:
file type: binary ;Details unknown

file number: 1 ;Indicates which file of a multiple file
wildcard batch transfer

characters : 1291 ;On SEND: indicates number of characters
output to the buffer, but not necessarily
yet sent out the modem.

On RECEIVE: indicates characters actually
written to disk so far; others may already
have been received to memory.

window size: 31 ;The window size agreed upon after negotiation
with the other Kermit. By definition, 0 means
Classic (non-windowing) Kermit. Otherwise,
the size may vary from 1 to 31.

block check: 1 ;The block check type agreed upon after
negotiation with the other Kermit.
Type 1 = 1 byte checksum
Type 2 = 2 byte checksum
Type 3 = 3 byte CRC-16 checksum

compression: 0 ;Is data compression (repeat count prefixing)
in effect?
0 = No compression
1 = Compression

8th-bit prefixing: 1 ;Is 8th bit prefixing being used?
0 = No
1 = Yes

FUNCTIONS SUPPORTED BY PCKERMIT (Subject to agreement by the other Kermit)

Windowing (full-duplex chanell required)
Data Compression
8-bit quoting (whenever parity is not "none")
File Attributes:
File Length
On Receive: accepts either
the attribute ! (Ascii 33) - Approximate File Length in K bytes
the attribute 1 (Ascii 49) - Exact file length

On Send:
sends the attribute 1 (Ascii 49) - Exact File Length

Time and Date:
Both Receive and Send
the attribute # (Ascii 35) - Creation date

NOTE: when PCKERMIT receives the creation date file attribute, it
automatically writes the received file with that date, rather than
the current date.


Local operation: Yes
Remote operation: ???
Transfers text files: Yes
Transfers binary files: Yes
Wildcard send: Yes
^X/^Y interruption: Yes (Different keystrokes, though)
Filename collision avoidance: Yes
Can time out: Yes
8th-bit prefixing: Yes
Repeat count prefixing: Yes
Alternate block checks: Yes
Terminal emulation: No
Communication settings: Yes
Transmit BREAK: No
IBM mainframe communication: ???
Transaction logging: No
Session logging: No
Raw transmit: No
Act as server: No
Talk to server: No
Advanced server functions: No
Advanced commands for servers: NO
Local file management: ???
Handle file attributes: Yes
Command/init files: No
Command macros: No

The exact file size attribute is not covered in the Fifth
Edition of the KERMIT PROTOCOL MANUAL. This is an addendum to
that manual from Frank da Cruz, who maintains the Kermit

"Date: Fri 2 Aug 85
From: Frank da Cruz
Subject: attribute packets

I was just looking at the protocol manual and realized that the current edition
does not contain something which might be useful to you, namely two new
attribute fields: "1" specifies the exact byte count of the file, and "2"
specifies the byte size (e.g. "7" or "8"). This will be in the next edition.
Many people have asked for a somewhat finer-grained way to report the file
size than the number of K (e.g. some systems need to preallocate space, but in
some unit other than K). - Frank"


The following information supplements the "1. Source Code Implmentation
Documentation" section above:


The module LCKPROT.C is produced by putting LCKPROT.W through the
LCKWART.EXE pre-preprocessor.

The utility LCKWART.EXE was produced by compiling LCKWART.C, using the
for Lattice C) Link automatic response file LCKWART.ARF.

The documentatiion for WART is LCKWART.DOC.

To summarize:
LCKPROT.C What we needed; WART was required only to
produce this file.


This is a small batch file that will compile a .C module into a .OBJ module.
Messages/Errors are sent to a .ERR file.

The LC1 and LC2 are the compiler modules supplied by LATTICE C.

Here is the batch file, with comments to the right:

lc1 >%1.err %1 -mS -b ;LC1 is the first phase of the Lattice C Compiler
;>%1 Messages/Errors are logged to filename.ERR
;%1 is the file being compiled
;-mS indicates the Small memory model
;-b indicates "force byte alignment"

type %1.err ;type out the .ERR file
lc2 %1 ;LC2 is the second phase of the Lattice C Compiler
;It's input is the .Q file produced by LC1
;It's output is a .OBJ file to later be linked.

Note that the small memory model (-mS) is being used; therfore, when linking
later on use the CS.OBJ module and the LCMS.LIB and LCS.LIB library modules,
which are the corresponding Small modules.


The following is the contents of the PCKERMIT.ARF file, which is an
automatic response file for the LINK procedure. (This is for the LINKer
supplied with MS-DOS 3.0) I have annotated on the right what each
line/module does:

cs+ -LATTICE C OBJECT MODULE (Supplied by Lattice)
lckmain+ -MAIN PROGRAM
lckfns3+ -PROTOCOL FUNCTIONS 3 (Windowing specific)
lckfio+ -FILE I/O
lcktio -TERMINAL I/O
pckermit -.EXE file
pckermit -.MAP file
gfts+gfs+gfcs+ -GREENLEAF LIBRARIES (Supplied by Greenleaf)
lcms+lcs -LATTICE C LIBRARIES (Supplied by Lattice)

NOTE: The Greenleaf functions are available from:

Greenleaf Software Inc.
2101 Hickory Drive
Carrollton, TX 75006
(214) 446-8641

NOTE: Lattice C is available from:

Lattice, Inc. OR from Lifeboat Assoc.
P.O. Box 3148 1651 Third Avenue
Glen Ellyn, IL 60138 New York, N.Y. 10028
(312) 858-7950 (212) 860-0300


The development of this software was done using the following:

Lattice C (ver. 2.15)
Greenleaf Functions General Library Rev. L2-2.10
Greenleaf Functions Communications Library Rev. L3-1.2
MS-DOS 3.0 on an IBM/PC AT
The Microsoft Linker supplied with MS-DOS 3.0


Here is a sample directory of files for version 1.17 of PCKERMIT.EXE:

LCKWART ARF 43 8-14-85 3:11p
PCKERMIT ARF 133 11-26-85 3:24p
COMPILE BAT 46 7-27-85 3:41p
PCKCOMP BAT 513 8-26-85 4:32p
PCKLINK BAT 21 11-26-85 3:30p
LCKFIO C 16159 12-06-85 12:01p
LCKFNS1 C 28939 12-03-85 6:37p
LCKFNS2 C 12347 8-06-85 10:04p
LCKFNS3 C 11025 11-13-85 6:07p
LCKLINK C 9806 11-16-85 12:21p
LCKMAIN C 8064 10-31-85 4:35p
LCKPROT C 14153 11-09-85 7:50p
LCKTIO C 15302 11-06-85 9:45p
LCKUSER C 22935 12-06-85 12:05p
LCKWART C 13151 7-30-85 11:11a
KWCHANGE DOC 4190 12-05-85 1:43p
KWINDOW5 DOC 28020 12-05-85 1:20p
LCKWART DOC 4119 6-05-85 5:06p
PCKERMIT DOC 37691 12-06-85 2:30p
LCKFIO ERR 70 12-06-85 3:17p
LCKFNS1 ERR 128 12-06-85 3:14p
LCKFNS2 ERR 128 12-06-85 3:15p
LCKFNS3 ERR 70 12-06-85 3:15p
LCKMAIN ERR 283 12-06-85 3:13p
LCKPROT ERR 70 12-06-85 3:13p
LCKTIO ERR 70 12-06-85 3:18p
LCKUSER ERR 70 12-06-85 3:16p
LC1 EXE 68736 5-02-85 4:49p
LC2 EXE 70592 5-02-85 4:49p
LCKWART EXE 31996 8-14-85 3:11p
PCKERMIT EXE 70236 12-06-85 3:19p
ASIC H 9012 10-16-85 9:59p
ASIPORTS H 12017 10-16-85 9:03p
CDISK H 4112 11-10-84 12:00p
CSTDIO H 2139 7-27-85 3:44p
CTYPE H 2198 5-02-85 4:49p
FCNTL H 896 5-02-85 4:49p
LCKCMD H 1625 7-29-85 4:17p
LCKDEB H 2643 7-30-85 11:00a
LCKERM H 3610 10-26-85 3:39p
LCKUSR H 4460 7-30-85 11:00a
STDIOS H 2031 7-27-85 3:38p
TIMEDATE H 553 8-17-84 12:00a
GFCS LIB 21504 4-26-85 4:54p
GFS LIB 60416 11-10-84 12:00p
GFTS LIB 9216 11-10-84 12:00p
LCMS LIB 68096 5-02-85 4:50p
LCS LIB 78848 5-02-85 4:50p
PCKERMIT MAP 25696 12-06-85 3:19p
CS OBJ 1675 5-02-85 4:50p
LCKFIO OBJ 6605 12-06-85 3:17p
LCKFNS1 OBJ 12381 12-06-85 3:15p
LCKFNS2 OBJ 5598 12-06-85 3:15p
LCKFNS3 OBJ 5046 12-06-85 3:16p
LCKMAIN OBJ 3035 12-06-85 3:13p
LCKPROT OBJ 7611 12-06-85 3:13p
LCKTIO OBJ 6472 12-06-85 3:18p
LCKUSER OBJ 11453 12-06-85 3:16p
PCKERMIT UPD 584 12-06-85 12:14p
LCKPROT W 6962 11-06-85 8:24p


LCKWART ARF LINK Automatic Response File to create LCKWART pre-processor
PCKERMIT ARF LINK Automatic Response File to create PCKERMIT.EXE
COMPILE BAT COMPILE batch file for Lattice C and LCK?????.C modules
PCKCOMP BAT PCKermit COMPile all modules batch file
PCKLINK BAT PCKermit LINK batch file used with PCKERMIT.ARF
LCKFIO C File I/O module
LCKFNS1 C Kermit Protocol Specific Module #1
LCKFNS2 C Kermit Protocol Specific Module #2
LCKFNS3 C Kermit Windowing Specific Module
LCKLINK C Module for linkable Kermit used in place of LCKMAIN.C
LCKMAIN C Main program for PCKERMIT
LCKPROT C Protocol State table in C (derived from LCKPROT.W)
LCKTIO C RS232 I/O and time module
LCKUSER C User interface module
LCKWART C Source code for LCKWART.EXE preprocessor used on *.W files
KWCHANGE DOC Kermit Windowing - Changes to definition draft to draft
KWINDOW5 DOC Kermit WINDOWing Definition - Add to Protocol Manual
LCKWART DOC LCKWART (WART preproccesor for *.W files) documenation
PCKERMIT DOC PCKERMIT Sliding Window Kermit Documentation
LC1 EXE Lattice C 1st phase
LC2 EXE Lattice C 2nd phase
LCKWART EXE WART pre-processor: *.W files input *.C files output
PCKERMIT EXE PCKERMIT Sliding Window Executable code
ASIC H "include for things that use asi buffer structure"
ASIPORTS H Greenleaf Comm Library Header for Asynch I/O ports
CDISK H Greenleaf Header
CSTDIO H "I/O for Lattice and Microsoft C and The Greenleaf Functions"
CTYPE H "defines various ASCII character manipulation macros"
FCNTL H "symbols used for "open, "creat", and "fcntl" functions"
LCKCMD H Command interface header
LCKDEB H Debug header file
LCKERM H PCKERMIT main header file
LCKUSR H User interface header file
STDIOS H Combination of Lattice C and Greenleaf Headers
TIMEDATE H Greenleaf Header
GFCS LIB Greenleaf Library
GFS LIB Greenleaf Library
GFTS LIB Greenleaf Library
LCMS LIB Lattice C v. 2.15 Library
LCS LIB Lattice C Library
CS OBJ CS.OBJ file supplied with Lattice C - Small model
PCKERMIT UPD PCKERMIT UPDate list of changes version to version
LCKPROT W PROTOCOL State Table in WART pre-proccesor form.


Columbia University maintains the Kermit protocol. The
following is taken from their file COMMER.DOC, which describes
Columbia University's policy regarding commerical use of Kermit:


Frank da Cruz

Columbia University Center for Computing Activities

June 1984

The KERMIT file transfer protocol has always been open, available, and free to
all. The protocol was developed at the Columbia University Center for
Computing Activities, as were the first several KERMIT programs. Columbia has
shared these programs freely with the worldwide computing community since 1981,
and as a result many individuals and institutions have contributed their own
improvements or new implementations in the same spirit. In this manner, the
number of different systems supporting KERMIT implementations has grown from
three to about sixty in less than three years. If Columbia had elected to keep
the protocol secret, to restrict access to source code, or to license the
software, the protocol would never have spread to cover so many systems, nor
would the programs be in use at so many sites, nor would the quality of many of
the implemementations be so high.

Although KERMIT is free and available to anyone who requests it, it is not in
the "public domain". The protocol, the manuals, the Columbia implementations,
and many of the contributed implementations bear copyright notices dated 1981
or later, and include a legend like

Permission is granted to any individual or institution to copy or use
this document and the programs described in it, except for explicitly
commercial purposes.

This copyright notice is to protect KERMIT, Columbia University, and the
various contributors from having their work usurped by others and sold as a
product. In addition, the covering letter which we include with a KERMIT tape
states that KERMIT can be passed along to others; "we ask only that profit not
be your goal, credit be given where it is due, and that new material be sent
back to us so that we can maintain a definitive and comprehensive set of KERMIT

Within this framework, it is acceptable to charge a reproduction fee when
supplying KERMIT to others. The reproduction fee may be designed to recover
costs of media, packaging, printing, shipping, order processing, or any
computer use required for reproduction. The fee should not reflect any program
or documentation development effort, and it should be be independent of how
many implementations of KERMIT appear on the medium or where they came from.
It should not be viewed as a license fee. For instance, when Columbia ships a
KERMIT tape, there is a $100.00 reproduction fee which includes a 2400' reel of
magnetic tape, two printed manuals, various flyers, a box, and postage; there
is an additional $100.00 order processing charge if an invoice must be sent.
The tape includes all known versions of KERMIT, including sources and

Commercial institutions may make unlimited internal use of KERMIT. However,
a question raised with increasing frequency is whether a company may
incorporate KERMIT into its products. A hardware vendor may wish to include
KERMIT with its standard software. A software house may wish to incorporate
KERMIT protocol into its communications package, or to distribute it along with
some other product. A timesharing vendor or dialup database may wish to
provide KERMIT for downloading. All these uses of KERMIT are permissible, with
the following provisos:

. A KERMIT program may not be sold as a product in and of itself. In addition
to violating the prevailing spirit of sharing and cooperation, commercial
sale of a product called "KERMIT" would violate the trade mark which is held
on that name by Henson Associates, Inc., creators of The Muppet Show.

. Existing KERMIT programs and documentation may be included with hardware or
other software as part of a standard package, provided the price of the
hardware or software product is not raised significantly beyond costs of
reproduction of the KERMIT component.

. KERMIT protocol may be included in a multi-protocol communication package as
one of the communication options, or as a communication feature of some
other kind of software package, in order to enhance the attractiveness of the
package. KERMIT protocol file transfer and management should not be the
primary purpose of the package. The price of the package should not be
raised significantly because KERMIT was included, and the vendor's literature
should make a statement to this effect.

. Credit for development of the KERMIT protocol should be given to the Columbia
University Center for Computing Activities, and customers should be advised
that KERMIT is available for many systems for only a nominal fee from
Columbia and from various user group organizations, such as DECUS and SHARE.

Columbia University holds the copyright on the KERMIT protocol, and may grant
permission to any person or institution to develop a KERMIT program for any
particular system. A commercial institution that intends to distribute KERMIT
under the conditions listed above should be aware that other implementations of
KERMIT for the same system may appear in the standard KERMIT distribution at
any time. Columbia University encourages all developers of KERMIT software and
documentation to contribute their work back to Columbia for further

Finally, Columbia University does not warrant in any way the KERMIT software
nor the accuracy of any related documentation, and neither the authors of any
KERMIT programs or documentation nor Columbia University acknowledge any
liability resulting from program or documentation errors.

These are general guidelines, not a legal document to be searched for
loopholes. To date, KERMIT has been freely shared by all who have taken the
time to do work on it, and no formal legalities have proven necessary. The
guidelines are designed to allow commercial enterprises to participate in the
promulgation of KERMIT without seriously violating the KERMIT user community's
trust that KERMIT will continue to spread and improve at no significant cost to
themeselves. The guidelines are subject to change at any time, should more
formal detail prove necessary.

Commercial organizations wishing to provide KERMIT to their customers should
write a letter stating their plans and their agreement to comply with the
guidelines listed above. The letter should be addressed to:

KERMIT Distribution
Columbia University Center for Computing Activities
612 West 115th Street
New York, NY 10025"



The maximum packet send packet size is limited to 90. This was done
as a work-around to an undetermined problem in the code from Columbia
which caused errors on some packets when a maximum packet size of
94 was requested by the receiver. Even if the receiver allows a max
packet size of 94 in the Send-Init exchange, PCKERMIT limits the actual
size of packets it sends out to 90. I believe this is done in one of the
.H header files.


An additional heuristic is being added to the Kermit Sliding Window Definition
to avoid unnecessary timeouts due to lost ACKs or NAKs. This additional
heuristic has not been implemented in V1.16 of PCKERMIT.EXE.
The substance of the additional heuristic will be:

"An additional heuristic will prevent most timeouts due to lost ACKs
or NAKs. The sender re-sends the earliest packet (the packet blocking the
window) if the following conditions are true:

1. The Sender's window is blocked.
2. The Retry Count for the earliest packet is zero.
3. An ACK (or optionally also NAK) for any later packet has been received."

This heuristic takes advantage of the fact that ACKs and NAKs should
normally be received in order. Receipt of a later ACK implies that the
earliest ACK was lost. Therefore, we can anticipate that a timeout is
likely to occur and avoid it by resending (once) the packet blocking the
window. The packet is only sent once (i.e. if the retry count is
zero) to avoid complicating error recovery.


1. There is a reportedly a bug in the Microsoft C Compiler which causes an
error in the Kermit Type 3 (CRC-16) Checksum algorithm. Beware!

2. Lattice C allows nested comments, which are not allowed by the Microsoft
C compiler. Their may be some instances of nested comments. LCKFNS3
has at least one area that was commented out that results in a nested


Long filenames can duplicate existing filenames because they are not
evaluated by PCKERMIT. The long filename is sent to DOS, which truncates
it to the first FILENAME.EXT characters.

In general, renaming works for most standard MS-DOS files. However, there
are some remaining bugs which reflect the UNIX origins of this code.
Developers may wish to take a close look at this area.

The addition of ~1, etc, after the filename is not ideal in the MS-DOS
environment because the extension is completely lost. Often files are being
received with same root but different extensions. If they are updates, it
may take a while to sort things out.

This logic is implemented in LCKFIO.C in the routine ZNEWN.


The Kermit sliding window extension is defined in the file KWINDOW5.DOC.
If the definition is unclear or ambiguous to you in any respect, please
contact Columbia University or Source Telecomputing at the address below.


The Kermit Sliding Window Definition is still labeled experimental by
Columbia University in order to help iron out all problems before the
final definition is published and to aid in coordinating efforts on
sliding window Kermits.

For the time being, we suggest developers can help the standardization
process by testing their implementations with the following Kermits:

PCKERMIT.EXE (Sliding window Kermit)
The Source (Sliding window Kermit)
MSKERMIT version 2.28 from Columbia University (Classic Kermit)


A bulletin board at 301-428-7931 (data only 300/1200/2400) is
providing informal support for sliding window Kermit.
This is a Maryland number.


Please send all corrections, questions and comments to:

John Mulligan
Source Telecomputing Corporation
1616 Anderson Road
McLean, VA 22102
SourceMail: STC356

Columbia University System Mail: We are OC.SOURCE on system CU20B.

  3 Responses to “Category : C Source Code
Archive   : WKERMSRC.ZIP

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: