SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (01/07/86)
Info-Kermit Digest Mon, 6 Jan 1986 Volume 4 : Number 1
Departments:
MS-DOS KERMIT -
New C-Kermit with Sliding Windows for PC-DOS
Revised Modules for MS-Kermit 2.28 jrd
Re: Fast PC/AT Kermit
My Two Cents on the MS-Kermit 2.28 jrd "Display Problem"
MS-DOS Kermit Terminal Emulation Query
MISCELLANY -
Apple DOS Kermit Bug
Kermit for NCR Decision-Mate V?
----------------------------------------------------------------------
Date: Fri 20 Dec 85 00:05:05-EST
From: Jan van der Eijk <OC.JAN@CU20B.COLUMBIA.EDU>
Subject: New C-Kermit with Sliding Windows for PC-DOS
I just finished a C version of Kermit for the IBM PC/XT/AT and DOS. It
supports the following:
Server
Dial command
Script files
Sliding window (full duplex only)
File Attributes
and the majority of the features from the Unix C-Kermit.
The file is called WKERMIT.EXE and the current version is 012. The sliding
windows part is not widely supported yet but the following systems/programs
do:
PRO-YAM Communication package for the PC
The SOURCE Public info
TCOMM Unattended bulletin board system.
Any updates will be posted on the following TCOMM system:
data only (301) 428 7931
If you have any questions direct them to OC.JAN@CU20B or to JAN VANDEREYK on
the previous mentioned TCOMM BBS. To upload WKERMIT to this system took
an effective rate of 63 CPS, while using sliding windows it would have been
around 100 CPS.
[Ed. - This is the first implementation of Kermit with windows that we have
received at Columbia. It is based on a previous release of C-Kermit,
version 4.2, edit number unknown; the current version of C-Kermit is
4C(057). Windows-Kermit is compiled in Lattice C and uses the Greenleaf
communication libraries (which do not support XON/XOFF). The source, .EXE,
and .BOO files are in PS:<KERMIT-W>, available via anonymous FTP from CU20B,
for evaluation only. You may use the .BOO or .EXE file even if you don't
have the Greenleaf libraries or Lattice C.
This is not a polished product -- it needs to be integrated with the
"mainstream" C-Kermit, the DOS interface fixed up a bit, and so on. The
reason for this posting is to get some experience and data on the windowing
option, especially when used over public networks like Telenet (which is the
normal way of getting to The Source, whose Kermit also does windows). I'd
be very interested in any performance measurements -- e.g. the transfer of a
particular file with and without windowing, over direct or dial connections
vs over public networks, with various window sizes, etc (the baud rate, the
size of the file in bytes, and the elapsed time required to transfer it in
each case).
I would appreciate it if everyone would refrain from fixing or changing the
program on the source level until a coherent release of C-Kermit can be
produced covering not only MS-DOS, but also Unix, the Macintosh, and VMS.
Also, an up-to-date version of the windowing specification and some
supporting documentation is available in PS:<KERMIT-W>KW*.*.]
------------------------------
Date: 2 JAN 86 13:15-MST
From: JRD@USU
Subject: Revised Modules for MS-Kermit 2.28 jrd
Updates to MS Kermit 2.28 jrd/2 as of the end of Dec 1985
From Joe R. Doupnik
CASS and EE, Utah State Univ
(801) 750-2982 (days) Bitnet user JRD node USU
MS Kermit 2.28 jrd has undergone some internal and external upgrading
since its original posting to Columbia Univ in late November. The responses
of numerous people testing it have helped a lot. Thanks guys. The significant
changes are listed below. Oh, yes. Files have renamed to current standards:
mssdef.h, and the .asm files msscmd,msscom,mssfil,mssker,mssrcv,msssen,
mssser,mssset,msxibm,msyibm,mssfin. (mssdmb.asm is gone.)
1. The single character command, C for Connect, is back.
Also fixed the parser to allow keywords within Kermit to be in mixed case.
2. X-packet problems -- fixed, I hope.
3. Interrupting reception of a file by typing ^C, at last, deletes or keeps
incomplete files as it should.
4. SET End-of-Line # command has been fixed to remove the suprious message
of "?Not confirmed"; the command actually worked despite the message.
5. A bug in server mode's (lack of) use of repeat prefixes has been fixed.
6. RUN whatever now displays a leading cr/lf before DOS's response.
7. The server mode display screen has been freed of stray messages and
retry counts, or so I hope.
[Ed. - One big problem with the MS-DOS Kermit server is that the DOS
programs it invokes -- and often DOS itself -- will put a message on the
screen and wait for the user to reply from the Keyboard; a disk problem will
evoke the familar "Abort, Retry, Ignore?" message, CHKDSK will ask you if you
want it to repair your disk if it finds something wrong (and REMOTE SPACE
invokes CHKDSK). So if the server hangs, it's probably stuck in this
manner, and there's not much one can do about it if the server is unattended.]
8. Filenames are not automatically expanded to be ???????.??? by typing the
escape key since the complete filename string is now a rather complicated
object (drive and path fields, etc).
9. Half duplex systems (eg, IBM mainframes) had a problem of not hearing a
packet if it were received too quickly after its own last transmission
(such as an EOF response). A new workaround waits 3 millisec (adjustable in
the code) before sending any packet in the hope of giving the other end time
to switch contexts from send to receive.
[Ed. -- 3 msec is about 3 character times at 9600 baud; this should be more
than adequate -- it certainly made the problem disappear for us, with our
own IBM mainframe. Ideally, the delay should be adjustable, and should be
zero for full duplex connections.]
10. A much more serious I/O problem has been displayed (machines going poof
or worse especially when Connecting). My best guess is timing problems in
the serial port interrupt handling code. This has been revised and
tightened considerably.
11. How to build Kermit from sources with various versions of MASM and
LINK. Worry no more; Kermit handles that now. Brief tutorial (yawn):
Kermit uses three program sections, CODE, CSTACK (was STACK), and DATAS.
My simple changes were to rename the old STACK section to be CSTACK (sorts
to later than CODE and earlier than DATAS) and place references to each,
arranged alphabetically, in the assembler header file, MSSDEF.H, where they
will be seen before any other code and hence also be in the desired
order-of-encounter.
One may link Kermit modules in any order at all, provided that MSSFIN is
mentioned last. A typical Link command file might look like this:
msscmd+msscom+mssfil+mssker+mssrcv+msssen+
mssser+mssset+msster+msxibm+msyibm+mssfin
kermit; or kermit/map, kermit.map;
12. Internally, code for the "% completed" message has been rewritten to
run more accurately and to work with files as large as 32 MB. Number of
Packets still turns over at 64586; that's a lot of packets.
13. The LOG command will now supply a filename of KERMIT.LOG if you don't
specify one, and logging now appends to the desired file (won't destroy
old text). One small comment on this version of Kermit is that in the
confusion of sending stuff hither and yon I apparently did both
Kermit> Log Prn (OK by itself), and
Control-PrtSc (ditto)
while within VMS Mail. My printer went into grahpics mode and slept hence
forth. Seems like both VMS and double printing is not a good combination.
Mail does bad things by itself due to the escape sequences emitted, but
double printing certainly is bad news for unknown reasons.
14. All filename handling has been strengthened. When attempting to write
to disk all read-only, hidden (system), and volume label files are "fully
protected" from Kermit.
15. Get and SEND. I have had to back off a little on GET's command line to
accomodate various filename constructions. We are back to the manual
whereby Get can have just one filename on its command line and that name
can have embedded whitespace and other printable characters. If a local
override filename is wanted invoke Get with an empty command and then
remote and local filenames will be requested by prompts. SEND, however, has
been modified slightly to also prompt for both names if its command line is
empty. For both commands, the remote name has leading whitespace trimmed,
but trailing whitespace is retained, and local filenames get full local
inspection.
GET and SEND permit the first character of a string to be a wild card by
saying "#" rather than "?"; the "#" will be translated to a "?". After the
first character of a string a "?" can be used as needed.
16. Disk I/O buffer sizes have been moved to the header file so you can
easily change them to suit local conditions. The logging (capture) buffer
is set to 256 bytes, up from 128, but the main data disk buffer ("buff") is
left at 128 bytes to keep the "% completed" display lively; note that DOS
does full sector buffering anyway.
17. An item of note. Giving the command REM DEL B:\JUNK to an MSDOS remote
server can lead to trouble if JUNK is a subdirectroy rather than a file.
DOS interprets this to mean DEL B:\JUNK\*.* (oops!) and asks the server
"Are you sure?". At this point the server Kermit hangs displaying the
message above and the server's operator must say something on the keyboard.
If he/she says N then DOS leaves the user in subdirectory B:\JUNK. It's a
DOS "feature" in at least version 2.11. On the other hand, simply sending
another file also named JUNK on B: results in a new file named B:\JUNK0001
if WARNING is on or a complaint if WARNING is off.
18. Z100 backspace bug fixed in MSXZ10.ASM.
19. A new version of the IBM screen handling module, MSYIBM, updated by Bob
Bolch for operation of Kermit under IBM's TopView has been heavily used by
me for a while with no problems. However, I don't have TopView (IBM's TV
demo disk works fine here). My system is a Zenith 151 PC and a composite
video monochrome monitor.
[Ed. - MSYIBM.TOP -- please try this if you use TopView, or even if you
don't, to make sure it does no harm on ordinary DOS systems. TopView setup
parameters are documented in MSVIBM.TOP.]
20. I haven't yet obtained a copy of Purdue's VT100 emulator package so this
version of Kermit still uses the Heath-19 emulation. A VT100 module which
works like a real VT100 sure would be nice!
Joe Doupnik
JRD on Bitnet node USU
[Ed. - This message has been considerably shortened for the digest. The
complete text, along with the new modules and any files mentioned above, are
in PS:<KERMIT-MS> on CU20B, available via anonymous FTP. Sorry, they are
not available on BITNET via KERMSRV -- after one or two further go-rounds,
the final result of all this will be installed as the official version
(probably 2.29) in all of the normal Kermit distribution areas.
The source files (ASCII text) are in PS:<KERMIT-MS>MSSS*.*. The object
files (8-bit binary) are in PS:<KERMIT-MS>MSSS*.OBJ. Documentation, in
the form of the messages we've had from Joe D., are in PS:<KERMIT-MS>MSA*.*.
8-bit binary .EXE files for the IBM PC/XT/AT are in PS:<KERMIT-MS>MSV*.EXE,
and corresponding ASCII .BOO files (decodable with KER:MSBPCT.BAS) are in
PS:<KERMIT-MS>MSV*.BOO. If you have trouble FTPing the .EXE or .OBJ files,
then either get the source and build from that, or else get the file
KER:AANETW.HLP, which gives hints about FTP'ing binary files from CU20B.
If you have other MS-DOS systems, like the HP-110 or -150, Wang PC, TI Pro,
Z-100, etc, please get the source files and try building and testing the
resulting .EXE, and pointing me at the .EXE if you can put it in a place I
can FTP it from. Copies of all the MSX*.ASM and MSY*.ASM modules have been
placed in PS:<KERMIT-MS>, but no object files yet.
Finally, I've added the fix for CR at column 80 that Joe added to MSYIBM
to the file MSYIBM.TOP. Therefore, I'd appreciate it if anyone who is using
TopView could try this module in place of MSYIBM.ASM and report if/how it
works, both under TopView and "up front". Is the performance any worse than
the TopView-less version? Should this become the regular terminal emulation
module for the IBM PC/XT/AT?
Thanks again to Joe Doupnik for the tremendous amount of work he's put in
and generously contributed.]
------------------------------
Subject: Re: Fast PC/AT Kermit
Date: 24 Dec 85 16:26:33 EST (Tue)
From: sdyer@BBNCC5.ARPA
I don't know what you're talking about. I regularly use MS-KERMIT on an AT
running DOS 3.1 with an 18.4mhz crystal (yielding an effective rate of
9.2mhz.) I haven't yet seen any problems related to this. I might mention
that my COM1: is located on the IBM serial/parallel card.
[Ed. - There seems to be a difference of opinion about whether Kermit
works on a souped-up AT. Can anyone suggest why it works for some people
and not others?]
------------------------------
Date: Tue, 24 Dec 85 22:01 EST
From: Larry Afrin <lbafrin%clemson.csnet@CSNET-RELAY.ARPA>
Subject: My Two Cents on the MS-Kermit 2.28 jrd "Display Problem"
I saw in the Digest a couple of msgs, one from Kathleen <last name?> and
one from Mike Iglesias, re "display problems" with MS-Kermit 2.28 jrd on old
(16K/64K motherboard) and Compaqs. I don't know about the Compaq side of
the issue, but I'm also running 2.28 jrd on a 16K/64K vintage 1981 IBM PC,
and I have had no hint of any display problems since I first assembled and
installed the program. For what it's worth, I'm running PC-DOS 3.10 with
ANSI.SYS installed, and I assembled 2.28 jrd with MASM 1.0 along with that
trick I documented in a msg you included in the Digest one or two issues
back. Maybe the display problems have something to do with how 2.28 jrd is
assembled and/or linked. (Hey, for a shot in the dark, it ain't so bad an
idea!) Oh, I'm also running a monochrome monitor off the standard IBM
monochrome monitor/ parallel printer adapter card.
-- Larry Afrin
Dept. of Computer Science
Clemson University
[Ed. - Another difference of opinion; "jrd/2" should link and assemble the
same way for everybody. Can someone pinpoint the problem?]
------------------------------
Date: Tue 31 Dec 85 13:39:13-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: MS-DOS Kermit Terminal Emulation Query
If a forthcoming release of MS-DOS Kermit were to include VT-100 emulation,
would anyone have any objection to removing the Heath-19 emulation? If so,
would the objections disappear if a VT-102 (with character insert and delete
functions) were emulated? Since code has been written at several sites to
make Kermit emulation a VT-10x, the question is whether to include it
alongside the H19 code, or to replace the H19 code altogether. In the
former case, the program would be that much bigger, and the implication
would be that other sites are invited to add emulation for still other kinds
of terminals (DG Dasher, IBM 3101 have already been suggested). I have a
vague preference for emulating only one kind of terminal, and allowing
others to be supported by turning Kermit's emulation off and loading a
console driver to emulate the desired terminal. What does everyone else
think?
------------------------------
Date: 30 DEC 85 AT 11:23:27
From: <MEDIN-T%cc82@nosc.ARPA>
Subject: Apple DOS Kermit Bug
Well my fears are confirmed. File xfer doesnt care what the checksum
received is. I dont know how this bug has continued this long either we
usually have very good com lines or nobody is using this kermit.
The bug is "very little attention is being paid to false returns from rpak"
In the case of received data no attention is being paid. Sigh!
The fix:
the stmt after label "rdat2" should be "beq rdat2d" since false is zero.
the 3 stmts starting with label "rdat2c" should be removed but the label
should be retained.
After looking at all the returns from "rpak" I am supprised that
the packet is used befor checking the checksum. It seems to me that the
whole packet is suspect if the checksum is in error. Anyway you probably
know more about this than I do.
Ted
milnet address "medin@nosc"
[Ed. - This message, and some further, more detailed information, has been
passed along to the Apple Kermit maintainers to see, and has been appended
to the Apple Kermit "beware" file, KER:APPLE.BWR.]
------------------------------
Date: Fri 3 Jan 86 14:09:50-CST
From: Bob Paver <CP.PAVER@MCC.ARPA>
Subject: Kermit for NCR Decision-Mate V?
I'm looking for a version of Kermit that will run on a NCR Decision-Mate V.
This system runs MS-DOS, but uses a 2651 UART rather than the more standard
8251. (MSGENER assumes the presence of the 8251 UART.)
Any help would be appreciated.
Happy New Year!
Bob Paver (512) 834-3316
Microelectronics and Computer Technology Corp. (MCC)
9430 Research Blvd, Echelon Building #1
Austin, TX 78759-6509
ARPA: paver@mcc.arpa
UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!im4u!milano!paver
------------------------------
End of Info-Kermit Digest
*************************
-------