SY.CHRISTINE@CU20B.COLUMBIA.EDU.UUCP (07/14/86)
Info-Kermit Digest Mon, 14 Jul 1986 Volume 5 : Number 1
Today's Topics:
Kermit Now Available for Atari ST
Info-Kermit-Request ID confusion
PDP-11 Kermit Binaries
Using VMS Backup with Kermit
Swedish characters in Kermit
RE: Swedish characters in Kermit
----------------------------------------------------------------------
Date: Thu 3 Jul 86 15:37:22-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Kermit Now Available for Atari ST
Keywords: Atari ST Kermit
This is to announce Kermit for the Atari ST series of personal computers,
contributed by Bernhard Nebel, Technische Universitaet Berlin
(NEBEL@DB0TUI11.BITNET). The program is written in DRI C, and is based upon
the OS9 version of Kermit, which was in turn based on the original (simple)
UNIX Kermit. The program transfers text and binary files, can do wildcard
sends, and includes the necessary settings for communicating with IBM
mainframes (parity, handshake, 8th-bit prefixing). IBM communications is
one major advantage of this program over the Kermit program that DRI has
been distributing with their GEM developers kit (and which they never
submitted to Columbia Kermit Distribution), and another is that this one
(unlike DRI's) actually employs the GEM user interface.
GEM Kermit does not provide a terminal emulator, nor does it manipulate
RS-232 parameters itself. Instead, it relies on existing accessories from
the desk menu to supply these functions. Bernhard has also supplied a
special IBM line-mode terminal accessory.
The source consists of C and header files, and there are also some
"uuencoded" binary files for the Kermit program itself and various
accessories and resource files. As originally submitted (via BITNET mail),
the file names had the prefix ST, but since that prefix was already in use
for Software Tools Kermit, I changed the names of the files from STK*.* to
AST*.*. In most cases this was a simple string replacement, but STKERM.*
became ASTKER.*. Also UUENCODE.C and UUDECODE.C became ASTUUE.C and
ASTUUD.C, respectively. I also changed (I hope) all internal references to
these filenames accordingly.
The files are available in KER:AST*.* on CU20B via anonymous FTP on the
Internet, or on BITNET from KERMSRV at CUVMA, and should appear within a
reasonable amount of time at Oklahoma State for UUCP access. ASTKER.DOC is
the documentation (in English), which includes installation instructions.
------------------------------
Date: Fri 11 Jul 86 13:50:11-EDT
From: Ken Rossman <sy.Ken@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit-Request ID confusion
Keywords: Info-Kermit-Request
My apologies to those of you who sent mail to Info-Kermit-Request and got
it bounced back to them with a "No such directory" error. We have been
moving files and directories around on the system lately, and the
redistribution list to which "Info-Kermit-Request@CU20B" points was moved
along with everything else, but the list was not updated.
It is fixed now. Sorry for any inconvenience. /Ken
------------------------------
Date: Mon 7 Jul 86 14:08:20-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: PDP-11 Kermit Binaries
Keywords: PDP-11 Kermit
For those who are able to transfer files from CU20B using FTP or NFT,
and who need the latest release of PDP-11 Kermit (for RSX, RT, or RSTS),
the 8-bit binary .TSK or .SAV images are now available in KB:K11*.*. These
are considerably smaller than the .HEX files in the main distribution, and
require no postprocessing. Thanks to Brian Nelson for sending them in on
diskette.
------------------------------
Date: Thu 10 Jul 86 09:19:47-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Using VMS Backup with Kermit
Keywords: VMS Kermit
Apparently, VMS Backup cannot create a saveset on disk with a blocksize
of 512, which is the blocksize used by VMS Kermit when you give the
"set file type fixed" command. To remedy this situation, Gary Stebbins of
DEC wrote a little procedure for converting VMS Backup savesets to and from
blocksize 512, to allow these files to be transferred with Kermit. Use of
Backup in this way permits convenient transfer of a group of unlike or
complex files in a single Kermit operation, such that all their FILES-11
and RMS attributes are preserved after transfer. Thanks to Bernie Eiben for
sending it in. The files are in KER:VMSBAK.DOC and KER:VMSBAK.BAS.
------------------------------
Date: Mon 7 Jul 86 19:32:24-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Swedish characters in Kermit
Keywords: Swedish characters
[Ed.- This is in response to those of you interested in getting Swedish
characters on your screen during terminal emulation using Kermit.]
Unfortunately, there's no "standard" version of Kermit that will display
Swedish characters on the screen, because there's no commonly accepted way to
represent Swedish (or Norwegian, or Finnish, or German, or Spanish, or Hebrew,
or...) characters in 7-bit ASCII. Old versions of IBM PC Kermit (the current
version is 2.29) have been modified to display Swedish characters from a
special font when certain 7-bit ASCII characters are received, but so far there
is no good, general solution to this problem, because of the lack of standards
(or more precisely, the lack of conformity to existing ISO standards). The
best person to ask about this would be Per Lindberg at the University of
Stockholm (Per_Lindberg_QZ@QZCOM). He advocates the use of a special console
driver to map between US ASCII and Swedish (or any other) characters.
Unfortunately, doing it this way would interfere with Kermit's built-in VT102
terminal emulation; the only way to get IBM PC Kermit to show Swedish
characters on the screen is modify the program. But then how do you make the
Norwegians, Finns, Germans, Spaniards, and Israelis happy? And then what about
the Turks, Russians, Armenians, Japanese, Cherokee, etc etc?
Since it is undesirable to modify the Kermit program for each new "national"
character set to be supported, a better solution might be to adopt a new
mechanism usable at runtime, something like the key redefinition mechanism
(SET KEY). But such a mechanism would probably be somewhat complicated,
because different systems use different methods to transmit "national"
characters:
(a) Selected 7-bit USASCII characters are redefined, for instance left
square bracket "[" might come out as an umlaut-A on a Swedish terminal.
(b) 8-bit codes are used to represent the national characters. This might
follow some proposed standard, or it might be completely system dependent
(the IBM PC or DEC Rainbow have built-in 8-bit characters, totally different
from each other).
(c) A shift-in/shift-out sequence might be used to switch between character
sets. This could correspond with the VT100's ability to switch in and out of
the alternate character set ROM, triggered by ESC ( 1, ESC ( 2, etc.
If anybody knows about a good, general solution to this problem that does not
require the program be modified for every new character set, please speak up.
- Frank
------------------------------
Date: 08 Jul 86 19:39 +0200
From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: Re: Swedish characters in Kermit
Keywords: Swedish Characters
**KERMIT, IBM PC and national characters.**
Yes, there *is* a standard way to represent national characters with a
7-bit code! Instead of adding more bits, the trick is to shift between
several character sets. The ANSI standard X3.41 escape sequence "SCS"
(Select Character Set) which is implemented in the VT100 and VT102
does this. ANSI X3.41 is related to ANSI X3.64, on which the VT100 is
based. This scheme is also an ISO and SIS (Swedish Institute for
Standards) standard. I suggest that you look up SIS 63 61 27 (ISO ESC
2/8 4/0 and ISO ESC 2/8 4/7 and ISO ESC 2/8 4/8).
My VT100-workalike can shift between vanilla ASCII and SIS using the
ESC ( A, ESC ( B etc. scheme. The characters [ \ ] { | } are umlaut
A:s and O:s (upper & lower case) on the keyboard, and the ANSI ESC
sequence shifts what the screen shows. There is a *big* difference in
difficulty learning which is what: I know without thinking which key
to hit for a left square bracket, but reading a C program with that on
the screen is awful. So I just switch what the screen shows, and no
problem.
BEGIN <flame>
wThe *problem* is IBM, who choose to use a non-standard 8-bit code for
representing national characters. Foo! ALSO they have the WORST
keyboard in history, with *both* USA and Swedish layouts. Double foo!
(They are different, [ is an upper-case letter, so we want it shifted).
END <flame>
To live with this problem, all communications software on their PC has
to talk 7-bit codes with the port and 8-bit codes with the screen and
possibly also with the keyboard. Your (a)-(b)-(c) scheme is sound. To
do this, I suggest you give KERMIT a character translation table for
I/O to COM:, and another table for keyboard layout. This, I beleive,
would solve the problem for all languages on the PC, be they Swedish,
Hebrew or whatever. The tables should be written in assembler (using
MACROs?), and linked with KERMIT giving an .EXE file which works on
swedish-modified PC:s. (Swedish keyboard layout, the right 8-bit codes
to the screen, the corresponding 7-bit codes to/from the port). Thus
nationally flavoured KERMITs can be distributed. (A luser can't hack
and link it, we have to do it and distribute diskettes, which we do
anyway).
The console driver I have been talking about is not a good solution.
However, IBM puts out a program called KEYBSV (KEYBNO for norway etc)
with *all* swedish PC:s which (I think) remaps the BIOS keyboard
driver. But since KERMIT reads the keyboard the hard way (?), this
won't help. (And you don't want to send 8-bit codes to the port!) I
have heard rumours that IBM has a paper with recommendations for
nationalizing software, have you seen it? (I have not). Do try to get
a copy of it, if it exists.
By the way, if you are implementing VT100 in KERMIT (which I think is
a very good idea), you might want to test it with my VTTEST program
which tests all features (and a few bugs...) in a VT100 (VT102). The
program is written in C, and runs under TOPS-10 and Twenex (Sargasso
C) and UNIX. If you don't already have it, I'll send it!
-- Per Lindberg (Per_lindberg_QZ@QZCOM.MAILNET)
QZ - Stockholm U. Computing Center
Box 27322
S-10254 Stockholm
Sweden
+ 46 8 654500
...enea!suadb!lindberg
(Im am not with the University of Stockholm, but the Stockholm
University Computing Center, which is another organisation).
------------------------------
End of Info-Kermit Digest
*************************
-------