MS-DOS Kermit Version 2.29, differences from Version 2.28:

(...this is a prerelease draft, reflecting 2.28/jrd5e...)


. Full DOS 2.0 file support; device and path may be included in any
  file specification in any Kermit command.  DOS 1.x support fully removed.
  Version 2.29 will not run under DOS 1.x (neither would 2.28).

. The MS-DOS Kermit server responds to advanced server commands (REMOTE DIR,
  REMOTE HOST, REMOTE DEL, REMOTE TYPE, REMOTE CWD, etc).

. File renaming algorithm much improved.  File specification length
  range checked.

. Improved file name handling, to prevent destruction of directory,
  system, hidden, read-only, and volume label files.  GET and RECEIVE allow
  device and path to be prefixed to incoming filename.

. On the IBM PC family, emulation of VT52, H19, VT100, VT102, and
  dumb terminal (the latter to allow coresidence with a loadable console
  driver like ANSI.SYS).  Support for 25th line during terminal emulation.

. On the IBM PC family, compatibility with TopView and MS Windows,
  and support for the Extended Graphics Adapter.

. Screen save (on IBM family only).  Push Ctrl-End to append screen to
  file KERMIT.SCN; use SET DUMP to change screen dump file (or device) name.

. New SET TERMINAL command for setting terminal type and parameters,
  including foreground and background color on systems that support it
  (currently only IBM family).  Also, explicit control over whether program
  should wait for refresh cycle to write screen (snow removal).

. Segments are now ordered independently of MASM/LINK version, without
  any special switches required for building, which should clear up all
  the system crashes that occurred when people ran the program after
  building it from source without the appropriate switches.

. COMMENT command, for documenting TAKE files.

. All known bugs in 2.28 fixed including:
   GET command filename confusion
   Failure to warn when run under DOS 1.x
   Many problems with file renaming, name truncation, etc.
   SET DEST PRINTER didn't work correctly
   Problems with dynamic memory allocation
   Problems with file transfer mode line display on early PC, Compaq
   Heath-19 emulation bug regarding receipt of CR or LF at column 80
   The "C?" bug in the command parser
   ^C of a file transfer did not honor SET INCOMPLETE KEEP
   Lost clusters on disk if BYE command given with log file open
   RUN command did not default file types .EXE, .COM, .BAT
   Long debug lines overflowed screen
   Overruns of half duplex systems at high baud rates
   Control-prefix operands in packets not range checked
   Interrupt and performance problems on IBM PC family
   Numbers sometimes disappearing from file transfer display

Incompatibilities:

. SET HEATH gone, replaced by SET TERMINAL { HEATH, VT102, etc }
. SET AUTOWRAP gone, replaced by SET TERMINAL WRAP
. SET REMOTE ON/OFF changed to SET DISPLAY OFF/ON (but SET REMOTE still there)

What's not in 2.29:

. TRANSMIT command for raw file upload
. Login scripts
. DIAL command, telephone directory
. Explicit control of DTR, RTS, and other modem signals
. VT102 printer control
. Any way to reassign BREAK, mode line toggle, and screen scrolling keys
. Tektronix or other graphics terminal emulation
. Redefinable keys at Kermit-MS> prompt level
. Serial file transfer display option (for use with Votrax, etc)
. Ability to display 8-bit characters during CONNECT
. More efficient scrolling memory for Rainbow to allow more screens saved
. Pause at end of screen during local TYPE
. Piped operation a la UNIX (e.g. compress foo.bar | kermit send)
. Perfect separation of
  (a) system-independent parsing of terminal-dependent escape sequences, from
  (b) system-dependent functions to perform the indicated actions.
  (actually, (a) is separate, but in MSZ module, where modem support is
  supposed to be.)

Also, the protocol code has not been significantly changed, and could stand
a lot of cleaning up -- much code could be eliminated by clear separation of
presentation, transport, and datalink functions.  In particular, packets
should never be reconstructed for retransmission -- there should be a simple
retransmission buffer.  This does not usually cause problems except when
the user types CR a lot during file transfer.