SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (07/18/86)
Info-Kermit Digest Fri, 18 Jul 1986 Volume 5 : Number 2
Today's Topics:
Additional BITNET Kermit File Access
Amiga Kermit Bootstrapping
Extra-Long Packets Specification
KERMIT Transfer Rates with File Compression
MS-Kermit 2.29 Memory Contention Problem
Rosetta Stone for MS-Kermit and VT100
A Wish List (long)
----------------------------------------------------------------------
Date: Tue, 15 Jul 86 06:19 EST
From: <BRIAN@UOFT02.BITNET> (brian nelson)
Subject: Additional BITNET Kermit File Access
Keywords: KERMSRV at Uoft02
Usage of kermsrv@uoft02.bitnet
There is a bitnet server for Kermit files at the node Uoft02. The 'user' is
called KERMSRV and is accessed in the following manner:
from VM/CMS: CP SMSG RSCS MSG UOFT02 KERMSRV DIR
CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*
from VMS Jnet: $ SEND KERMSRV@UOFT02 SEND K11*.*
Please note that any filespec containing wildcard characters will be queued
for a deferred transmission; please do not override this by submitting
multiple requests. Also, there is no point in sending requests that involve
CUVMA or CUNYVM in the routing. If the traffic is too high, there is a
possibility that requests could be deferred to the next day.
We are connected to Ohio State via 9600 line, then to PSUVM which goes
to CUNYVM when I send you mail. Most of the european traffic seems to go
from PSUVM to GWUVM and then out to EARNET. Anyway, I think we want to
avoid routing that involves CUNYVM. Sorry, if we were farther west then
this thing would be more useful.
The commands are (in Jnet format)
$ send kermsrv@uoft02 dir FILESPEC
$ send kermsrv@uoft02 send FILESPEC
$ send kermsrv@uoft02 vmsdump FILESPEC
$ send kermsrv@uoft02 help
The 'VMSDUMP' command can be used to avoid EBCDIC translation, thus if you
are running jnet on your vax you can request Kermit-11 binary files.
brian@uoft02.bitnet
[Ed. - Thanks for the information Brian!]
------------------------------
Date: Wed, 16 Jul 86 16:22 N
From: <MAESSEN%HWALHW5.BITNET@WISCVM.ARPA>
Subject: Amiga Kermit Bootstrapping
Keywords: Amiga Kermit, Bootstrapping
As I tried to install the Amiga Kermit I found out there was no real
solution for the bootstrap procedure: How could I get the CKIBOO.BAS and
CKIKER.BOO files on our Amiga?
One of the problems was, that if I used a simple BASIC program, buffer
overflows occurred and there was no reliable stop criterium.
That's why I wrote two programs, one for our Vax and one BASIC program for
the Amiga which can do the job.
W. Maessen
Agricultural University,
Wageningen, The Netherlands
P.S.
I didn't have the time to create a composite program which combines
CKIBOO.BAS and this Amiga Basic program, but it sure would save some time.
[Ed. - Thanks! The programs are listed in the file KER:CKIBOO.MSG.]
------------------------------
Date: Thu 17 Jul 86 13:19:44-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Extra-Long Packets Specification
Keywords: Extra-Long Packets, ELP
Recent technological advances have brought high-speed, error-correcting
asynchronous dialup modems into the marketplace, and it won't be long until
they are affordable by ordinary mortals. The first question some people ask
when they learn of these of these devices is whether their error-correcting
capability has made Kermit obsolete. The answer is an emphatic no, for at
least two reasons. First, although error-free transmission may be guaranteed
from modem to modem, it cannot be assurred between modem and computer.
Second, even when the connection between computer and modem is clean, problems
of file delimitation, file representation, and computer-to-computer
synchronization are not solved by these modems.
When new communication technologies provide high-speed, potentially error-free
paths, then file transfer performance is unreasonably hampered by Kermit's
short packets and its stop-and-wait operation. But (you ask) won't the long
packet extension solve this problem? Perhaps, for some modems. But others,
already on the market, will not perform at their peak unless they handle data
in bursts even longer than the 9024-byte maximum provided by this extension.
One such modem, operating in half duplex, wants data in chunks of at least
16K-20K, and others may need even more.
Successful transmission of very long packets, especially at high speeds,
requires effective end-to-end full duplex flow control. When modems or other
intermediate devices are involved, each device along the chain must be able to
control the flow of data from the devices "upstream." For instance, if the
receiving computer cannot keep up with arriving data, it must be able to stop
the modem, and when the modem's buffers approach fullness, it must stop the
other modem, which in turn must be able to stop the sending computer, all
without loss of a single byte of data.
But given a virtually error-free path with reliable end-to-end flow control,
Kermit's maximum packet length can be further increased by employing a second
kind of extended header, which is just like the long-packet (LP) header, except
with a 3-byte, rather than 2-byte, extended length field. The presence of a
3-byte length field is signalled when the LEN field of the packet indicates
(after decoding) a length of one. The DATA field of such a packet begins with
an extended header in which the first three bytes are the 3-digit base-95
length, and the 4th byte is the header checksum. This allows for lengths up to
857,374 (95 cubed minus 1).
To ensure that this extension is compatible with Kermit programs that are
unaware of it, we must include it in the negotiations. Rather than extend the
capability mask into a second byte, we take over one of the reserved bits, and
assign capability #2 (bit 4 of the first capability byte, corresponding to a
value of 16) for extra-long packets (ELP). The rest of the initialization
string stays the same, but the interpretation of the MAXLX1 and MAXLX2 fields,
which appear at CAPAS+2 and CAPAS+3 respectively, is different. If the ELP
capability bit is set (regardless of the setting of the LP bit), then the
2-digit base-95 quantity given by MAXLX1 and MAXLX2 should be multiplied by 95
to obtain the intended length. In other words, MAXLX1 is the "9025's place"
(rather than the 95's place), and MAXLX2 is the 95's place (rather than the 1's
place). For instance, if the maximum length is to be 30,000, the encoding
could be "#>" (3x9025 + 30x95 = 29,925) or "#?" (30,020).
As with regular long packets, the file receiver tells the sender the maximum
length packet to send. But now there are more possibilities, since either
Kermit program may support one or the other or both (or neither) long packet
extension. If the receiver does not support LP or ELP, the sender will send
only normal packets (NP). If a Kermit program supports ELP, then it should
also support LP, so that it can fall back to LP rather than to NP when the
receiver supports LP but not ELP.
The interesting case arises when the sender supports only LP, but the receiver
supports both LP and ELP. If the receiver puts the ELP maximum length in
MAXLX1 and MAXLX2, then the sender (which is unaware of the ELP extension) will
interpret these numbers as the LP maximum length, 95 times smaller than what
the receiver intended. But since the sender goes first in the negotiation, the
receiver sees that the sender does not have ELP capability, and in this case it
can specify a suitably large LP maximum length (like 9024) in its own
initialization string, rather than an ELP maximum length that the sender would
misinterpret. Without this trick, fallback would occur to a much smaller size.
A few final words of caution are necessary. First, the longer the packet, the
more rigorous the required error-checking technique; it would be unwise to
transmit packets of thousands of characters guarded by anything less than a
16-bit CRC. Second, extra-long packets are untried as of this writing; even if
the technique works, performance might be disappointing if the implementation
follows the straightforward path suggested in all the foregoing code. When
packets are very long, the transmission line can sit idle for extended periods
while packets are being assembled and disassembled. Although idleness is
unavoidable while the receiver is checking and processing the packet before
ACKing it, the sender can make use of this time to begin assembling its next
packet, so that additional idle time after the ACK is received is avoided.
This trick requires an additional packet transmission buffer, which, for
very long packets, might be hard to find. Finally, users must know the
required conditions for successful use of long packets, and must request
extended packet sizes explicitly; too many things can go wrong if long packets
are used by default.
------------------------------
Date: Tue, 15 Jul 86 13:19 EDT
From: CCPHIL@TUCC.BITNET (Phil Julian, SAS Institute)
Subject: KERMIT Transfer Rates with File Compression
Keywords: Compression
We have found that piping Kermit input through a 'compress' program will
greatly increase the transmission rate when going between a Sperry 5000 Unix
system and an HP 9000 Unix system, using C-Kermit on both ends. Much of the
improvement may be due to spaces in the original source, and nulls in the
tar format, but the effects of the compression program are much greater than
Kermit's internal space compression.
The first attempt to send the files was
tar cf - . | kermit -i -s - on the HP 9000
kermit -i -k | tar xf - on the Sperry 5000
22 megabytes took 8.5 hours to send, with a 31.4% efficiency rate, at 19.2k
baud.
The next attempt to send the files was
tar cf - . | compress | kermit -i -s - on the HP 9000
kermit -i -k | uncompress | tar xf - on the Sperry 5000
4 megabytes took 1 hour to send, with a 54.6% efficiency rate, at 19.2k
baud. The improvement was a 74% over using Kermit alone. The compress
program is in the public domain, and uses the Lempel-Ziv algorithm.
These figures may add to the argument to add space compression algorithms to
the Kermit protocol. Few systems have Unix-like pipes, so the addition to
the protocol would be useful.
[Ed. - Yep, in fact this technique is suggested in the documentation. There
are other problems with Unix Kermit performance too, including excessive
copying of data from buffer to buffer, single-character i/o where bulk i/o
would suffice, lack of flow control, etc. These will be addressed in future
releases.]
------------------------------
From: I. WRENCH <ELRL93@uk.ac.rutherford.prime-f>
Date: Wed, 16 Jul 86 09:11:36 BST
Subject: MS-Kermit 2.29 Memory Contention Problem
Keywords: MS-Kermit 2.29 memory contention
In a previous UK newsletter I asked for help with problems using v2.29 of
Ms-Kermit to a DEC 10 system. The symptoms were that files sent from the PC
contained spurious characters on arrival, always in the same places. Several
people replied with sugestions, all of which i tried and seem to have no
success. I managed to get access to kermits on non-DEC machines and tried my
Ms-Kermit out with them - and got exactly the same problem. This lead me to
think that my actual copy of Ms-Kermit (brought down in .BOO form from
Lancaster) might have been corrupted somehow. I brought the .BOO file down
again using a different terminal capture prog than I originally used, and
converted the .BOO file using both the .PAS and .BAS de-hexers - but nothing
changed. This seems to suggest that there was something wrong with the set-up
on the IBM-XT I was using, and with a lot of playing around I traced down the
problem to be a program called INT10 that was being loaded in the AUTOEXEC.BAT
file. This program I believe has something to do with the Hercules graphics
board and I presume was causing workspace contention problems with Ms-Kermit. I
think this was caused as Ms-Kermit was growing in size to the point when the
problem was triggered at the release of v2.29. Incidentally the scroll back
pages function also just stopped working, it just pulled back rubbish onto the
screen. Anyway all is back to perfect working order now, if anyone else was
having similar problems to me i.e a perectly good program just stopped working
properly, and you can't trace it, then look to see what else is resident in
memory. Hope this is of use.
Iain Wrench.
[Ed. - See next message.]
------------------------------
Date: 17 JUL 86 13:31-MDT
From: JRD@USU
Subject: RE: MS-Kermit 2.29 Memory Contention Problem
Keywords: MS-Kermit 2.29 memory contention
Iain's difficulties were appearence of strange characters in transferred
files and a trashed roll back screen. In his most recent note he traced
both to a Hercules supplied Helpful Utility, INT10.COM.
Indeed, Iain. The Hercules display board has characteristics much different
than standard IBM boards. Their INT10 program intercepts Bios Int 10h calls
(video display) and maps them into Hercules compatible form and might also
use memory not belonging to itself. The strange looking characters on the
roll back display were graphics images whereas Kermit expects text and
attributes. I have a legal copy of INT10 here and get similar troubles.
However, Kermit runs well with the EGA boards, in text mode.
Thanks for the specific symptoms. I had seen your original note in the UK
Kermit newsletter, but have not had time to reply.
Regards,
Joe D.
------------------------------
Date: Mon, 14 Jul 86 21:51:40 EDT
From: Edward_Vielmetti%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: Rosetta Stone for MS-Kermit and VT100
Keywords: VT100 Emulation, Keyboard settings
After (too much) hacking around with various other terminal programs and
with Kermit, I've come up with a reasonably useful general reference for
mapping the vt100 keypad with MS-Kermit.
No single keyboard mapping is "best"; it all depends on your particular
application. In particular, some keyboards are best mapped logically (f1
corresponds to numeric pad 1) and others are best done physically (the one
in the upper corner is the same in both). Instead of trying to please
everyone, here's a way to roll your own with a minimum of effort.
The first set of diagrams are pictures of the keyboard mappings for all the
vt100 implementations I could find. There aren't too many, but these few
show the various approaches nicely.
The second set of diagrams should save some time when you build an
initialization file. In it are the results of SHOW KEY for all the function
keys and all the numeric keypad keys.
(The numeric keypads shown have an enter key on them, since they were done
on a Zenith 158. With that exception they should be generally applicable.
I don't have an enhanced AT keyboard to play with.)
Edward Vielmetti
Computing Center MicroGroup
University of Michigan
emv%UMich-MTS.Mailnet@MIT-Multics.ARPA
+----+----+----+----+
| PF1| PF2| PF3| PF4| This is the layout of a real, live
+----+----+----+----+ VT100 keypad.
| 7 | 8 | 9 | - |
+----+----+----+----+
| 4 | 5 | 6 | , |
+----+----+----+----+
| 1 | 2 | 3 | |
+----+----+----+entr|
| 0 | . | |
+---------+----+----+
+----+----+----+----+
| SF1| SF2| SF3| SF4| This is the layout of the VT100 emulation
+----+----+----+----+ for Procomm v2.3.
| F7 | F8 | F9 | SF5|
+----+----+----+----+
| F4 | F5 | F6 | SF6|
+----+----+----+----+
| F1 | F2 | F3 | |
+----+----+----+ SF8|
| F10 | SF7| |
+---------+----+----+
+----+----+----+----+
| F1 | F2 | F3 | F4 | This is the layout of the default VT100
+----+----+----+----+ emulation for MS-Kermit v2.29.
| F5 | F6 | F7 | F8 |
+----+----+----+----+
| F9 | F10| SF1| SF2|
+----+----+----+----+
| SF3| SF4| SF5| |
+----+----+----+ SF6|
| SF7 | SF8| |
+---------+----+----+
+----+----+----+----+
| F1 | F2 | SF1| SF2| This is the layout for PC-VT v8.4. Note
+----+----+----+----+ the two keys mapped to the same
| F3 | F4 | SF3| SF4| VT100 key in the case of 0 and enter.
+----+----+----+----+
| F5 | F6 | SF5| SF6|
+----+----+----+----+
| F7 | F8 | SF7| SF8|
+----+----+----+ |
| F9 F10| SF9|SF10|
+---------+----+----+
+----+----+----+----+
| OP | OQ | OR | OS | These are the escape sequences sent out
+----+----+----+----+ by these emulations. Read "OP" as
| Ow | Ox | Oy | Om | <esc>OP.
+----+----+----+----+
| Ot | Ou | Ov | Ol |
+----+----+----+----+
| Oq | Or | Os | |
+----+----+----+ OM |
| Op | On | |
+---------+----+----+
+----+----+----+----+
| F10| SF1| SF2| SF3| This is the VT100 emulation
+----+----+----+----+ defined by PC1:MSKERMIT.INI
| F7 | F8 | F9 | SF4| for the University of Michigan's
+----+----+----+----+ MTS system.
| F4 | F5 | F6 | SF5|
+----+----+----+----+
| F1 | F2 | F3 | |
+----+----+----+ SF6|
| Grey - | SF7| |
+---------+----+----+
1
Show Key for the function keys:
+----+----+ +----+----+ +----+----+ +----+----+
| f1 | f2 | | 596| 597| |1118|1119| |2152|2153|
+----+----+ +----+----+ +----+----+ +----+----+
| f3 | f4 | | 598| 599| |1120|1121| |2154|2155|
+----+----+ +----+----+ +----+----+ +----+----+
| f5 | f6 | | 600| 601| |1122|1123| |2156|2157|
+----+----+ +----+----+ +----+----+ +----+----+
| f7 | f8 | | 602| 603| |1124|1125| |2158|2159|
+----+----+ +----+----+ +----+----+ +----+----+
| f9 | f10| | 604| 605| |1126|1127| |2160|2161|
+----+----+ +----+----+ +----+----+ +----+----+
unshifted shifted with ctrl with alt
+----+----+----+----+ +----+----+----+----+
|Home| Up |PgUp|Gry-| | 7 | 8 | 9 |Gry-|
+----+----+----+----| +----+----+----+----|
|Left| |Rght|Gry+| | 4 | 5 | 6 |Gry+|
+----+----+----+----+ +----+----+----+----|
| End|Down|PgDn| | | 1 | 2 | 3 | |
+----+----+----+----+entr| +----+----+----+----+entr|
| Ins | Del | | | 0 | . | |
+---------+---------+----+ +---------+---------+----+
cursor pad numeric pad
+----+----+----+----+ +----+----+----+----+
| 71 | 72 | 73 | 74 | | 583| 584| 585| 586|
+----+----+----+----+ +----+----+----+----+
| 75 | | 77 | 78 | | 587| 588| 589| 590|
+----+----+----+----+ +----+----+----+----+
| 79 | 80 | 81 | | | 591| 592| 593| |
+----+----+----+----+ 28 | +----+----+----+----+ 540|
| 82 | 83 | | | 594 | 595 | |
+---------+---------+----+ +---------+---------+----+
unshifted shifted
+----+----+----+----+
|1143| |1156| |
+----+----+----+----+
|1139| |1140| |
+----+----+----+----+
|1141| |1142| |
+----+----+----+----+1052|
| | | |
+---------+---------+----+
with ctrl
------------------------------
Date: Wed, 16 Jul 86 16:17 PDT
From: FRIEDMAN%OAVAX.MNET.MFENET@LLL-MFE.ARPA
Subject: A Wish List (long)
Keywords: MS-DOS Kermit, MS-DOS 2.29
For the last year or so I have been using MS-KERMIT on a PC-XT to
connect to a variety of computers. These include the CRAYs here at
NMFECC and the local VAX running VMS. I have been collecting a
wish-list, and thought it was time to post it and see if some of the
items might be added to the "official" list in the BWR file.
Here goes:
1) Any new text coming from the host or typed by the user should appear
at the end of the last screenful, not at the cursor location. Operator
messages from the host, as well as messages from programs I am running,
often obscure critical text on the screen while I am examing something I
did five minutes earlier.
2) Seven pages (or so) of screen memory is nowhere near enough. I'd
like to be able to use as much memory as I want, (say) 30 pages of
screen memory. Better still would be an "infinitely" long memory,
with simultaneous storage into a disk file that would serve as both a
log and the top half of the screen memory. This might also allow you
to view the screen memory of your last session simply by paging back
during the current session. The present log is awkward since a) it
isn't available online, and b) it contains a lot of control
characters from backspacing over typing errors, and from screen
editing sessions on the VAX when I forget to turn off the logging.
3) Printing and dumping. It would be nice if one could somehow "mark" a
section of the screen memory and either print it or save it to a file.
4) The CRAYs do not respond to input characters until the carriage
return is pressed (this is also true of many computers accessed through
networks). Thus, screen editing is impossible without use of a
"co-editing" program which runs on the PC and the CRAY simultaneously.
It might be a good project to develop standards for such a system.
NMFECC and LCC both support a system called SED which seems to work
well.
5) Again because of the above characteristic, editing of input lines
is limited to backspacing. A true line-editing capability (as on the
VAX, or in the DOS supplement/shareware program CED) could be
incorporated into the terminal emulator. This is the natural place
for such a capability, since the line could be echoed locally,
edited, then sent when the return key was pressed.
6) A related wish is command-line recall, either VMS/CED-style (press a
key repeatedly and old command lines reappear in reverse order) or by
highlighting text in the screen memory somehow, then bringing the line
into the current command buffer for editing by pressing a key, then
sending it with a return. On our system, linefeed characters echo as
exclamation points, and so a facility for translating exclamation points
into linefeeds (and echoing linefeeds as !'s during local pre-
transmission editing) would be useful - of course, the mapping should
be general enough to support a variety of host computer idiosyncrasies.
7) When I assign a character string to a key, then press the key, often
the characters appear too rapidly for our CRAY terminal concentrator to
accept them. It would be useful if the speed with which character
strings were sent to the host could be selected by the user. Since when
I talk to the VAX I press the arrow keys a lot, and these send
three-character sequences, I'd like these to be sent at full speed - so
some means of specifying the "speed of paste" when each key is defined
would be best. (Also, it would be nice if the interactive key
definition procedure were streamlined so that the user need only press
the key they wished to define - why do we need to know the scan code?).
8) It would be nice to have a "bare bones" mode that used DOS for the
keyboard handling. My text editor has a facility whereby one can
start a command processor, and use the editor commands to paste old
lines, etc. Thus, one gets command line recall and a log when
running compilers on the pc. It would be nice if I could run codes
on the CRAY this way.
Also, I have some questions about what happens when one is not
in connect mode and a message comes in over the serial port from the
mainframe. When I am at Kermit command level after a ctrl-]c, then I
reconnect, data is missing from the screen (if I had been listing my
files, the list would be garbled). I have had better luck with
ctrl-]p. What I'd really like is a full explanation of what happens
- for example, does the disk actually run in a background mode to
update the log when an interrupt comes in over the port?
Finally, I expect that some of the above wishes might be
answered by use of either a) a windowing program, b) a mouse with
appropriate driver for cut-and-paste, or c) a keyboard enhancer
program, and wonder if anyone has learned any useful tricks. I use
SIDEKICK all the time with MS-KERMIT, and find it useful to paste
frequently used lines from the notepad; SIDEKICK allows the user to
control the speed of pasting, and so I avoid the problem alluded to
in (7) above.
In general, I'm very pleased with MS-KERMIT; I would appreciate
any comments on these ideas from either the KERMIT developers or the
user community. Comments can be posted if of general interest; other-
wise I can be reached at:
friedman%llv@lll-mfe.arpa
or some such thing depending on the syntax of your local mail utility;
Im on the LLV VAX on the MFENET at Lawrence Livermore National Laboratory.
------------------------------
Date: 16 JUL 86 21:47-MDT
From: JRD@USU
Subject: RE: Wish List
Keywords: MS-DOS Kermit, MS-DOS 2.29
Mr. Friedman (friedman%llv@lll-mfe.arpa),
Your long "wish list" arrived in the mail from Columbia and, since
I have been doing much of the MS Kermit development recently, perhaps I can
comment on some of the points.
As I understand things, the bulk of the wishes are closely related
to offsetting deficiencies of the mainframe host, full editing facilities
in particular.
Point 1: While in connect mode incoming text should be placed at the end
of previously received text rather than at the cursor position (if the screen
has been rolled back manually). True, but. This would require a healthy amount
of screen and memory management code and employment of multiple pages of video
memory (on what kind of display adapter?) to avoid massive flickering between
old and new screens. And, think about what must be done if the regular screen
scrolls up. Just telling the host Xoff can work wonders most of the time;
exiting connect mode, selecting port 2, and returning to connect mode will
also preserve the old screen (but will lose new incoming text from port 1).
Point 2: Five screens of roll back are too few, 30..inf would be much nicer.
Again, these things can be done, at a stiff price in both runtime code
space and programmer effort. An easy work around is to make a hard copy
listing as you go (Control PrtSc does the trick). Micros are spoiling us.
Point 3: Selectively edit a screen for dumping to a printer. See below.
Modern full screen editors on micros have many of the characteristics
you wish. They cost $200+ when Sold in large quantities and they just edit.
Some serious duty editors of this kind are Brief, Emacs, Epsilon, and Kedit.
For capturing program output to a window have a look at Epsilon by Lugaru;
I'm using Brief. Some day, "real soon now", mainframe editors will catch up,
but at a very hefty price in i/o channel facilities (38 Kbaud+) and scads of
real memory for buffers, etc. My students have remarked to me that because
I have pronounced ideas on what editors should do then why not write my own.
Yes, certainly, but what about all the other interesting things to do?
Point 4: Cray editors are line oriented rather than full screen types. Yep!
Only Real Programmers use Crays and RPs are happy with card images and
patching binaries; I was & did. Try a copy of Emacs. By the way, why are
you burning up Cray time doing editing? Don't you fellows at LLL work into a
mere-computer front end to handle i/o, scheduling, and other routine chores?
(Must be the SDI money.)
Point 5: Line editing Helpful Utilities. These still work under Kermit!
Mouse menus can be very useful for classes of minor tasks, and Kermit loves
the little fellows. Microsoft supplies a very good menu program with their
mouse; I have both.
Point 6: Command line recall buffer and translation of strange input chars.
Kermit already has too many buffers and the command parser is Byzantine
trying to do the present command line editing (in system independent fashion).
Limited translation is being considered, particularly for European characters.
Point 7. Pace sent characters. Either lower the baud rate or have the troops
get a concentrator with typeahead buffering. If we were to pace characters
then most of the other users would hit the overhead. Also, key redefinition
could be much smoother. Sure could, and we are thinking about doing so
when time is available; it will not replace Prokey et al. Also, how do you
get file transfer packets through a slow concentrator?
Point 8: Bare bones keyboard handling (let DOS do it). MS Kermit obtains
keyboard info by both DOS calls and Bios calls; it does not go to the
keyboard hardware and the like. It is about as bare bones as possible. If you
were to use a fancy console handler which passes along scan codes properly
then it probably would be compatible with Kermit. Most such utilities do not
do so yet.
Question: What's with the serial port?
Kermit returns the serial port to its original owner when Kermit
does not have direct need of it, such as between file transfers. That is
a very good safety feature for a program which uses interrupts for reception.
As you may notice, between file transfers or Connect sessions there is no
implied source/sink for serial port information; thus, Kermit is unaware
of the port at such times. If the port were left active then Kermit would
have to be prevented from accessing conflicting programs or letting the user
Push to DOS, etc just to keep the interrupts from calling a perhaps non-
existant interrupt routine (a disaster) or having a buffer overflow.
When DOS grows up to be a multi-tasking o/s then we can consider letting
Kermit run in the background; WINDOWS/DOS 5.0 does not seem to be there yet.
I also run DECnet-DOS on my micro, and it tries to permanently install itself
as an extension of DOS plus "own" the serial port most of the time. It runs
the port in the background and messes with DOS in a very serious way.
Comment added by me. Kermit as a whole is written and improved by volunteers,
using an enormous number of man hours, and we earn exactly zero for doing so.
Thus, features get added when someone decides to do them (best to let Columbia
know first since others may be doing the same thing). Many of the items on
your wish list fall into the very sophisticated technique department.
Fortunately for all of us, many of the Kermit contributors are adept at such
matters, when they have the time. Suggestions such as yours provide a rich
menu of interesting things to consider. Like to have a go at one or two?
And not least, thanks for the nice words about the existing Kermit; they help.
Regards,
Joe D.
------------------------------
End of Info-Kermit Digest
*************************
-------