info-kermit@ucbvax.ARPA (02/16/85)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Fri, 15 Feb 1984 Volume 2 : Number 6
Today's Topics:
Kermit for Fujitsu Micro 16s with CP/M-86
Kermit for Burroughs 6800
Guide to MS-DOS Kermit Files
New Unix Kermit Bug Report
Feedback on "ckwart.c", etc.
Sacred Characters, Cont'd
----------------------------------------------------------------------
Date: Fri 15 Feb 85 13:25:22-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for Fujitsu Micro 16s with CP/M-86
To: Info-Kermit@CU20B.ARPA
This is to announce Fujitsu Micro 16s support for CP/M-86 Kermit contributed by
Chris Barker, World Research Institute for Science & Technology, Long Island
City, NY. The program makes use of the Fujitsu's built-in ADM3A firmware for
terminal emulation, and runs at speeds up to 9600 baud. The 86KERIO module
submitted was for version 2.7 of CP/M-86 Kermit; I compiled it with the current
version, 2.9, without apparent problems. The files are:
KER:86*.A86 Source (all unchanged, except for addition of 86KERIO.FUJ)
KER:FJ*.* Help and hex files
available via anonymous FTP from CU20B. The author says he is also working on
MS-DOS Kermit support for the same machine.
------------------------------
Date: Fri 15 Feb 85 13:25:45-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit for Burroughs 6800
To: Info-Kermit@CU20B.ARPA
This is to announce Kermit for the Burroughs 6800, written in Algol by
Randy McLaughlin, Metro-II, St Paul MN. The following files are included:
KER:B68KERMIT.ALG Source of the B6800 Algol program.
KER:B68KERMIT.NDL NDL "request sets" to replace READTELETYPE and
WRITETELETYPE and associated DEFINE's.
KER:B68KERMIT.DOC Documentation for B6800 Kermit.
They may be anonymously FTP'd from CU20B.
------------------------------
Date: 05 Feb 85 19:54 +0100
From: Per_Lindberg_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
To: Info-Kermit@CU20B
Subject: Guide to MS-DOS Kermit Files
Hi, Frank (and all the rest of the Kermit crew at Columbia)!
I miss very much a file with a complete breakdown on all the MS-prefixed
files. Their number has grown beyond what is easy to manage. So, I made
such a file. Here it is. My apologies for any mistakes. Hope you can keep
it updated and include it in forthcoming releases of the tape. Share and
enjoy! -Per Lindberg
[Ed. - This very useful file, which guides your way through the
bewildering array of dozens of MS*.* files, is available in KER:MSAAAA.HLP
on CU20B -- the A's are so it will appear at the top of the MS*.* files in
an alphabetical listing, hopefully attracting some attention.]
------------------------------
Date: Thu, 14 Feb 85 16:13:46 est
From: Paul Placeway <paul%ohio-state.csnet@csnet-relay.arpa>
To: pritch@ohio-state.CSNET, sy.fdc%cu20b@csnet-relay.arpa
Subject: New Unix Kermit Bug Report
This may be old news, but I had problems bringing up Unix Kermit on a Sun
Microsystems (BSD 4.2) computer. (This is ckermit as of Feb. 13 on BITNET.)
Kermit would compile just fine, but would dump core when run. The fix is
simple: change line 751 of ckuser.c from
while (feof(tfile[tlevel]) && (tlevel > -1)) { /* If end of take */
to
while ((tlevel > -1) && feof(tfile[tlevel])) { /* If end of take */
The problem is that the Vax cc(1) changes the order of the check in the if
statement, but the Sun cc(1) dosn't, and so it trys to feof(tfile[-1]) which
gives a core dump.
Paul W. Placeway
The Ohio State University
(UUCP: cbosgd!osu-eddie!paul)
(CSNet: paul@ohio-state)
[Ed. - Thanks. The same thing happens on Pyramid and probably other Unix
systems too. This fix now appears in the distributed copy of ckuser.c.
Glad to hear that so little is required to make it work on the SUN.]
------------------------------
Date: Fri, 15 Feb 85 16:14:16 GMT
From: Chris (K) <cjk@ucl-cs.arpa>
To: info-kermit@cu20b.arpa
Subject: Feedback on "ckwart.c", etc.
Info & Frank:
1. WART Preprocessor:
This does not compile as it stands on 11/44 under Berkeley 2.8
due to use of compiler extensions:
- "unsigned char" not supported;
- the same member-name may not be used in two different
structure declarations unless the offset is the same.
Fix is to delete line 44 and change all /CHAR/char/; and to change the
member ->nxt of struct sym to ->next in lines 537, 596, 609.
After these changes, it compiles but bombs with core-dump due to
overlength printf string (see below). The culprit is "char *warning" on
lines 66-70. Split this into 3 separate single-line strings and output by
three fprintf's at line 137.
[Ed. - I ran into the same problems with Wart under Venix and they're
fixed in the current distribution copy, along with a replacement for
the index() function, which turns out not to be portable.]
2. "printf()" lengths.
The reason that wart bombed on Berkeley 2.8 is that printf() and its
derivatives use a 128-byte buffer, for unpacking the formatted string
into, before output. You are in dead trouble (with a core-dump) it any
printf formats to longer than this. I suspect that this is a more
stringent restriction than you will find in any of the micro-compilers.
For what it's worth, Aztec-C for Z80 rejects strings of more than about
150 bytes.
Please restrict the format strings used in printf() (& derivatives)
to a single line of text; and think carefully about the resulting
formatted length when strings are inserted by %s. In particular, you
cannot expect to include the whole of a kermit data block and always get
away with it.
[Ed. - Everyone who's been working on moving C-Kermit to
peanut-whistle Unix systems (like PDP-11's without I&D space) has been
bitten by the printf buffer problem. As a newcomer to Unix, I must
admit I was shocked that (a) there's any limitation at all, (b) the
limit is so small on some systems, and (c) no checking is done for
overflow. Various measures are necessary -- reducing the length of
string constants, mostly in ckuser.c; using (f)puts instead of printf
wherever possible. Some people are already working on this.]
3. End-of-File Markers (Visual).
I don't think I trust file transfers in general. It's very nice to
have some confirmation (apart from a matching closing brace) that the file
you have in your hand is the whole of the one that the remote should have
sent you. Could we have, as standard, something like a row of 30
asterisks at the end of every kermit source file?
[Ed. - Good idea. Some day when I have time to add them to the end of
1000 files... 30K of asterisks!]
4. Menu for Parameters.
The nicest way (at least to some minds) to set parameters on a micro
is an interactive menu. I've written one (in C) for the RML 480Z Kermit;
do you want it? It's not wholly transportable, but I can clean it up
before sending. It uses up & down arrows to select parameter, right and
left to toggle through up to 10 preassigned settings, alters a variable
(displaying individually assigned value-description) and optionally calls
an action routine as each is changed. 5 lines of help-text available on
each parameter. Not yet implemented is a facility to enter a hex or char
value for a parameter. No limit (except storage) to the number of
parameters it will handle. I'd have to get RML's permission to release
it, since they paid for the work; but I think it would be given. Of
course, this is not a practical way to set parameters in Server mode; but
I don't see Server being of much use on a single-user micro. I expect to
make the 480Z answer an incoming PSTN call and respond to GET/SEND; and
that's all.
[Ed. - ckuser.c does attempt to provide menus for commands and settings by
allowing you to type '?' any time in a command. This is "menu on demand"
-- the experienced user need not be constantly confronted with menus, but
inexperienced users can get them when needed. 'set ?' gives a menu of
parameters; 'set parity ?' gives a menu of the parity settings, 'help set
parity' gives a fuller explanation of parity, etc. All this works without
knowing anything about the terminal -- no termcap, curses, no reliance on
terminal-dependent function keys.]
5. General.
It'll be some time before I can do anything much with the new
C-Kermit, but it looks a fine job. In particular, it should be very easy
to extract the whole of the protocol and parameter handlers for use on
systems whose architecture and command-language differ markedly from unix.
I will feed back info as I get on with it. Thanks.
Chris Kennington.
[Ed. - Thanks -- that's the idea. We hope to use ckprot.w and ckfns.c as
the core of a new Macintosh Kermit -- the user and system interfaces will
be totally different.
There are a few other problems that have to be resolved, too. Perhaps the
biggest one is reworking the logic used in switching between connect and
protocol to prevent some Unix implementations from releasing and possibly
hanging up the line whenever one escapes back to command level. Herm
Fischer (HFISCHER@USC-ECLB) is working on this, plus some of the problems
listed above, while creating versions of C-Kermit for System III, PC/IX,
Xenix, etc. There should be some results to announce soon.]
------------------------------
Date: Fri, 15 Feb 85 02:21 EST
From: Paul Schauble <Schauble@MIT-MULTICS.ARPA>
Subject: Sacred Characters, Cont'd
To: sy.fdc@CU20B.ARPA
About two years ago I did a study for Honeywell on all of the then current
asynchronous communications protocols. The conclusion was that Kermit
could not be implemented on their mainframes because they reserved @ as a
non-changeable character delete. I believe that ARPANet users also have
problems with this character.
Because of the problems with various networks, forbidden characters have
to be specified by the user. Just provide a SET that can be put in the
start-up and assume that the implementor will build in those that are
sacred to the operating system.
You still have to communicate them to the other end.
What I would like to see is a Kermit II protocol, that can be
non-compatable with Kermit I. There is a lot of useful accumulated
experience now, and it would be a real shame to not be able to use it.
Kermit II would have windowing, sacred character negotiation, packet size
negotiation, and maybe multiple logical channels. Is this politically
possible?
Paul
[Ed. - I agree that these issues should be addressed by Kermit II --
there's not much chance of fixing all the Kermit I's out there. And while
we're at it we could add some other things too: dynamically changing block
check types (each packet tagged with its block check type, to avoid all
the stupid negotion and confusion presently required to switch among them,
and to allow Kermits to adapt themselves on the fly to changing line
conditions), automatic detection of parity, allowance for negotiations
occuring at any time during a transaction, a mechanism to allow a file
transfer to be interrupted and continued (e.g. when a diskette fills up),
etc, etc. But who has the time to write the specification, and who has
the time to write the many implementations? Actually, it might not be so
bad if the new C-Kermit is used as a starting point...]
------------------------------
End of Info-Kermit Digest
*************************
-------