19-Jan-90 2:27:30-GMT,27278;000000000001 Return-Path: Received: by watsun.cc.columbia.edu (5.59/FCB) id AA08698; Thu, 18 Jan 90 20:54:35 EST Date: Thu, 18 Jan 90 20:54:34 EST From: Frank da Cruz To: Info-Kermit@watsun.cc.columbia.edu Subject: Info-Kermit Digest V11 #3 Reply-To: Info-Kermit@watsun.cc.columbia.edu Queries-To: Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU Message-Id: Info-Kermit Digest Thu, 18 Jan 1990 Volume 11 : Number 3 Today's Topics: Announcing MS-DOS Kermit 3.0 MS-DOS Kermit 3.0 Questions and Answers New MS-DOS Kermit Book Available MS-DOS Kermit 3.0 Feedback Wanted Announcing HP-1000 Kermit Version 1.99D Query: C-Kermit Treatment of Modem Signals Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU, requests for addition to or deletion from the Info-Kermit subscriber list to Info-Kermit-Request@WATSUN.CC.COLUMBIA.EDU or to KERMIT@CUVMA.BITNET. Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. [Ed. - And apologies for the I-KERMIT ADD message mistakenly sent to I-KERMIT instead of LISTSERV. Some day I'll learn!] ---------------------------------------------------------------------- Date: Thu, 18 Jan 1990 12:00:00 EST From: Christine M Gianone Subject: Announcing MS-DOS Kermit 3.0 Keywords: MS-DOS Kermit 3.0 This is to announce the final release of MS-DOS Kermit 3.0, first announced for beta-testing in Info-Kermit V11 #2. Thanks to the thousands of you who participated in the short testing period. To recapitulate the major new features of 3.0, they are: . DEC VT320 terminal emulation. . Many additions to Tektronix graphics emulation, including features from the DEC VT340 (color, sixel, but not REGIS) and HDS2000/3000, suitable for use with mainframe versions of WordPerfect 4.2 and 5.0. . Saving of graphics screens on disk in TIFF 5.0 format, suitable for import into PC Paint, Ventura Publisher, Pagemaker, WordPerfect 5.0, etc. . True half duplex operation with RTS/CTS hardware handshake. . International character set support for both terminal emulation and file transfer. . Sliding window packet protocol. Problems reported and fixed during the testing period include: . Incorrect Attribute packet character set announcers. . Problems when receiving badly formatted packets 1800-2000 bytes in length. . Incorrect receive packet length after SET WINDOWS command. . Incorrect crosshair cursor report in Tektronix mode. . Automatic return to wrong text terminal type after Tektronix emulation. . Several incorrect special terminal character translations. . Incorrect operation of SET TRANSLATE INPUT. . Terminal lockup after failure to automatically enter 132-column mode. . Insufficient maximum allowed number of ANSI escape sequence parameters. . Nonfunctional 3COM BAPI network support. . Case sensitivity of ARGC, VERSION, and other special numeric variables. . Various minor escape sequence misinterpretations. The new files have been installed in the regular Kermit distribution "A" area, and are available over the networks via anonymous FTP from watsun.cc.columbia.edu (Internet) and from KERMSRV at CUVMA (BITNET), and by mail order from Kermit Distribution at Columbia University on a variety of magnetic media. Internet BITNET Description msvibm.boo MSVIBM.BOO BOO-encoded (printable) version of MSVIBM.EXE. mskerm.hlp MSKERM.HLP Summary of MS-DOS Kermit 3.0 features & commands. msr300.upd MSR300.UPD Description of new features in version 3.0. mskerm.bwr MSKERM.BWR Limitations and known bugs in version 3.0. mskerm.ed MSKERM.ED Detailed edit history of version 3.0. msvibm.vt MSVIBM.VT VT52/102/320/340/H19 terminal emulation summary. msvibm.tek MSVIBM.TEK Tektronix graphics summary (in preparation). mss*.asm,.h MSS*.ASM,.H System-independent source code. ms*ibm.asm MS*IBM.ASM IBM-PC/PS2-specific source code. msvibm.bat MSVIBM.BAT DOS batch program for building 3.0. msvibm.mak MSVIBM.MAK A makefile for building 3.0 under DOS with MASM. msvibb.mak MSVIBB.MAK A makefile for building 3.0 with Borland TASM. msvibx.mak MSVIBX.MAK A makefile for building 3.0 under Xenix. msvibm.lnk MSVIBM.LNK LINK command file for 3.0. Kermit Init/Command Files: mskermit.ini MSKERMIT.INI Sample initialization file, includes DIAL macro. msihay.tak MSIHAY.TAK Hayes modem dialing script (used with DIAL). msiem*.ini MSIEM*.INI Keyboard setups for use with EMACS. msiwp3.ini MSIWP3.INI New keyboard setup for mainframe WordPerfect. Utilities: mspeps.* MSPEPS.* Epson printer driver for EGA graphics screens. mspep4.* MSPEP4.* PC CP437-to-Epson character set translation. mspupc.sh MSPUPC.SH PCPRINT (transparent print) for UNIX. mspvpc.com MSPVPC.COM PCPRINT for VAX/VMS. msixse.* MSIXSE.* XSEND utility for sending directory trees. msuchk.* MSUCHK.* SCANCHEK utility to display keyboard scan codes. msulk2.* MSULK2.* LK250 keyboard driver. Binaries are available on watsun only, for FTP in binary (image) mode, in the kermit/bin directory: msvibm.exe The MS-DOS Kermit 3.0 executable program. mspeps.com Epson printer driver for EGA graphics screens. mspep4.exe PC Code-Page-437-to-Epson character set translation. msixse.exe XSEND utility for sending directory trees. msuchk.exe SCANCHEK utility for keyboard scan codes. Non-IBM Versions: The non-IBM-compatible versions of MS-DOS Kermit 3.0 are not done yet. Some (DEC Rainbow, Heath/Zenith-100) are currently in preparation and will be announced when they are ready. Volunteers are needed for the others (Victor, Sanyo, TI, HP, NEC, etc). In the meantime, the new mss*.* source files are incompatible with the old msu, msg, msx, msy, and msz system-dependent source files for the non-IBM systems. The .BOO files for the non-IBM versions, however, will remain available. Also, the old source files will be accessible for limited time (most likely until the next major release of MS-DOS Kermit) in kermit/old on watsun. Bootstrapping: For those who cannot use FTP to transfer the binary MSVIBM.EXE file directly, the MSVIBM.BOO is an encoding of MSVIBM.EXE into printable ASCII characters that should be safely transferrable over BITNET, e-mail, etc. Use your old version of Kermit to download this file to your PC, and then run any of the "BOO-file decoders" to translate it back into a runnable .EXE file. The following files are available for this purpose: msbaaa.hlp An explanation of the bootstrapping files and procedures. msbpct.bas A BOO-file decoder written in Microsoft BASIC. msbpct.c Like MSBPCT.BAS, but written in C for speed. msbpct.boo BOO file formed from MSBPCT.EXE based on MSBPCT.C. msbpct.* There are also versions of MSBPCT in assembler, Fortran, etc. If you have a C, Pascal, or other compiler, download the appropriate MSBPCT source code, compile it, and run it to translate MSVIBM.BOO into MSVIBM.EXE. If you only have BASIC, you should download MSBPCT.BAS and MSBPCT.BOO. Then use the former to create MSBPCT.EXE from the latter, and then use MSBPCT.EXE to decode MSVIBM.BOO (using the BASIC version directly on MSVIBM.BOO would take a very long time). Our deepest thanks to Professor Joe R. Doupnik of Utah State University (JRD@USU.BITNET) for the year of hard work he put in on this release, and for his continuing devotion to the Kermit effort over the years. Thanks also the many others who contributed to 3.0, particularly Terry Kennedy, Jack Bryans, John Junod, Bert Tyler, Mikko Laanti, Fred Richter, Hirofumi Fujii, Gary Stebbins, Drew Derbyshire, and Paul Whitmer. And for the accompanying utilities, thanks to Mark Buda, Terry Kennedy, Phil Benchoff, Mark Zinzow, R. Brooks Van Horn, and Frank da Cruz. More about MS-DOS Kermit 3.0 in the following messages. ------------------------------ Date: Thu, 18 Jan 1990 13:12:11 EST From: Christine M Gianone Subject: MS-DOS Kermit 3.0 Questions and Answers Keywords: MS-DOS Kermit 3.0 Here are the questions that came up most frequently during the MS-DOS Kermit 3.0 beta testing period: Q - I tried using the Latin-1 (or DEC-MCS) terminal character set, but I didn't get any special characters on my screen, only incorrect ASCII characters where the special characters should be. A - To see 8-bit text characters, you need an 8-bit no-parity connection to the host, and you must tell MS-DOS Kermit to SET DISPLAY 8 (7 is the default). In the 7-bit environment, you can still use an 8-bit character set if your host sends shift-in/shift-out codes (but see MSKERM.BWR). Otherwise you must use one of Kermit's 7-bit "national replacement character sets" (Italian, Norwegian, etc), in which brackets, vertical bars, etc, are replaced by national characters. Q - If none of Kermit's built-in terminal character is suitable for my language or computing environment, what can I do? A - Put a lot of SET KEY and SET TRANSLATE INPUT commands in your MSKERMIT.INI file. These commands override Kermit's built-in translations of outbound and inbound characters, respectively. Also remember to SET TRANSLATE INPUT ON. Using these mechanisms, you can construct an entirely new terminal character set. Q - Word-11 or other DEC PDP-11 or VAX/VMS applications do not seem to work right with 3.0. Screens are fractured, etc. A - Kermit's new VT320 terminal emulation is noticed DEC by operating systems like VMS 5.0 or later, causing them to send 8-bit control sequences which are ignored by MS-DOS Kermit unless you SET DISPLAY 8. SET DISPLAY 7 is still the default, for compatibility with earlier releases. Q - If Kermit does VT340 graphics, how come my SAS graphs don't come out right if I tell SAS that I have a VT340? A - Kermit implements many VT340 graphics features, including colors and sixels, but not DEC's REGIS graphics language, which is what SAS uses. There are no current plans to implement REGIS, which is huge. The VT340 features which are supported by Kermit can be used to best advantage with host-resident versions of WordPerfect (4.2 and 5.0) on VAX/VMS or UNIX. Q - Why do I have to SET FILE TYPE TEXT and SET FILE TYPE BINARY with 3.0 when I didn't have to do this in previous versions? A - During file transfer, version 3.0 does two things that previous versions didn't do: text file character set conversion, and conveying and using the file type given in the file attribute packet. If you want to approximate the old mode of operation, in which you did not have to (and indeed could not) give SET FILE TYPE commands, you can SET TRANSFER CHARACTER-SET TRANSPARENT (this is the default anyway) and SET ATTRIBUTE TYPE OFF. ------------------------------ Date: Mon, 15 Jan 90 10:34:09 EST From: Frank da Cruz Subject: New MS-DOS Kermit Book Available Keywords: MS-DOS Kermit 3.0 Christine M. Gianone, who you know as the editor of the Info-Kermit Digest, Manager of Kermit Development and Distribution at Columbia, designer of recent extensions to the Kermit protocol, author of recent pieces in Data Communications Magazine, PC Week, etc etc, has written a book on MS-DOS Kermit 3.0: "Using MS-DOS Kermit", Digital Press, Bedford, MA (1990). This book includes MS-DOS Kermit 3.0 for the IBM PC family on a 5.25-inch PC diskette. Printing should be complete by early- to mid-February. The short beta-testing period for 3.0 was due to the printing and binding deadline for this book+disk package. Chris's book is quite different from the earlier MS-DOS Kermit manuals. It is tutorial in nature, geared mostly towards the typical non-computer-expert PC user. It includes illustrated step-by-step instructions for program installation and hooking up your cables and modems, an introduction to MS-DOS, and chapters devoted to major Kermit topics including terminal emulation, file transfer, server mode, international character sets, script programming, features for people with disabilities, etc. Every concept is illustrated by examples. A complete command reference is included, along with tables of PC keyboard scan codes, Kermit keyboard verbs, and PC character sets, plus glossary, index, etc. The detailed technical appendices (escape sequences, etc) found in the previous manuals are omitted; this information is (or will be) available in other forms. "Using MS-DOS Kermit" is an excellent introduction to MS-DOS Kermit 3.0 and its new features, and the command summaries and tables also make it a valuable reference. The new book+disk package provides higher-quality documentation to a wider audience. Its tutorial approach will reduce the consulting burden on the organizational help desk. The book will give Kermit software a more "serious" and professional image in the corporate and government sectors, and in the press. Ultimately, the result should be increased popularity for Kermit, new inroads into the mass market, and some badly needed revenue for Kermit Development and Distribution at Columbia to keep the Kermit project alive. See the file MSKERM.HLP for availability and ordering information. Of course, the Kermit software itself remains free, copyable, and sharable, with source code openly available. Online documentation is available too, including: MSKERM.HLP - Expanded summary of MS-DOS Kermit 3.0 features and commands. MSKERM.BWR - The "beware" file, listing limitations, bugs, workarounds. MSR300.UPD - Description of the new features in 3.0. MSKERM.ED - Detailed edit history since 2.32/A. MSVIBM.VT - Description of terminal emulator escape sequences, keys, etc. MSVIBM.TEK - Description of graphics emulation features and escape sequences. MSKERM.DOC - The 2.32/A manual (long). Also .MSS and .PS versions. MS*.ASM,.H - The source code! (very long). All these files are new except for the 2.32/A manual (which still applies, since 3.0 is backwards compatible with 2.32/A). In addition, there are numerous supporting files (contributed script programs, key mapping files for various applications, notes and hints found in the Info-Kermit digest, etc). Those who don't have access to the book should be able to find whatever information they need in these files, and of course can tailor or combine these documents to produce whatever local documentation they need. ------------------------------ Date: Wed, 17 Jan 1990 14:13:12 EST From: Christine M Gianone Subject: MS-DOS Kermit 3.0 Feedback Wanted Keywords: MS-DOS Kermit 3.0 How is MS-DOS Kermit 3.0 working for you? We usually hear from you only if you have problems. We'd also like to hear about it when things are OK. Please let us know how you like the new features of 3.0 -- international character sets, VT320 emulation, the new graphics features, sliding windows, etc. Also let us know about any discoveries you have made: how to use the program with local area networks, host graphics applications, character sets, etc, that are not mentioned in the documentation. And of course, your problem reports and suggestions for additional features in future releases are always welcome. And if you have any interesting stories about how you or your organization are using Kermit, please send them in for possible publication in forthcoming issues of Kermit News (yes, the fourth issue is on the way!). ------------------------------ Date: Mon Jan 8, 1990, 19:16:46 EST From: Christine M Gianone Subject: Announcing HP-1000 Kermit Version 1.99D Keywords: HP-1000, RTE Operating System This is to announce version 1.99D of HP-1000 Kermit for the Hewlett-Packard 1000 series of computers with the RTE-6 and RTE-A operating systems, from Paul Schumann of E-Systems, Inc, Greenville, Texas, USA. This version replaces version 1.98 of September 1986. The major new feature is support for the D-Series multiplexer and drivers. The new files are available in the "D" area of Kermit distribution: Distribution Name Original Name Description HPMKER.SRC (many) Fortran Source Code HPMKER.SUB KERMIT.SBMT Interex program submission form HPMKER.INS KERMIT.ISTL Installation instructions HPMKER.LOD KERMIT.LOD Loader command file HPMKER.HLP KERMIT.TEXT Plain text help file HPMKER.MAK KERMIT.MAKE Makefile Binary files are not included, since these are not easily distributed on industry-standard magnetic tapes or over networks. According to the installation instructions, these files can be generated from the Fortran source (and in the case of the indexed help file, from KERMIT.TEXT). The source code consists of many files concatenated into one single file, HPMKER.SRC. Within this file, each original file begins with a line like <<< k6subs.ftn >>> to show the original file name. This file can be picked apart into its original files with a text editor or a simple program. Before attempting to build HP-1000 Kermit, be sure to reconstitute the original source files, and to rename the HPMKER files back to their original names shown above. If you have trouble getting these files onto your HP-1000 or building Kermit from them, you can order a native HP-1000 tape containing this program (including binaries) from Interex, the international HP user group. Many thanks to Paul Schumann for keeping this version of Kermit current, and for contributing it to Kermit Distribution! ------------------------------ Date: Sat, 2 Dec 89 5:21:22 MET From: Kristoffer Eriksson Subject: Query: C-Kermit Treatment of Modem Signals Keywords: C-Kermit [Ed. - What follows is an excellent discussion of some of the issues that are holding up release of C-Kermit 4F, which in turn is holding up release of C-Kermit 5A. The system-dependent aspects of C-Kermit are the result of contributions from dozens of programmers all over the world in the form of patches to patches, rather than a rational and consistent design effort. The code under discussion is in the ckutio.c module, and has reached a level of complexity that defies understanding and instills fear in anyone who would modify it, for fear of breaking something else which cannot be tested. Responses to Kristoffer and to Frank da Cruz, fdc@watsun.cc.columbia.edu, from UNIX programmers who might be able to help untangle this mess would be most appreciated.] I have made some modifications to ckutio.c for some new features, which made it necessary for me to try and understand how kermit handles O_NDELAY and CLOCAL on System V, and the corresponding facilities on other systems. My conclusion so far, is that Kermit does not handle them in a concistent manner, at least that is what I think now. Now, to be able to continue with my new features, I need to fix this. To do that without breaking anything at the same time, I need your help. I need to know which parts of the current behaviour are intended, and which are not. I need to know the consequences for systems other that SysV, because that is the only one I have experience with. I need to know the consequences for the routines that call on ckutio.c of changes in it. I have studied ckucon.c and ckudia.c, but there are some other routines that call ckutio.c, which I understand much less. I know there are many systems with flawed or in other ways strange tty drivers. I need to know any considerations that should be made for those. I'll describe my understanding of O_NDELAY and CLOCAL on SysV. Let me know if you disagree. You usually use O_NDELAY in the open() call to open a tty device without blocking until there is a carrier present on that port, in case the device has modem control enabled as default. When you operate a modem on that port, you usually don't want to wait for a carrier, since most modems don't provide a carrier until you have dialed somewhere to, which you can't do if you can't talk to it. Ok, many modems can be configured to alwayes provide a carrier, but then you can't be disconnected automatically when the connection eventually drops. Kermit uses O_NDELAY on the open() in ttopen() if you have set a modem type prior to the "set line" that causes ttopen() to be called. O_NDELAY also affects read()-ing from the device. If there is nothing to read (empty input buffer or dropped carrier), read() will finish immediately returning 0 (the return value maybe will change/has changed in V.3 or V.4, I don't know). You might want this behaviour sometimes (tell me if you think Kermit does want it), but usually it is much more convenient to use the VMIN/VTIME timed read in SysV, and Kermit does use VMIN/VTIME. With O_NDELAY you would have to constantly loop on read() until you receive something. However, if you turn off O_NDELAY, and use the VMIN/VTIME settings that Kermit does, you have to find some other way to make the device ignore the carrier absence, if you are going to talk to your modem. You use CLOCAL to do that. You couldn't have used CLOCAL to open the tty to begin with, since CLOCAL is set through the ioctl() interface, which only works on already open files. But once you have opened the file, you can set CLOCAL, and unset O_NDELAY. Kermit sets CLOCAL when you dial, through a ttpkt(..., DIALING, ...) call in ckdial() in ckudia.c. Once you are finished commanding the modem, and have established a connection and a carrier, you can unset CLOCAL so you will get an EOF when the connection goes down. Kermit does that with a ttpkt(..., CONNECT, ...) call at the end of ckdial(). If you have a direct connection that always gives a carrier, you need never set CLOCAL. So far, all seems well. However, O_NDELAY is not always unset, only sometimes. I think this is wrong. I think O_NDELAY shoule always be unset at some time before beginning to dial or connect. ttopen() leaves O_NDELAY set. ttpkt() and ttvt() (ttvt is used by for the "connect" command) unset O_NDELAY only when called with flow==DIALING. Thus, for a direct connection where you do not dial prior to connecting, O_NDELAY will remain set, unless I'm very mistaken. By the way, I have not found any place where ttvt() is called with the parameter "flow" set to either CONNECT or DIALING, but ttvt() nonetheless handles those cases. ttvt() looks to me like a mutated ttpkt(), so maybe those cases where just left in by accident? Can they safely be removed? After unsetting O_NDELAY, these functions perform some "magic" ( close(open(...) ). What systems need such magic? Can someone explain how myread() works, especially the part where the return value after an empty read is dependent on whether you have set a modem type or not (ttmdm) and the loop around myread() in ttinc()? I find it a bit strange. What does the return values mean? I wonder whether this might be an effect of O_NDELAY remaining set sometimes? The condition ttmdm == 0 may during some phases coincide with O_NDELAY remaining set, but not always. Is that the reason for testing ttmdm? In the end, ttres() also unsets O_NDELAY, this time without any magic, but only for UXIII, and only if ttmdm != 0 (you have set a modem type). Is there any other reason for this than as a late repair of the missing unset earlier? ttres() is supposed to restore the tty to "normal". I wonder what this "normal" mode is? If "normal" is the mode it had before dialing an connecting, I don't think it will restore O_NDELAY to that state. I'm tempted to suggest that it should be left alone, and to other functions fixed to always unset it, but I am not sure that is the intended state either. If some very early state is intended, which might be the case if ttres() can be called in an very early state, e.g. via ttclos() if you change lines without using the first line, maybe O_NDELAY should be turned on again? tthang() closes and reopens the tty, except on Xenix systems. This open of courses also blocks for carrier on my system if the O_NDELAY flag is not used, exactly like the very first open. The open is performed with the same fcntl flags as the file had before being closed. O_NDELAY is a fcntl flag. But O_NDELAY is not always set at this point. It has been unset if you have used the dial command, as I outlined before. I have patched this to force O_NDELAY on the open, and restore to the original state afterwards. Any comment? Why is the tty closed at all? Shouldn't it suffice to set a zero baud rate, just as the manual says? (It does suffice on my system.) When the last open file descriptor to the tty is closed, it resets the communications parameters to defaults (especially after dialing, when HUPCL has been set explicitely). That is why CLOCAL will not remain on to enable a painless new open. Is it wise to use the "flow" parameter of ttpkt() and ttvt() both for setting XON/XOFF flow controll and for indicating DIALING/CONNECT mode? Will there never be any clash? What mode is it when it is not DIALING or CONNECT? On many systems there is another solution to the problem of how to open and read without blocking for a carrier. They have more than one device name (or can have them created with mknod) for the same tty port. One name enables modem control by default, and the other disabled it. Kermit does not know about these different names, so it just uses what the user gives it. I have testet that on SCO Xenix. I think it behaves somewhat strange on that system, and not to my liking. The driver simply ignores my setting of CLOCAL, and only uses the default for that device name, always. Are other systems like that, too, or is just that Xenix is strange as always? I think that's most of what I had on my mind. Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone:+46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske ------------------------------ End of Info-Kermit Digest *************************