cc.fdc@COLUMBIA-20.ARPA (01/24/84)
From: Frank da Cruz <cc.fdc@COLUMBIA-20.ARPA>
We (at Columbia) have decided to make a full blown effort at getting IBM PC
Kermit in shape, and will be working on it full time over the coming weeks or
months. While the present release, 1.20, is quite adequate, there remain gaps
and problems. What's worse, 5 or 10 different sites have made significant
modifications to this program -- most of them useful and worthwhile -- and we
are badly behind in fitting all this work into the base version. What follows
is our list of things to do (it's rather long). If you have comments on this
list, please send them to me. And if you have additional suggestions, send
those to me too, rather than changing the program yourself. Meanwhile,
announcements will be made of test versions of PC Kermit from time to time, as
the various features find their way into the program. Here's the list:
* Support for multiple systems:
First, the program should no longer be thought of as IBM PC Kermit, but rather
MS DOS KERMIT. Support has been added to it (at other sites) for at least the
following MS DOS systems:
. DEC Rainbow 100, 100+
. Heath/Zenith 100
. Victor 9000
. Seequa Chameleon
. Eagle 1600
. Ericson Step/One (Panasonic JB3000)
And we'll soon be getting in some IBM Peanuts and HP-150s, which will have to
be supported by this program too. Currently, only the IBM PC/XT and Z100
support are integrated into the same program. We need to integrate support for
the other systems too.
By the way, the IBM PC version is known to run without modification on certain
PC-compatibles, including the Compaq portable and the Columbia MPC.
* Program organization:
The program is now a gigantic monolith, with conditional assembly to select the
PC or Z100. It will only become larger and more tangled (like CP/M-80 KERMIT)
if we support the additional systems in the same way. So it has to be broken
up into separately compiled modules. There should be a system-independent
module for the protocol, and system/device/etc-dependent modules for:
. port i/o
. modem control, if necessary (for "smart" &/or internal modems)
. file i/o
. printer i/o
. screen display (cursor positioning, screen clearing, etc)
. terminal emulation (some people have wanted to plug in their own terminal
emulators)
. command parsing (some people would prefer a Unix-style command parser, or a
menu, or function keys, or a mouse, or a pointing finger, or ...)
and so forth. This cuts down on assembly time, KERMITing time, etc, and -- if
the modules have well-defined specifications and interfaces to the outside
world -- should make it easy to support new systems by plugging in new modules.
Doing it this way requires clear user-level documentation about how to put
together a working KERMIT for an existing or new system.
* I/O structure:
Packet encoding/decoding must be separated from file/port i/o, to allow
non-file data to be encoded/decoded, e.g. to send directory listings. For
instance, it is now possible for you to type "GET FOO#BAR" (assuming you're
talking to a system that allows "#" in filenames); since the argument for the
server command doesn't go through the normal encoding mechanism, the remote
KERMIT will see "FOO#BAR" and translate the "#B" to control-B. The data field
of any packet should go through the encoding mechanism to get control & 8th-bit
prefixes, etc. Obvious exceptions are the init and attributes packets.
* Binary file transfer:
. Get the 8th bit prefixing working reliably with DEC-10/20, VAX, etc.
. Get binary file transfer working with CMS KERMIT. This requires
implementation not only of 8th-bit prefixing, but also the dreaded FILE
ATTRIBUTES packet, to allow arbitrary record boundaries to be preserved for
CMS files sent to the PC and back.
* Herm Fischer's changes:
Test this stuff, integrate it, check it out on non-PC machines:
. Server mode
. TAKE command
. Init file
. Key redefinitions
. etc
* Kimmo Laaksonen's change:
. Filename completion, a la TOPS-20 & TENEX.
* Terminal emulation:
. Modularize
. Insert character is too slow when inserting a block of characters.
. Use 25th line to display current settings -- baud, parity, etc. Maybe
toggle (and/or scroll) this display with a function key.
. SET HANDSHAKE to allow user to specify this.
. SET FLOW-CONTROL option for XON/XOFF (during both terminal emulation & file
transfer)
. Session logging (with big memory buffer, XON/XOFF &/or handshake)
. Multiple page screen memory (like HP or new Concept)
. Distinguish between ^H and backarrow (they really are different); make
SET BACKARROW only affect backarrow, not ^H too.
. Support VT52/H19 reverse index command -- many editors, like VI, use it.
. User-defined function keys.
. SET BELL {VOLUME | PITCH | DURATION}
. Support for IBM's ANSI.SYS to allow (relatively slow) ANSI terminal
emulation. This has already been done by Glenn Everhart in the Seequa
version (I think the same thing is also in Herm's SET CONSOLE business).
. Support CTRL/PrtSc during terminal emulation (Shift/PrtSc already works).
. Fix the getting-stuck-on-25th-line problem.
. Do bounds checking on all cursor positioning commands.
. (pie in the sky) Full-speed ANSI terminal emulation, windows, line/char
insert/delete, etc.
* Add local functions (like in CP/M Kermit 3.6 & above):
These are especially handy for 1-drive systems (like the Peanut).
. Directory listings
. Deleting files
. Find out how much space is left on disk
. Change default disk
* Fix existing problems:
. Always update retry count on screen when there's a NAK or retransmit.
. MS DOS file byte count includes the ^Z at the end of the file.
If it's a text file, you don't want to send it; if it's a binary file
you do. Find some way to do this right. Probably need to add SET FILE
BINARY/TEXT like CP/M KERMIT.
. COMND simulation -- currently, if any fields are left off, the command has
no effect (like SET<CR> or SET IBM<CR>). It should either complain, or
supply a default. Also, implement ^R, ^W.
* Missing features from the protocol manual:
. Timeouts
. Fancy block check types -- 2 char checksum, 3 char CRC.
. Repeat counts.
. Sending file-management commands to server & displaying results.
. Server-provided file management: delete, rename, directory, type,
change directory, login, ...
. DEFINE command for SET macros.
* Etc:
. Verify everything in SPAR.
. Prevent receive-packet buffer overruns.
. Ability to run in background from a batch file.
. Ability to send a raw file (like in Kimmo's CP/M Kermit), with prevailing
handshake/flow control (XON/XOFF, half duplex XON, etc).
. Special features for PC-to-PC connection. For instance, sending an
entire directory tree, to be replicated on the target system.
. ^C during file transfer sends you straight back to command level.
. Don't set the baud rate to 4800 when starting up, but leave it at whatever
it was set at. If you want it at 4800 (or whatever), put a SET BAUD
command in your KERMIT.INI file.
. Appearance -- put some whitespace around "?" help messages.
. Add a real "help" command that gives a bit more information.
. Allow redirection of incoming files to devices other than disk:
- Printer, to let PCs share printers.
- Memory, to let programs be downloaded and started from remote disk.
* Finally, a manual:
A new manual needs to be written, for use in conjunction with the KERMIT User
Guide, much like the new (draft version of the) KERMIT-20 Manual. The manual
should contain not only detailed descriptions of the commands, but also hints
about using KERMIT within the PC/MS DOS environment, for instance:
Using KERMIT in conjunction with key redefinitions (like ProKey). For
instance to get a META key for EMACS, to make the arrow keys work with your
favorite editor.
Using KERMIT as a terminal (can't transfer files!) over a protocol emulator
as a 3270 -- inverse video, etc.
. Using KERMIT with a RAM disk.
. Using KERMIT with a "smart" modem.
. Using KERMIT over TELENET, through a TAC, over TYMNET, etc etc
. Nuts & bolts of connected two PCs.
Any other suggestions?
-------