SY.CHRISTINE@CU20B.COLUMBIA.EDU.UUCP (02/05/87)
Info-Kermit Digest Wed, 4 Feb 1987 Volume 6 : Number 4
Today's Topics:
MS-DOS Kermit 2.29b
Note for Testers of MS Kermit 2.29b.
MS-DOS Key Definitions
Kermit Keyboard Redefinition
Keyboard Translator
Bugs in WART
Commodore-64/C128 Kermit
Rationale for C-Kermit's approach to DTR?
Kermit for Apple // ProDOS?
----------------------------------------------------------------------
Date: 26 JAN 87 21:02-MDT
From: JRD@USU
Subject: MS-DOS Kermit 2.29b
Keywords: MS-DOS Kermit, 2.29b
RE: Kermit Digest V6 #3
Ed Barton reported that MS DOS interprets incoming filenames
such as AUX.C as meaning send the contents to device AUX. He recommends
Kermit rename the file to XAUX.C or similar. I just tested this situation
by having a VAX send this note as AUX.C to my micro running PC DOS 3.21.
The file was automatically renamed to AUX00001.C because AUX was recognized
as an existing file. This is with MS Kermit 2.29b. Earlier versions may
not detect the device name.
There are circumstances where device names are wanted as file
destinations, a serial printer connected to COM1 (AUX) is one of them.
Another small complication is that MS DOS character devices are known by
their names (CON, AUX, PRN, and the like) so that non-standard drivers
can have names in conflict with incoming files without Kermit being
aware of the sensitive names. MS Kermit knows nothing about real device
names per se and relies on DOS itself to reveal a potential conflict.
A workaround is to use an override filename when receiving such a file:
Kermit-MS> Receive Foo.bar
replaces the incoming filename with Foo.bar.
Joel Seiferas said the file transfer screen flashed on only
momentarily with his IBM PC w/Fansi-Console 2.0. Kermit follows DOS's
rules for the display. I suggest he try again without Fansi-Console
because such utilities trap video i/o and apply their own rules. Kermit,
of course, is completely unaware of the Helpful Utility and does not
need an ANSI interpreter. There was an earlier problem with Fansi-Console
when Kermit displayed the Connect mode status line; Fansi-Console's author,
Bob Smith, fixed that this summer.
My local tester of Zenith 100 Kermit version 2.29b says that it
works! One bug concerned cursor addressing after toggling the mode line
while in Connect mode. He promised to bring around tech documentation on the
Z100. Until advantage can be taken of those details I think we ought to try
out MSK 2.29b on the Z100. Therefore, following this note is file MSTZ10.BOO
for the Z100.
Regards,
Joe D.
[Ed. - Thanks Joe! The .BOO file for the Zenith 100 is in KER:MSTZ10.BOO if
anyone wants to test it. See message from Joe below.....]
------------------------------
Date: 26 JAN 87 22:11-MDT
From: JRD@USU
Subject: Note for Testers of MS Kermit 2.29b.
Keywords: MS-DOS Kermit, Z100 Kermit, Zenith 100 Kermit
Notes for testers of MS Kermit version 2.29b
The Kermit Digest, Volume 6 number 3, 20 Jan 1987 contained a list
of improvements and new features found in maintainence release 2.29b. A
slightly longer version is reproduced below. As the Digest notes, we want to
make sure the present material is in good shape so the next major release,
2.30, will be more stable. So, the pleasant task of current testing is to
exercise Kermit, discover problems, and relay symptoms and even solutions
to Columbia or myself.
One possible problem is MS Kermit will attempt to send 94 byte
packets to a remote host which asks for smaller ones.
Another is a HANGUP command in a script might clear the modem DTR
and RTS signals so that the next serial port operation thinks they are still
active whereas the modem is asleep.
A concern is detection of the XON/XOFF flow control characters when
parity is being used. With the new allowance of 8 bit characters an incoming
8 bit character could appear as XON or XOFF with the high bit set. Testing
is needed here.
Similarly, the new ANSI printer control needs testing.
Terminal emulation in IBM Kermit is clearly a target for bug hunts.
Difficulties with line wrapping and the like using various editors is a
common problem. If you are using a popular Helpful Utility (the terminate
and stay resident kind) and note an anomoly try to detect if the H.U. is the
culprit so that other users will know of likely pit-falls. Sometimes it is
hard to note what are proper versus observed operations; an annotated LOG is
a good starting point since I can try to repeat the offending character
sequences. Escape characters in a LOG file are best translated to "ESC" or
other printable code for network transmission; a .BOO file also works if an
English description is sent along with it.
We are especially interested in knowing if MS Kermit 2.29b
successfully communicates with a wide varitey of hosts and through various
communications front-end devices. At this stage Kermit knows little about
Local Area Networks; your experiences would help.
Thanks for your time and help,
Joe Doupnik
jrd@usu.Bitnet
Center for Atmospheric and Space Sciences
Utah State University
Logan, Utah 84322
(801) 750-2982 (work)
[Ed. - The updates to MS-DOS Kermit 2.29b are described in KER:MST29B.UPD]
------------------------------
Date: Mon 26 Jan 87 20:07:46-EST
From: D. M. Rosenblum <DR01@TE.CC.CMU.EDU>
Subject: MS-DOS Key Definitions
Keywords: MS-DOS Kermit, Keys
In the INFO-KERMIT digest, Vol. 6, No. 2, Joe Doupnik asks for comments
about what users would like in a Kermit key translation system. One thing
that I would like (that I have asked about before) is the ability to specify
key translations that may take effect (and be disabled) only on the receipt
of certain character sequences from the remote host.
For instance, on a real VT1xx terminal (or a VT52, for that matter), there
are certain escape sequences that the host can send that will cause the
keypad keys to generate something other than their normal characters; there
are other escape sequences that the host can send that will cause the keypad
keys to revert to their normal characters. What would be nice is to be able
to specify a set of key definitions that should take effect automatically
when such an escape sequence is received from the host, and should cease to
be in effect when the escape sequence that would normally turn off the
alternate definitions is received ("cease to be in effect" here would imply
reverting back to either the default key definitions, or possibly some
user-specified defaults -- in other words, the user should be able to
define, say, the long keypad "+" key on an IBM-PC keyboard to mean one thing
most of the time, but to mean something else when the host has sent the
escape sequence that puts the keypad into alternate keypad mode, and to
revert back to his/her "most of the time" definition when the host sends the
escape sequence that puts the keypad back into normal mode). Since Kermit
is emulating a VT102, the escape sequences that have this effect are
well-defined (the only reason I'm not mentioning them here is that I don't
have a VT1xx manual readily available at the moment), and one wouldn't have
to accomplish the impossible task of thinking of what the right escape
sequences should be to have this effect.
Daniel M. Rosenblum, Ph.D. candidate,
School of Urban and Public Affairs (SUPA), Carnegie-Mellon University
ARPAnet (Internet): DR01@TE.CC.CMU.EDU
CSnet: use the appropriate gateway to ARPANET
BITnet: DR01%TE.CC.CMU.EDU@CMUCCVMA or DR01%TE.CC.CMU.EDU@WISCVM;
DR01@CMCCTE or DR01@CMCCTE.CCNET may work from some sites.
CCnet (DECnet): DR01@CMCCTE or DR01@TE.CC.CMU.EDU or DR01@CMCCTE.#DECnet
CMSPVX::SPPHDR01 (VAX DECnet only)
------------------------------
Date: Tue, 27 Jan 87 17:45:50 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Kermit Keyboard Redefinition
Keywords: MS-DOS Kermit, Keys
I would really like to see the keyboard translator get away from numeric
codes. It's very unfriendly and thus discourages people from using the
facility. One way to do this while still maintaining machine independence
is to allow the key names and code names to be defined via Kermit commands.
Then one person has to suffer once for each type of machine (to define the
correspondence between key names and scan codes. It also allows things like
new F12 keys to be handled without changes to Kermit. Here is a sample
syntax:
To define keys:
<command> ::= SET KEY <key-name> <key-def>
<key-def> ::= <key-item>
| <key-item> <key-def>
<key-item> ::= <number> [to represent an ASCII code]
| <quoted-string>
| <key-name> [to refer to another key definition]
| <Kermit-function>
| <code-name> [to refer to a predefined code sequence]
<Kermit-function> ::= ESCAPE
| BREAK
| PRINTON
| PRINTOFF
etc.
<number> is any of the following:
decimal integer
octal integer suffixed with the letter O
hex integer with a leading digit and suffixed with X
Suffix letters could be either case.
Alternatively, the backslash notation could be used for
octal and hex.
<quoted-string> is zero or more characters enclosed in single or
double quotation marks. If a quotation mark of
the same type as the enclosing ones is contained
in the string, it must be doubled.
To define the correspondence between the names of keys and scan codes:
<command> ::= SET KEYNAME <key-name> SCAN <number>
To define names for ASCII codes, escape sequences, etc.:
<command> ::= SET CODENAME <code-name> <code-def>
<code-def> ::= <code-item>
| <code-item> <code-def>
<code-item> ::= <number>
| <quoted-string>
| <code-name>
Of course, there should be corresponding SHOW commands for each of the set
commands, but I will omit their definitions.
Examples:
Make q key send z:
set key q "z"
assuming:
set keyname q scan ### [### represents the scan code for the q key]
Make control-G key send ANSI attributes off sequence:
set key cntl-g normal
assuming:
set keyname cntl-g scan ### [### represents scan code for control-G]
set codename esc 01bh
set codename normal esc "[0m"
Define control-L to send login sequence:
set key cntl-l "login" cr "myname" cr "mypass" cr
assuming:
set keyname cntl-l scan ### [### represents scan code for control-L]
set codename cr 0dh
The advantage of this scheme is that only once per different kind of machine
does someone have to sit down and set up a file of SET KEYNAME commands to
establish the correspondence between names of keys and scan codes. Everyone
would then use these names by having a TAKE command for the definition file
in their MSKERMIT.INI file.
Likewise, people could define files of code sequence names. Some obvious
sets of useful definitions are the mnemonics for ASCII control codes and
VT102 escape sequences. Again, many people could benefit from the work of
one person in setting up such definition files.
Once such definition files were available, people could redefine the
keyboard without having to think about scan codes, numeric values of ASCII
codes, or obscure escape sequences.
What do you think?
Roger Fajman
------------------------------
Date: Tue, 20 Jan 87 21:25:26 EST
From: Russell Nelson <bh01@clutx.BITNET>
Subject: Keyboard Translator
Keywords: Keyboards
Well, I have experience with two keyboard translators.
Freemacs
Freemacs is a programmable editor that supports the IBM-PC and Z-100. It is
freely copyable, hence the name, and source is available. I anticipate that
people will want to port it to other MS-DOS machines besides these two, and
of course you always have a keyboard problem. The module that contains the
dependent code has a keyboard translator that translates the keys into
strings. I use strings because the programming language is very string
oriented, and they are more self- documenting than numbers.
Windows
Windows will run on any MS-DOS machine for which a driver can be written.
Specifically, Windows has a keyboard driver, which translates the keycodes
into three sets of numbers: the required virtual keys (every driver must
supply them; they include all ASCII characters plus a few like F1 through
F10), the optional virtual keys (like Left, Middle, and Right for the
optional mouse buttons, F11 through F16, etc)., and the machine dependent
virtual keys. All but the machine dependent keys are standardized. F12
returns the same code for all machines on which it exists.
Both are reasonable solutions. I believe that the Windows version is better
IF you let the user input the names of the required and optional keys. The
code for the names can be looked up in a table. I think that it is
resonable to expect the user to look up the machine dependent keycodes.
-russ
GEnie: BH01
BITNET:BH01@CLUTX
uucp: decvax!sii!trixie!gould!clutx!bh01
------------------------------
Date: 28-JAN-1987 14:08:40
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
From: Chris Kennington (cjk@uk.ac.salf.r-d)
Subject: Bugs in WART
Keywords: C-Kermit, WART.C
I have been setting up the WART preprocessor as a general tool on my
MSDOS micro (i.e. not part of a unix or similar MAKE), and have found the
two following problems:-
1. It won't discard a comment on the states line (and so won't even
process its test-program). Correction is to insert a call
to "rdcmnt(fp)" in routine "rdstates()" if after the line
"if (isspace(c) ......" you come out with c == '/'.
Note that this problem shows up with a very odd diagnostic,
as the routine then attempts to insert a null state into
the table, and the algorithm always gives a match on a null
state.... You'd still get the diagnostic if there was
garbage on the line.
2. Under MSDOS using Aztec-C, because of the anomalous way that this
compiler treats '\n', you get a .c program output in which many
of the lines are separated by LFs, not by CRLF pairs (as required
by MSDOS). Feeding this to Aztec blows the compiler. The
outputs from printf() are OK, since Aztec puts in a CRLF pair
when '\n' is found in a format-string; but the copying
routines using "putc(c,fp)" calls come to grief. Simplest
cure I can think of (tho' not efficient) is to replace all
these calls by ones to "outc(c,fp)", where this is coded:-
outc(c,fp)
char c; FILE fp;
{
if (c == '\n') putc('\r',fp);
return(putc(c,fp));
}
For more generality, this could be conditionally compiled
with a simple macro for outc(), depending on a #ifdef.
I may do a bit more generalizing on the WART program, to make it
suitable for programs which have several state-tables in them, possibly
nested one within the other. If so, I will feed the resulting prog back to
you (both Lancaster & Columbia).
Chris Kennington (cjk@uk.ac.ucl.cs)
[Ed. - Thanks for the comments on Wart -- we'll put them in its "beware
file" for now.]
------------------------------
Date: Wed, 28 Jan 87 21:39:25 est
From: "Ray Moody" <aij@s.cc.purdue.edu>
Subject: Commodore-64/C128 Kermit
Keywords: Commodore-64 Kermit
RE: Inquiry in the Info-Kermit Digest V6 #3
The posting made several months ago is not mine, but I am currently
working on C64/C128 Kermit. Some of the features I _PLAN_ to add include
support for the C128 80 column screen and VT100 emulation.
I do _NOT_ plan to have this version of Kermit run in native 128 mode.
The 80 column screen can be accessed in C64 mode, and we are not out of
memory yet. I see no reason to seperate C128 Kermit form C64 Kermit.
If you have any features you want to have added to C64/C128 Kermit, please
send me Email.
Ray Moody
aij@s.cc.purdue.edu
pur-ee!s.cc.purdue.edu!aij
------------------------------
Date: Tue, 27 Jan 87 11:01:03 CST
From: Dave Capshaw <capshaw@MCC.COM>
Subject: Rationale for C-Kermit's approach to DTR?
Keywords: C-Kermit, DTR
What is the rationale for the way that C-Kermit 4D(061) manipulates DTR? To
hang up the phone, C-Kermit uses ioctls to explicitly clear and set DTR
which leaves DTR asserted even after Kermit exits. (This is what surprised
me.) What is the advantage of this approach over having DTR simply follow
the open/close state of the line?
[Ed. - The ioctl's are in the function tthang(), in the file ckutio.c, under
the Berkeley conditionals (apparently ATT-type systems do it another way --
setting the baud rate to zero). The code clears DTR, sleeps half a second,
then restores DTR. Are there any Unix wizards out there who can explain why
(a) this is necessary, or (b) why it should not be done. I hesitate to
simply remove the ioctl that restores DTR, because somebody must have put it
there for a reason... Also, I assume that close() does not affect the state
of DTR?]
------------------------------
Date: Tue 27 Jan 87 00:51:38-PST
From: Mark Crimmins <CRIMMINS@CSLI.Stanford.EDU>
Subject: Kermit for Apple // ProDOS?
Keywords: Apple II Kermit, ProDOS
There was some talk a while back in the Digest about various people
developing a version of Kermit for Apples that would (i) support 80 column
displays, and (ii) use the ProDOS operating system. I KNOW there's a demand
for this --- does anyone have a working version of such a thing yet?
Thanks,
Mark Crimmins
CRIMMINS@CSLI.STANFORD.EDU
------------------------------
End of Info-Kermit Digest
*************************
-------