About the Kermit file-transfer protocol and about terminal emulation under various Kermit implementations (archives of various Usenet discussions) -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- 2002: Newsgroups: comp.protocols.kermit.misc Message-ID: Organization: Columbia University Date: 1 Dec 2002 10:11:53 GMT From: Jeffrey Altman Subject: A Letter to the Kermit Community 1 December 2002: Today marks the end of a significant period in my life. For the last eight years I have been privileged to work on and support Kermit as my career. I began working for Columbia University after nearly seven years as a Kermit user and eventually as primary developer of OS/2 C-Kermit which became the basis for Kermit 95 on Windows 95/98/ME and Windows NT4/2000/XP. During this time the Kermit project shipped 23 releases. The initial version of K95 was shipped on Oct 5, 1995 just seven months after I joined Columbia University. K95 was not only a port of OS/2 C-Kermit to Windows but an attempt to make C-Kermit easy to understand for beginners by adding a Graphic Front End and to do so in a manner that would be inherently cross platform. Back then our dreams were to build a front end that could be supported on OS/2 and 32-bit Windows with the ability to easily port it to MacOS and X-Windows. At the time our development platform had to be selected, Java was not even announced to the world. (That occurred in early August 1995.) We selected Zinc as our cross platfrom development environment. Unfortunately, cross platform development environments that wrap existing OS components tend to be lowest common denominator feature sets and result in apps that are not entirely what the end user expects. (Java discovered this with the original AWT library and eventually constructed the Swing library to avoid the OS dependencies.) For Kermit, the reliance on Zinc allowed us to easily support both OS/2 and Windows but resulted in significant compromises in features as the years went on. The Zinc library was not only lowest-common- denominator but also suffered from two significant problems: . it is a memory and GUI resource hog . the authors never checked memory buffer overwrites These two issues resulted in significant problems in pre-1.1.21 releases of Kermit 95. First, as the number of configurable items in the Settings Notebook increased the required GUI resource allocation increased to more than 30% of the total GUI resources available on Windows 95/98/ME. This would result in unpredictable crashes. The memory overwrite bugs were primarily caused by a failure to allocate enough memory for path names. The Zinc library was originally developed to support DOS, 16-bit Windows, and OS/2. The 8.3 filename restrictions, coupled with the limited drive space available on those systems, resulted in short pathnames. It seems they never anticipated that anyone would want a pathname greater than 64 characters. Now with today's GUIs, coupled with removal of the 8.3 restrictions, it is common for the filename alone to be 64 characters, not even considering the rest of the pathname. The memory overwrites produced data corruption in the Zinc databases that stored the Connection Configurations. The problems became more obvious as users switched to Windows 2000 and began to install K95 in directories with long pathnames or across network shares access via UNC names. For 1.1.21 and later these issues were addressed by a combination of extensive debugging of the Zinc libraries coupled with limiting the number of GUI resources allocated at once. It is due to the latter that the Settings Notebook was broken up into separate (although annoying) settings pages. I'm not going to say that the choice of Zinc was a disaster, but in hindsight it would have been better if the decision to use Zinc could have been put off until Java for desktop development began to stablize. However, waiting until mid-1997 was not an option and now that Zinc has been deployed Kermit 95 has become dependent on its database format. Any attempt to migrate to something else would require either abandoning the existing user data or re-implementing the Zinc database format in the new language. Neither are desireable, nor did we ever have the resources. The use of Zinc did succeed in its initial goals: construct a GUI front end for C-Kermit that would reduce the need for end users to understand the C-Kermit command language in order to configure and establish connections to hosts over a wide range of connection types; and do so on multiple operating systems on multiple architectures in a manner that allowed for database portability. The initial versions of K95 were shipped on OS/2 (X86) plus Windows 95/NT4 (X86,MIPS,Alpha,PPC). We even had a PowerPC version for OS/2 but it was never publicly released since the operating system itself was never released. It was possible to use a single Dialer database on multiple operating systems in multi-boot scenarios. At one point I had a database shared by OS/2, Windows 95, NT4, and Windows 95 (Hebrew edition.) Porting OS/2 C-Kermit to Windows was a challenge in itself. C-Kermit is a single threaded application. OS/2 C-Kermit is multi-threaded (separate threads for command processor, keyboard/mouse input, screen display, and device/network I/O processing) but it can count on all thread independent signals being delivered to the first thread in the process. In Windows, thread-independent signals are delivered to the process in their own thread. To this day I am still not satified with the cross platform model I developed to handle events such as SIGINT. The existing implementation works well enough for most purposes and there have always been an endless number of new features to add to K95 such that I have never had the time to re-visit the design of this fundamental building block. Looking back over the last eight years it is somewhat incredible to think about what was achieved. In 1995, the source code for K95 was less than 80,000 lines in total. The executable for the Windows X86 was 786k. For the 2.1 release the base source code over 500,000 lines of code not including support for SRP, Kerberos, SSL/TLS, and SSH; the k95g executable is 3566.5K. The security protocol support adds another 1.2 million lines of source code plus almost 3MB in supporting DLLs. Then there is all of the documentation that was written: 88,000 lines (the original release had 5235 lines of documentation.) [This does not include the "Using C-Kermit" book which Frank and Christine were able to update only once during this time frame. To accommodate all of the new documentation which has been written, an updated "Using C-Kermit" current with version 8.0 would need to be 1800 pages in length.] I tried to look back and summarize all of the features that were added to Kermit in the last eight years and I became overwhelmed. There were 35 plus terminals that were emulated; streaming Kermit protocol; the Internet Kermit Service; all of the IETF work (TELNET AUTH SRP, TELNET AUTH KRB5, TELNET START-TLS, TELNET FORWARD-X, PKIX, TLS, KERBEROS 5, SSH 2, FTP AUTH TLS; TN3270 extensions; DNS SRV); UTF8 terminal support; URL hotspots; mouse event programming; Windows Telephony; DECNET; TELNET; RLOGIN; KLOGIN; Remote COM-PORT-CONTROL; HTTP; FTP; all of the security implementations; Bidirectional Printer Management; the GUI release; export permission; and thousands of other things that I just can't summarize because (to be honest) I can't remember. I tried to use the Internet Wayback Machine http://web.archive.org/web/*/http://www.columbia.edu/kermit/k95.html but it's almost as if everything on the current k95.html page is new. One of the greatest aspects of my work on Kermit has been that the impact of my work has not been limited only to the Kermit product and its users. Through Kermit I have participated in the Internet Engineering Task Force on numerous working groups and have either authored or edited over two dozen Internet-Drafts and RFCs. In addition, I have been an active contributor to various OpenSource projects: OpenSSL; MIT Kerberos; Tom Wu's Secure Remote Password distribution; Peter Runestig's Secure Telnet and FTP clients and servers; Denis Sbragion's Sredird Telnet Com-Port-Control daemon; plus many others. I participated as an unofficial observer in the Commerce Department BIS advisory council meetings on export control. Plus I was able to work with purely commercial companies to help them ensure that their products were compliant with protocols implemented within Kermit. With all of this there is always more that I wish I could have accomplished. We never did implement TN3270/TN5250 within Kermit. Nor did we ever port the terminal emulator to MacOS or X-Windows. The BeOS port never truly worked and we don't support PalmOS or Windows CE/ PocketPC devices. The Internet Kermit Service never received wide enough support from OS vendors such as IBM, Sun, HP, Compaq, and RedHat. Support for security features on VMS is still not complete. We never got to develop a drag/drop file transfer interface for Kermit, Zmodem, and FTP. But overall I believe that Kermit 95 is a very good product that in many ways probably does too much. :-) Unfortunately, my time to work on Kermit as a Columbia University staff member has come to an end and it is time for me to move on to other endeavors, even if I am not quite sure what they will be. I still consider myself a member of the Kermit Project even if I am not paid to be. Kermit has been a part of my life for fifteen years. It was a lab for me when I was in college and then grad school. When I got my first job as a developer after receiving my Master's, I continued to work on C-Kermit eventually taking the reins of the OS/2 port from Kai Uwe Rommel. I left that job for Columbia because the 20 hours a week I was spending on Kermit was a lot more enjoyable than the work I did for my employer. I can't imagine how it would be possible for me to simply give it up now but my work on Kermit has caused me to grow far beyond what is possible within Kermit. Therefore, Kermit is going to have to become a smaller piece of my life. My participation in open source projects such as MIT Kerberos and OpenSSL will continue. My participation in the IETF will continue. Over the last year and a half I have become very interested in Peer to Peer overlay networks and purely distributed authentication systems. I have been active in the Project JXTA community (http://www.jxta.org) and currently sit on its Board. I have been actively pursuing the creation of an IETF P2P Working Group to standardize a suite of P2P protocols; and an IRTF P2P Research Group to study the effects of P2P overlay networks on an Internet containing 10^14 nodes (today's Internet has less than 10^9 nodes.) It is my hope that my next employeer will provide me the opportunity to continue this work. In the meantime, I will be available on a contract basis through Internet Access Methods (http://www.iamethods.com) / (http://www.iamx.com) for development or consulting work on Kermit; Peer to Peer systems; or various Security efforts. I can be reached either at jaltman AT columbia.edu or jaltman AT iamx.com. Last but not least I want to say thank you to Frank da Cruz, Max Evarts, Christine Gianone, everyone I've worked with at Columbia University; and all of the wonderful users that have supported Kermit over the years most notably: Peter Runestig, Mark Zinzow, Kent Martin, Arthur Marsh, Perry Wolfe, Robert Strickler, Greg Belenger, Clarence Dold, Thomas Dickey, Jim Schneider, Vincent Fatica, Gene Alexander, and everyone else whose name I can't pull off the top of my head. Without you Kermit would not be any fun at all. Jeffrey Altman Volunteer Kermit Developer -- Jeffrey Altman * Volunteer Developer Kermit 95 2.1 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc References: Message-ID: Organization: Columbia University Date: 1 Dec 2002 14:25:47 -0500 From: Frank da Cruz Subject: Re: A Letter to the Kermit Community In article , Jeffrey Altman wrote: : : Today marks the end of a significant period in my life... : Looking back over the last eight years it is somewhat incredible to : think about what was achieved... Anyone who has been following the goings on here since 1995 knows Jeff's key role in most of it, if only by his over-the-top devotion to 24x7 end-user support: http://www.columbia.edu/kermit/tsreviews.html Jeff is an extremely talented and hard-working person; we were lucky to have him and are unlucky to lose him. Ironically, Jeff's main passion over the past 5 years or so--security--is precisely what should have sealed our success, yet the market did not respond. Kermit 95 was one of the first, if not THE first, full-featured Windows communication software packages to support Kerberos IV, Kerberos V, and SSL/TLS, as well as the lesser-known Secure Remote Password, each of which offers MANAGEABLE secure authentication and strong encryption. But it turned out that, despite the many earlier requests for it, nobody actually wanted *manageable* security (because it must, indeed, be managed), and instead flocked towards SSH, which in many ways is a disaster waiting to happen: http://www.columbia.edu/kermit/sshclient.html#x3.2 This was a setback for us, because instead of concentrating on GUI development, essential not only in the mass market but also to many of our potential large licensees, we had to drop everything and add SSH to K95, which took a year, just so people could keep using K95 in an environment where Telnet servers were being turned off (rather than secured) and SSH was suddenly required for terminal connections. We had expected that at least some of the larger corporations and government agencies would be more serious about security. Live and learn. : One of the greatest aspects of my work on Kermit has been that the : impact of my work has not been limited only to the Kermit product and : its users. Through Kermit I have participated in the Internet : Engineering Task Force on numerous working groups and have either : authored or edited over two dozen Internet-Drafts and RFCs.... Shamefully this kind of activity is no longer valued in most workplaces. Devotion to standards and participation in their evolution rarely contributes to the bottom line, and are increasingly discouraged if not punished in these hard times except in the few companies that can still afford it -- a trend which has consequences for us all. : ... But overall I believe that Kermit 95 is a : very good product that in many ways probably does too much. :-) A common theme in the evolution of any software product. It starts out small and focussed; users request more features; the market makes new demands (such as SSH); the product becomes increasingly complex and "bloated"; eventually users begin longing for the good old days when the product was "lean and mean". But of course they can't go back to the original release because it lacks certain essential features that were added later--a different set of them for each user! Perhaps our mistake has been to listen too closely to our users and try too hard to please. Other products tend to displace K95 by offering users very little in terms of features or choices, and therefore are perceived as easier for most people to use. Kermit's strength, however, lies in its ability to be adaptable to almost any setting; perhaps it is best suited to situations in which professionals can configure it for end users -- employees or clients of a company, the population of a university, workers in a government agency. This is done through its command scripting language, which allows complex or repetitive procedures (such as EDI transactions) to be "canned" for use by relatively unskilled workers. I would like to think the value of this approach will become apparent as we suffer increasingly through the labor-intensive, error-prone, point-and-click interfaces that are coming to dominate the workplace and drag down productivity. : I still consider myself a member of the Kermit Project even if I am : not paid to be. I can't predict how much time Jeff can devote to Kermit in the future. Even if it's only 10% of his normal contribution, that's about a full-time job for anybody else :-) But let's not take this as an epitaph for Kermit 95. We have just released version 2.1, which is totally up to date with all the latest Kerberos, OpenSSL, and other security libraries, and seems so far to be quite solid. It's easy to install and easier to use than ever. It's easier to get too. As long it remains popular I'm sure Jeff won't forget about it. In any case, we intend to continue to develop and support it, as we always have done. If that changes, I'll let you know. Kermit 95 2.1 has just now gone to press. The new shrinkwraps--which, for the first time, contain the secure cryptographic version of the software -- should be available towards the end of December. You can preorder them at the old price starting today: http://www.columbia.edu/kermit/k95order.html Thanks, Jeff. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc References: Message-ID: <8ce22d01.0212021110.77c49d5a@posting.google.com> Organization: http://groups.google.com/ Date: 2 Dec 2002 11:10:28 -0800 From: Dan Skinner Subject: Re: A Letter to the Kermit Community jaltman@watsun.cc.columbia.edu (Jeffrey Altman) wrote in message news:... > 1 December 2002: A day that will live in infamy! Jeff; a comment from a Kermit newbie.(First use August 1990). You and Frank and all have lived up to a support model that is as different from its competitors as C-Kermit and K95 are different from their competitors, and that is a GOOD THING :-) I've tried to model my little company's products and services on your good example, down to absurdly low prices. How can I help you make it work, rather than How can I avoid responsibility is a model and a style that will always be in fashion! THANK YOU!!! Good Luck and Good Computing. Best Regards^ÅDan. JDanSkinner.com -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc References: <8ce22d01.0212021110.77c49d5a@posting.google.com> Message-ID: Organization: Columbia University Date: 2 Dec 2002 14:58:26 -0500 From: Frank da Cruz Subject: Re: A Letter to the Kermit Community In article <8ce22d01.0212021110.77c49d5a@posting.google.com>, Dan Skinner wrote... : : I've tried to model my little company's products and services on your : good example, down to absurdly low prices. Good luck. It's nice to know that some people still believe in such notions, which are largely held to be "legacy, deprecated" concepts long ago replaced by the more up-to-date "take the money and run". The best way to keep the old ideas alive is to not be shy about spreading the word across our wonderful Internet. In Kermit's case, it's especially important since most people still believe that it hasn't changed since 1983. "Kermit, oh yeah, I remember that, I used in college... A nice little toy for its time... What ever happened to it?" We have a web page to refer people to when they say things like that: http://www.columbia.edu/kermit/kermit.html To this day, people cling to incredibly clunky, obscure, and unsafe methods of doing things (such as automating an FTP session) that would be perfectly straightforward with C-Kermit or K95. My favorite is when someone asks how to do something involving recursive directory traversal in Unix (deleting files, moving them, transferring them, whatever) -- something that can be done in one simple command in Kermit, like: delete /recursive /before:1-jan-2000 *.txt The conversation rapidly devolves into heated arguments over the syntax of "find" and "xargs" versus various Unix versions and shells, and then over the ensuing week or two into insults and death threats, before it finally veers off on some tangent, such as English versus metric units of volume, weight, or mass as applied to bottles of beer. We need independent Kermit users to pop up on the newsgroups when people ask "How do I do such-and-such?" and Kermit is the obvious and sensible answer. Jeff and I do this a lot, but people would pay more attention if they heard it from a variety of actual users who benefit from it in real life. Why should they trust us? Yes, if you post on newsgroups you get spam. I get tons of it. It's annoying, but that's all. There are many worse things in the world, starting with unemployment. "Up with Common Sense!" Our new slogan? It's an inversion of Gracie Allen's campaign slogan in the 1940 presidential race. (Where is she now when we need her?) http://www.geocities.com/Hollywood/Hills/1836/campaign1940.html - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!emory!gatech!udel!news.mathworks.com!news.alpha.net!uwm.edu !lll-winken.llnl.gov!sol.ctr.columbia.edu!news.columbia.edu !watsun.cc.columbia.edu!fdc Message-ID: <3at022$rfc@apakabar.cc.columbia.edu> References: Date: 22 Nov 1994 14:43:14 GMT Organization: Columbia University Lines: 26 From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: re-dial in kermit 3.12 In article , Vito Kwan wrote: > > I am using MS-DOS kermit on my PC and try to find out how to re-dial > a phone number at a certain time interval, like 5-seconds. > Could someone please give me some hints? > Read the chapter on script programming in the manual? Use any of the standard dialing scripts, which already do this? Once again, the manual is: Christine M. Gianone, "Using MS-DOS Kermit", Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1992, 345 pages, ISBN 1-55558-082-3. Packaged with version 3.13 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 3.5-inch diskette. US single-copy price: $34.95; quantity discounts available. Available in computer bookstores or directly from: Kermit Development and Distribution Columbia University Academic Information Systems 612 West 115th Street New York, NY 10025 USA Telephone: +1 212 854-3703 - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.terminals,comp.sys.ibm.pc.misc Path: utkcs2!gatech!destroyer!caen!hellgate.utah.edu!cc.usu.edu!jrd Message-ID: <1992Oct9.142143.59575@cc.usu.edu> References: <1992Oct5.021247.22556@samba.oit.unc.edu> Organization: Utah State University Lines: 23 Date: 9 Oct 92 14:21:43 MDT From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Inexpensive Tek 4014/DEC VT220 Emulator? In article , jt@fuw.edu.pl (Jerzy Tarasiuk) writes: >>>>>> On Mon, 5 Oct 1992 02:12:47 GMT, sdoublie@med.unc.edu (Sylvie Doublie) said: > (some lines deleted) > Sylvie> connect by modem to computers at her lab. She needs the > Sylvie> program to emulate both Tek 4014 and DEC VT220 terminals. She doesn't > Sylvie> have much money to spend, so she'd like to get a [free or cheap] > Sylvie> program, but an inexpensive commercial application will suffice. > > > KERMIT can emulate Tek 4010 and DEC VT100, VT220, VT320 (at least > version 3.11 which I use just now to write this message). > And it at least can be tried free, get it (e.g. by FTP) and read > docs to know if she need pay (for commercial use would need). ----------- All accurate except for the very last point. Kermit USE is always free. Financial arrangements come into play when a Columbia Kermit becomes part of another product package offered for sale. The Kermit Project is heavily dependent on such arrangments and on the sale of the user's books, plus donations. If corporations were to contribute a fraction of the cost otherwise spent on a commerical product, we could do much more, and faster too, and buyers would still enjoy the benefits of a commercial-grade product with Tech Support and a professionally done user's manual (Digital Press and Prentice Hall does the publishing). Joe Doupnik .............................................................................. [see below for discussions of Kermit support policy] ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.protocols.kermit.misc Message-ID: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Dunwoody Georgia Date: Sun, 27 Jul 2003 02:04:29 -0400 From: Bill Subject: Word Perfect Keyboard (Frank) Clueless! Well I am still attempting to help a Medical Transcriber change her connection with Kermit to a UNIX server. I thought she had made it work but she wasn't that lucky and the System Person said the old version of ProComm was the only one that would work. Anyhow today I tried to log in and got to the terminal screen after typing in the set terminal keyboard-mode wp, and as you advised checked the terminal type on the terminal page and there is no vt320-w! There isn't even an option in the scroll box. I don't think the set command is working (or I am putting it in the wrong screen!). I have also looked through the .ini files and they seem to be similar enough to do the simple things she needs to do (file retrieval and the upload of her work). I refuse to believe that the ancient version of ProComm is the only thing that will work! I really thought that it was out of production but [Symantec] still sells a version. She and I both are working from a template and maybe there are more options working from scratch? Any additional thought? Thanks Bill Atlanta .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Columbia University Date: 26 Jul 2003 16:01:15 -0400 From: Frank da Cruz Subject: Re: Word Perfect Keyboard (Frank) In article <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>, Bill wrote: : : [I] checked the terminal type on the terminal page and there is no : vt320-w! There isn't even an option in the scroll box. I don't think : the set command is working (or I am putting it in the wrong screen!). VT320-W would not appear in the scroll box; it's not a terminal type, it's a keyboard mode applied to a terminal type. : I refuse to believe that the ancient version of ProComm is the only : thing that will work! : Me too. Let's try again, step by step. Let's assume you have a connection to the host, and have started WordPerfect on the host. K95 is in its terminal screen (normally blue, but could be any color). On the bottom of the screen (inside the frame) is a green line with white writing, called the Status Line, that says: o o o o VT320 Help: Alt-H Command: Alt-X (etc etc). At this point do: . Alt-x (i.e. hold down the Alt key and press the X key) . At the K-95> prompt, type the following command: set terminal keyboard-mode wp . Alt-x again to get back to the terminal screen. Now the Status Line should say: o o o o VT320-W Help: Alt-H Command: Alt-X (etc etc). and the WordPerfect Key mappings should be in effect. To return to the regular VT320 key mapping, do: . Alt-x (i.e. hold down the Alt key and press the X key) . At the K-95> prompt, type the following command: set terminal keyboard-mode normal . Alt-x again to get back to the terminal screen. and the "VT320-W" in the status line should revert to "VT320". There *should* be an easier way to do this: Ctrl-Alt-Shift-W is supposed to toggle in and out of WordPerfect keyboard mode. But for some unknown reason this does not seem to work on all PCs. If these instructions do not cause "VT320-W" to appear in Kermit's status line, send e-mail to kermit-support@columbia.edu, and we'll do the detailed troubleshooting. By the way, when you first posted this question you said you had the "latest kermit", and I assumed by that you meant you had Kermit 95 2.1.3. If that's not the case and you are talking about (e.g.) MS-DOS Kermit, then please say so. - Frank .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: a2i network Date: Sun, 27 Jul 2003 20:17:08 +0000 (UTC) From: dold@WordXPerfe.usenet.us.com Subject: Re: Word Perfect Keyboard (Frank) I wanted to wait for Frank to respond first, with a K95 entry that was more graceful than my setup. I made my own mapping for WordPerfect and MSDOS Kermit-3.11 to a UnixWare box. I was also faced with another Unix (ESIX) system that came with bundled software and a fixed terminal type of vt100-pro, with some mangling to fit the Procomm-of-the-day mapping. By capturing what procomm sent to the unix system for each F key, I was able to build my own map of what Kermit needed to send. I probably still have that lying around somewhere. I looked at the Wordperfect mapping that was on the kermit site at that time, and chose not to use it, although I don't recall why. -- Clarence .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Dunwoody Georgia Date: Mon, 28 Jul 2003 10:38:19 -0400 From: Bill Subject: Re: Word Perfect Keyboard (Frank) Thanks! This evening was a break-through. The keyboard-mode needs to be issued after the session is started and then the W is appended to the terminal type. I have forgotten whether she used vt220 or vt320. I used the vt220W and go to the help screens and that lets you see the UNIX template. I expect that the days of UNIX WP and ProComm are pretty fuzzy memories to most folks now - certainly to me. We never used UNIX based applications, except for CAD workstations and they and their dark room requirements didn't last so very long because along came AutoCad and we were all PCs. Thanks for the help. If you find the ProComm mappings/Kermit version I am willing to try. Bill Atlanta .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Columbia University Date: 28 Jul 2003 10:06:44 -0400 From: Frank da Cruz Subject: Re: Word Perfect Keyboard (Frank) In article , wrote: : : I wanted to wait for Frank to respond first, with a K95 entry that was more : graceful than my setup. K95's WordPerfect keyboard mode is built-in. You can see what the default mappings in the Default.Ksc file, which is in your Kermit 95 directory tree somewhere; there's also a copy here: ftp://kermit.columbia.edu/kermit/k95/default.ksc Search for "SET TERMINAL KEY wp" and then read the next 146 lines. Of course you can change the mapping any way you like. : I looked at the Wordperfect mapping that was on the kermit site at that : time, and chose not to use it, although I don't recall why. It should have been just the ticket since these mappings were provided by WordPerfect themselves. K95 used this map as a model for its WP keyboard mode. - Frank .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com> References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> Organization: Dunwoody Georgia Date: Wed, 30 Jul 2003 23:37:41 -0400 From: Bill Subject: Re: Word Perfect Keyboard (Frank) I have used FinePrint to print out the whole manual, and found the WP section. If the old mapping file is found it may be worth posting at Kemit. I expect that the Transcribers will all hit this at some point(?). Especially when the old version of ProComm(s) flake out. Pretty sure it will not run in XP and I haven't tried it on my Win2K machine. Thanks Bill (BTW the existing WP emulation works well enough to make corrections to the server copy, and apparently they mostly work on WP locally and then up-load the files. Kermit up-loads fine as is......) .............................................................................. Newsgroups: comp.protocols.kermit.misc Message-ID: References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com> <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com> Organization: Columbia University Date: 30 Jul 2003 12:08:18 -0400 From: Frank da Cruz Subject: Re: Word Perfect Keyboard (Frank) In article <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com>, Bill wrote: : I have used FinePrint to print out the whole manual, and found the WP : section. If the old mapping file is found it may be worth posting at : Kemit. I expect that the Transcribers will all hit this at some : point(?). Especially when the old version of ProComm(s) flake out. : Pretty sure it will not run in XP and I haven't tried it on my Win2K : machine. : Why don't you post what you think the mapping should be and then we can compare it with what Kermit uses, and then we'll know why you think there is a problem. Remember: Kermit's mapping is the one recommended by the WordPerfect company itself. Anyway, you still haven't confirmed that you have actually activated Kermit's WordPerfect keyboard mode. I explained several times how to to do this. - Frank ////////////////////////////////////////////////////////////////////////////// Newsgroups: comp.terminals,comp.sys.ibm.pc,comp.sys.ibm.pc.misc Path: utkcs2!darwin.sura.net!news.udel.edu!ravel.udel.edu!sigurd Message-ID: Sender: usenet@news.udel.edu Nntp-Posting-Host: ravel.udel.edu Organization: University of Delaware References: <1992Oct5.021247.22556@samba.oit.unc.edu> <1992Oct6.092905.19557@news.uni-stuttgart.de> Date: Tue, 20 Oct 1992 20:56:10 GMT From: sigurd@ravel.udel.edu (Sigurd Andersen) Subject: Re: Inexpensive Tek 4014/DEC VT220 Emulator? In article <1992Oct6.092905.19557@news.uni-stuttgart.de> skok@itwds1.energietechnik.uni-stuttgart.de (Holger Skok) writes: : Kermit emulates vt100 and Tek4014 and it's free (as far as I know). : I haven't found out though, how to store the Tek4014 image and convert : it to HPGL like it is possible with some commercial terminal emulators. : ... [ Others also sent various related messages which I will NOT summarize ] [as of 20 Oct 1992] The latest version of MS-Kermit (for MS-DOS-based personal computers) is 3.12. That's the version now distributed by Columbia University. Version 3.12 adds the ability to establish network connections using ODI drivers in addition to the connections using packet drivers that were possible with version 3.11. MS-Kermit and versions for other computer systems are fully copyable. The following quote is from the book, "Using MS-DOS Kermit," Second Edition: "Kermit programs can be freely reproduced and shared as long as this is not done for profit. No licensing or registration is required. However, Kermit programs are not in the public domain. In general, each Kermit program includes a copyright notice to protect its special status. ..." (page xxii) With version 3.11 or 3.12 (and possibly earlier versions), one can capture Tektronix graphics screens as "Aldus/Microsoft TIFF (Tagged Image File Format) 5.0 ... suitable for importation into applications such as WordPerfect 5.0, Aldus Pagemaker, Ventura Publisher, PC Paint, and others that support TIFF 5.0." (ibid., p. 85) Screen capture is initiated with the key combination Control-End. The graphics commands from a host that create the screen images can also be captured (using the LOG SESSION command) and played back using the REPLAY command. A reference for the book: "Using MS-DOS Kermit Connecting your PC to the Electronic World" Second Edition, by Christine M. Gianone. From Digital Press (ISBN 1-55558-082-3) or Prentice-Hall (0-13-952276-X). -- Sigurd Andersen Internet: sigurd@chopin.udel.edu CNS User Services __o or Sigurd.Andersen@MVS.udel.edu 115-B Newark Hall _ \<,_ Bitnet: ACS20833@UDELVM Univ. of Delaware (_)/ (_) Ph: (302) 831-1992 Fax: 831-4335 Newark, DE. 19716 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.os.vms Path: utkcs2!darwin.sura.net!paladin.american.edu!news.univie.ac.at!hp4at !mcsun!uknet!strath-cs!str-ccsun!dct.ac.uk!ccdarg Message-ID: <1992Oct20.154534.710@dct.ac.uk> Date: 20 Oct 92 14:45:34 GMT References: <1992Oct19.160704.1@uwovax.uwo.ca> <1992Oct19.215917.5808@ais.com> Organization: Dundee Institute of Technology From: ccdarg@dct.ac.uk (Alan Greig) Subject: Re: Shipping obj files using Kermit? In article <1992Oct19.215917.5808@ais.com>, bruce@ais.com (Bruce C. Wright) writes: > > In article <1992Oct19.160704.1@uwovax.uwo.ca>, > brent@uwovax.uwo.ca (Brent Sterner) writes: >> >> I have a user who wants to transfer .obj files to another site using >> Kermit. The files arrive, bit are not usable. The file organization >> seems to end up being munged, whether he uses binary mode or not. > > Yes, rather annoying how VMS .OBJ files and Kermit don't agree with one > another very well. :-( > C kermit 5A for VMS can transfer *any* VMS file preserving RMS attributes. It can even transfer to a PC (say) and then correctly restore the file on the way back. The moment it passes the beta stage (which is expected any day now...) I'll post out a copy of the announcement here. In the meantime you can probably get hold of it as follows. HOW TO GET THIS EDIT The new edit is available (on the Internet only) via anonymous ftp from host watsun.cc.columbia.edu [128.59.39.2], using text (ASCII) mode in the directory kermit/sw/. General C-Kermit documentation: ckaaaa.hlp Explanation of file naming conventions ckcplm.doc C-Kermit "program logic manual" ckccfg.doc C-Kermit configuration info ckcker.ann Info-Kermit Digest announcement of version 5A(179) ckcker.bwr General C-Kermit beware file ckcker.upd C-Kermit program update history since edit 179, plain text ckc178.upd C-Kermit 5A update history through edit 178, HUGE ckuker.doc plain-text user manual (still 179) ckuker.ps Postscript user manual (ditto) ckuker.mss Scribe source for user manual + ckuhdr.mss (ditto) VMS sources: ck[cuwv]*.[cwh], plus ckvcvt.c (labeled-file decoder) VMS build: ckvcdt.com plus ckvker.com (DCL), ckvker.mak (VMS MAKE), or ckvker.mms (MMS). Instructions: ckvins.doc. VMS executable: ckvker.hex, use ckvdeh.mar to decode it into .EXE format. NOTE: this executable does not include TCP/IP support. VMS docs: ckvker.hlp, ckvins.doc, ckvker.bwr VMS diffs: ckv184.dif (88K), use with cku184.dif. -- Alan Greig Janet: Alan@UK.AC.DUNDEE-TECH Dundee Institute of Technology Internet: Alan@DCT.AC.UK Tel: (0382) 308810 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 53502 of comp.os.vms: Path: utkcs2!gatech!rutgers!spcvxb!terry From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Newsgroups: comp.os.vms Subject: Re: Shipping obj files using Kermit? Message-ID: <1992Oct20.232253.4168@spcvxb.spc.edu> Date: 21 Oct 92 03:22:53 GMT References: <1992Oct19.160704.1@uwovax.uwo.ca> <1992Oct19.215917.5808@ais.com> Organization: St. Peter's College, US Lines: 23 In article <1992Oct19.215917.5808@ais.com>, bruce@ais.com (Bruce C. Wright) writes: > Yes, rather annoying how VMS .OBJ files and Kermit don't agree with one > another very well. :-( Fixed in a forthcoming major release. C-Kermit 5A, now in beta test, adds a new file transfer type called "LABELED". Labeled transfers correctly pre- serve all the file attributes you'd ever want. You can transfer any VMS file structure between systems with this feature. I've moved RMS indexed files, .OBJ's, etc. You can even pass these files through an intermediate system which knows nothing about VMS files. I've moved VAX Notes conference files from one VAX to my PC and then back to another VAX and had them work fine. The current test version of C-Kermit is available from watsun.cc.columbia.edu in directory kermit/sw. At the present time I believe only sources are avail- able; you'll need the VAX C compiler (or DEC C for an Alpha AXP) to compile it. When the test period is over, a formal announcement will likely be made here. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 676 of comp.terminals: Newsgroups: comp.dcom.lans.ethernet,comp.terminals Path: cs.utk.edu!gatech!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!cs.umd.edu!afterlife!grday From: grday@afterlife.ncsc.mil (Gary Day) Subject: MSDOS Kermit and TCP/IP Message-ID: <1993May14.021506.3974@afterlife.ncsc.mil> Organization: The Great Beyond Distribution: usa Date: Fri, 14 May 1993 02:15:06 GMT Lines: 83 Xref: cs.utk.edu comp.dcom.lans.ethernet:4760 comp.terminals:676 On April 16, 1993 I posted the following: >I have an IBM AT running MSDOS 5.0 with a 3COM 3C505 LAN adapter. >Can someone please tell me what I need (i.e., packet driver or whatever, >and where I might obtain such) in order to use MSKERMIT 3.11 Several people asked me to post what I found out, so here it is. First, MSDOS Kermit may be used to communicate via TCP/IP lans in one of two ways. MSDOS Kermit provides direct support for TCP/IP lans via a set of SET TCP/IP commands. In order to use MSDOS Kermit in this mode, you need a packet driver. PCTCP-PLUS from FTP Software Inc. comes with a complete collection of packet drivers. These same drivers may be obtained from: Host: sifon.cc.mcgill.ca Location: /pub/ftp_inc/dos/pdrivers MSDOS kermit 3.11 is also available from this same location. You may need to refer to the documentation with your specific adapter to get the correct values to use when installing the appropriate packet driver. Specifically, you will need to supply a software interrupt number, the hardware interrupt number used by the adapter, the I/O address, and the memory base address. For example, I have a 3C505 card, so I use the command: 3c505 0x60 5 0x300 0xcc00 By the way, PCTCP-PLUS comes with a device driver called 3C505.COM which should not be confused with the packet driver by the same name. With the packet driver installed, you can invoke Kermit and give the appropriate SET TCP/IP commands, for example: SET TCP/IP ADDRESS 139.75.25.126 SET TCP/IP SUBNETMASK 255.255.255.0 SET TCP/IP GATEWAY 192.75.55.9 SET TCP/IP DOMAIN NCSC.MIL SET TCP/IP PRIMARY-NAMESERVER AFTERLIFE SET TCP/IP PRIMARY-NAMESERVER VALHALA SET PORT TCP/IP PARADISE You may need to get the help from your LAN manager to get the proper values to be supplied for the addresses and for the name servers. The second, and easier way to use Kermit on a TCP/IP LAN, is to use the TNGLASS "-e" option, which informs TNGLASS (from PCTCP) that an alternate terminal emulator is being used. This causes TNGLASS to make a TELNET connection, and then invoke the named terminal emulator, with which it will communicate via DOS interrupt 14. For example: tnglass paradise -e kermit In this case, you will need to inform kermit that it is to communicate via interrupt 14, by issuing the command: SET PORT BIOS1 All of this information and much more is given in the book: "Using MSDOS Kermit" by Cristine Gianone and this is a book that I highly recommend for serious MSDOS Kermit users. It also comes with MSDOS Kermit 3.11 on a 5 and 1/4 in. floppy. I am a blind programmer and use a screen reader driver, together with a speech synthesizer to produce speech from the displayed text. The MSDOS Kermit vt100 emulation is done through MSDOS I/O interrupt calls and thus works well with my screen reader. (Some earlier documentation indicates that Kermit performs terminal emulation via direct video memory access, but this appears not to be the case, at least for vt100 emulation). However, I have found that if I install a packet driver and try to make a direct TCP/IP connection with Kermit, my system will hang as soom as my screen reader is enabled. I haven't a clue why this should be. But the second method of using tnglass and interrupt 14 works fine. Gary R. Day: grday@afterlife.ncsc.mil Thanks to Wayne Hann, of the Cabot College of Applied Arts, WAYNE@FAC.CABOT.NF.CA for pointing me in the right direction. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.os.vms Path: cs.utk.edu!gatech!concert!rutgers!spcvxb!terry Message-ID: <1993May9.171512.5872@spcvxb.spc.edu> Date: 9 May 93 21:15:12 GMT References: <01GXWVNSRHQ89BVI9R@JCSVAX1.BITNET> Organization: St. Peter's College, US From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Subject: Re: Kermit is toooooooo slow !! In article <01GXWVNSRHQ89BVI9R@JCSVAX1.BITNET>, HANY%JCSVAX1.BITNET@pucc.Princeton.EDU (Axioms can be viewed as a form of exact theology) writes: > > Our school runs VMS Kermit-32 version 3.3.111 on a VAX/VMS V5.4-2. > I find it pretty slow to transfer files using this protocol, specially > that our highest connection is at 2400 bauds. Still, at 2400, I get almost > triple Kermit's speed using ZMODEM when connecting to my local BBS. There's a number of reasons for this. First, your 2400 baud connection to JCS is either through the DCA front-end, or through the NJ Bell LANgate packet- switched network. Both of these introduce substantial delays when used for file transfer. A protocol which utilizes multiple-packet windows will perform better on this type of link. C-Kermit does this; I don't know about Zmodem. Second, Zmodem expects to be able to pass most control characters through the line. While I am told that it is careful to avoid using "troublesome" characters like ^S/^Q, I believe it will use ^V (or is it ^N?), which is the "attention charac- ter" for your DCA front-end. Kermit quotes all control characters in user files. > My question is: Is there any shareware/freeware software that is faster than > this version of Kermit ? I think that it won't be hard to convince our sys > mngr to switch if such a thing exists. It is equally important also to know > where can I get it. An FTP site will be the most convenient, but I am also > willing to call long distance if it is worth it. C-Kermit is substantially faster than Bliss Kermit-32 as long as both ends are capable of using long packets and sliding windows. Many other Kermits, in- cluding MS-DOS Kermit, support these features. C-Kermit is available by anonymous FTP from watsun.cc.columbia.edu. In your case, you'd want (as a minimum) kermit/v/ckvker.hex and ckvdeh.mar. As you probably know, I provide support for some of the more esoteric pieces of software on the JCS cluster. I'd be glad to install C-K there if system man- agement requests it. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!nntp.memst.edu!ukma!eng.ufl.edu!spool.mu.edu !howland.reston.ans.net!darwin.sura.net!udel!news.intercon.com !psinntp!news.columbia.edu!usenet Message-ID: <1993May16.144933.16900@news.columbia.edu> Date: Sun, 16 May 1993 14:49:33 GMT References: Organization: Columbia University From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: zmodem for kermit In article haymoree@quack.kfu.com (Ed Haymore) writes: > > How do I get a decent throughput with Kermit on a 14.4k modem? I can't > get anything more than about 350 cps -- with zmodem I get 1600+ cps on > the same setup. (compressed file, by the way) > > Even at 2400 baud, kermit's speed is about 50% of zmodem's. If the > quoting doesn't significantly increase the amount of data to transfer, > what makes kermit so slow? First, let's make sure you are using real and up-to-date Kermit software, and not the minimalistic and half-hearted Kermit implementations that you find in most commercial and shareware communication software. For DOS and Windows, use MS-DOS Kermit 3.12 (soon to be 3.13); for UNIX use C-Kermit 5A(188) (soon to be 189) (watch comp.protocols.kermit for announcements). Then make sure an effective method of flow control, preferably RTS/CTS, is enabled at each interface along the communication path. For example, tell MS-DOS Kermit to SET FLOW RTS/CTS, and give the corresponding settings to your modem. Set your interface speed higher than the modem's modulation speed. For example, using 14400 bps modulation, set your interface to 57600 bps if possible, or 38400 or 19200 otherwise. (This doesn't actually matter too much when transferring precompressed files, but it does matter for most other types of files, and is a good rule to follow in general when using modems that do data compression.) Tell both Kermit programs to SET WINDOW , where is a number somewhere between 2 and 20 -- the optimum value depends on the connection, the characteristics of the modem and the data. Tell both Kermit programs to SET RECEIVE PACKET-LENGTH 1000. Also, when sending binary files (like ZIP files) don't forget to tell the file sender to SET FILE TYPE BINARY (it will tell the receiver automatically). Using these settings, you should get about 1300 cps for ZIP or other precompressed files, and much higher rates for other types of files. MS-DOS Kermit 3.13 and C-Kermit 5A(189) will include a new feature that lets you boost throughput of ZIP and other precompressed files by about 20%, ON PERFECTLY CLEAN 8-BIT TRANSPARENT CONNECTIONS, bringing Kermit's performance in this situation to the same level as Zmodem's (as pointed out earlier, Kermit already outperforms Zmodem in most other situations: text files, most uncompressed binary files, noisy connections, connections with delays, 7-bit connections, etc). To get Kermit software, use anonymous ftp to watsun.cc.columbia.edu [128.59.39.2], directory kermit, get the file READ.ME, read it, take it from there. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.tcp-ip,comp.terminals Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!uunet!cs.utexas.edu!utah-morgan !hellgate.utah.edu!cc.usu.edu!jrd Message-ID: <1993Aug16.215757.71292@cc.usu.edu> References: <24n6pq$pr8@toffu.icl.fi> Organization: Utah State University Date: 16 Aug 93 21:57:57 MDT From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Where to get VT-100 source code in public domain? In article <24n6pq$pr8@toffu.icl.fi>, jel@xerver.icl.fi (Jerry Lahti) writes: > westes@netcom.com (Will Estes) writes: > >>I need to write a simple VT-100 emulator as part of a commercial >>product. Where does one find the specifications for VT-100, and is >>there any code in the public domain for this emulation that can be >>used as either a reference or actually copied into a commercial >>product? > > Presumably Digital will sell you the appropriate reference manuals. > > MS-Kermit sources might serve as a reference, although the display > emulation is unfortunately :-) already at the VT-320 level. However, > I have not looked closely enough at the copyrights to know, if the > code could be directly incorporated into a commercial product. > > /Jerry Lahti > > -- > Jerry Lahti ! tel. +358-0-567 3639 > ICL Personal Systems Oy ! fax. +358-0-567 5670 > P.O.Box 780 ! Email: jel@xerver.icl.fi (Internet) > 00101 Helsinki, Finland ! X400: C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY ------------------ Here's the copyright notice from MS-DOS Kermit: ; Copyright (C) 1985, 1993, Trustees of Columbia University in the ; City of New York. Permission is granted to any individual or institution ; to use this software as long as it is not sold for profit. This copyright ; notice must be retained. This software may not be included in commercial ; products without written permission of Columbia University. So no, one can't use the material for commercial products. The ref for DEC VT100's is from Digital themselves (that's by far the best ref too). Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!darwin.sura.net!howland.reston.ans.net!agate!dog.ee.lbl.gov !hellgate.utah.edu!cc.usu.edu!jrd Message-ID: <1993Oct31.194051.2931@cc.usu.edu> Date: 31 Oct 93 19:40:51 MDT References: <2aehhv$kbg@vixen.cso.uiuc.edu> <752109594snz@genesis.demon.co.uk> <2aejmc$77v@apakabar.cc.columbia.edu> <1993Oct28.204050.9223@omen.UUCP> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Problems with com4 and Kermit In article <752109594snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes: > > In article <1993Oct28.204050.9223@omen.UUCP> caf@omen.UUCP writes: > >>What's unreal about the Kermit in Telix, Procomm, et al? Do they violate the >>published Kermit spec? > > Many do. I've noted that in the past some implementations won't accept valid > negotiation packets even though published specs show how to deal with them, > even when the packets contain fields for the more advanced functions. > > ----------------------------------------- > Lawrence Kirby | fred@genesis.demon.co.uk > Wilts, England | 70734.126@compuserve.com > ----------------------------------------- To quote a section from the "Kermit News", Number 5, July 1993, which has a big article on the subject of performance. (start quote, with some abbreviations) Table 1 illustrates the performance of the Kermit protocol implementations found in different PC software packages. These measurements were made on a direct 19200-bps serial connection, downloading a typical ASCII text file (the VM/CMS Kermit-370 manual), 135087 bytes in length, from a Sun SPARCserver-10 with C-Kermit 5A(189) to the hard disk of an IBM PS/2 Model 70. Table 1 Kermit Implementations Compared Window Packet Time Speed PC Software Size Length sec (cps) Effic Remarks ----------- ------ ------ ---- ----- ---- --------------------------- Telix 1 94 131 1052 55% No Long Pkt, no Slide Window METZ 1 94 119 1158 60% No LP, no SW Smartcom III 1 94 113 1220 64% No LP, no SW PROCOMM PLUS 14 1000 77 1790 93% Window size is not selectable Zstem 340 2 1000 74 1863 97% Max window size is 2 MS-DOS Kermit 3 1000 72 1915 99% Full control-char prefixing MS-DOS Kermit 3 1000 69 1999 104% Only 0, 1 and 129 prefixed ------ MS-DOS Kermit v3.13 METZ v1.16 PROCOMM PLUS v2.0 Smartcom III v1.0A Telix v3.21 Zstem 340 v1.0.4 (end quote) Please contact Christine Gianone, cmg@columbia.edu, to request a copy. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!uunet!nntp.club.cc.cmu.edu !honeydew.srv.cs.cmu.edu!GS137.SP.CS.CMU.EDU!pwp Message-ID: Originator: pwp@GS137.SP.CS.CMU.EDU Organization: School of Computer Science, Carnegie Mellon X-Newsreader: NN version 6.5.0 #13 (NOV) References: <1993Oct31.194051.2931@cc.usu.edu><1993Nov01.112834.8307@omen.UUCP> <752171522snz@genesis.demon.co.uk> <1993Nov02.112928.17189@omen.UUCP> Date: Wed, 3 Nov 1993 04:57:15 GMT From: Paul Placeway Subject: Re: Problems with com4 and Kermit caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >So where can the current Real Kermit(Tm) protocol specs be FTP'd from?? >It appears that one must use code from the latest Columbia Kermit sources, >and those are protected by a restrictive Copyright. Watsun.cc.columbia.edu. You know this already, and so does most of the rest of the planet. >>Most ZMODEM implementations do go as fast as the freely available specs >>permit. >Likewise for Kermit, and likely to stay that way. Yup. Unix Kermit 5a and MS Kermit 3, for instance. The current spec is the natural union of the latest protocol document and the final versions of the un-quoting additions from the Kermit mailing list, ALL of which are available for anonymous FTP right now (yes, I just checked). The spec MUST be right, because there are hundreds of Kermit implementations, often in different languages, which all actually work together. The only way to do this is to have a clear, complete, and available spec, and to implement to it. I know personally that the sliding windows spec is correct. I wrote a ground-up new implementation in 1988 (yes, 5 years ago). When I had it working to the spec correctly, it worked correctly against the existing code the first time I tried it. And the latest, fastest, Kermit is *still* backwards compatible to version 1. Zmodem cannot make the same claim, though for reasons of greed rather than any good technical reason. Now if the spec for the latest version of zmodem were available, and Omen just happened to make the best quality implementation, you shouldn't have any problem with compensation for your efforts, and users of machines too weird for Omen to support (eg. Macs, Amigas, hand-held calculators) would benefit from other high performance implementations. (And like Microsoft, if a small market becomes a big one, you have an easy chance to step in and sell even more.) On the other hand, if you want to run a closed spec, well, I can only suggest you ask IBM and DEC how they feel about the current popularity of Sun, or perhaps consider the current popularity of ARC vs. ZIP. The Market reacts to a good value. The inverse is also true... >Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf -- Paul Placeway -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 47123 of comp.dcom.modems: Newsgroups: comp.dcom.modems Path: cs.utk.edu!avdms8.msfc.nasa.gov!europa.eng.gtefsd.com!uunet!omen!caf From: caf@omen.UUCP (Chuck Forsberg WA7KGX) Subject: Re: Problems with com4 and Kermit Organization: Omen Technology INC, Portland Rain Forest Date: Fri, 05 Nov 1993 00:12:25 GMT Message-ID: <1993Nov05.001225.8163@omen.UUCP> References: <752171522snz@genesis.demon.co.uk> <1993Nov02.112928.17189@omen.UUCP> Lines: 92 In article Paul Placeway writes: >caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >>So where can the current Real Kermit(Tm) protocol specs be FTP'd from?? >>It appears that one must use code from the latest Columbia Kermit sources, >>and those are protected by a restrictive Copyright. > >Watsun.cc.columbia.edu. You know this already, and so does most of >the rest of the planet. > >>>Most ZMODEM implementations do go as fast as the freely available specs >>>permit. > >>Likewise for Kermit, and likely to stay that way. > >Yup. Unix Kermit 5a and MS Kermit 3, for instance. The current spec >is the natural union of the latest protocol document and the final >versions of the un-quoting additions from the Kermit mailing list, ALL >of which are available for anonymous FTP right now (yes, I just >checked). The spec MUST be right, because there are hundreds of >Kermit implementations, often in different languages, which all >actually work together. The only way to do this is to have a clear, >complete, and available spec, and to implement to it. Um, last time I checked, Unix Kermit and MS Kermit are covered by restrictive copyrights. My "likely to stay that way" comment refers to Kermit support in "the popular implementations" of Kermit in ProComm, Crosstalk et al. I don't think DCA or Datastorm are any more likely to violate Columbia's copyright than they are likely to violate the copyright in rz/sz. The fact that someone was able to cobble together a program that works in one or two benign environments does not mean the spec is through or accurate. >I know personally that the sliding windows spec is correct. I wrote a >ground-up new implementation in 1988 (yes, 5 years ago). When I had >it working to the spec correctly, it worked correctly against the >existing code the first time I tried it. I'm not sure Frank completely agrees with you: . Sliding Windows. Of course, I know the history too. I worked closely with The Source throughout the development of sliding windows, but the implementations that they commissioned were rush jobs that left a lot to be desired. They were nowhere near "efficient and robust under stress". They were buggy as all get-out, hideous to contemplate internally, and broke more often than they worked. This was the code that was incorporated into shareware Procomm, by the way, and who knows where else. Eventually, we wrote our own sliding windows implementations completely from scratch. Compare them yourself for robustness and efficiency with The Source version. Of course, the good implementation is Copyrighted. >And the latest, fastest, Kermit is *still* backwards compatible to >version 1. Yup. It took me an hour to get C-Kermit 189 on SCO to send a binary file to C-Kermit 189 on a BSDI machine starting with the settings given in the Kermit News article. (The Kermits were using different dialects, then Ctrl-C had to be escaped.) Kermit lusers often encounter this dialect problem. So don't lecture me on compatibility. >Zmodem cannot make the same claim, though for reasons of greed rather >than any good technical reason. Now if the spec for the latest Oh yes ZMODEM can. Every case of incompatibility that I have been able to investigate has been caused by the implementor breaking the spec or the PD source code in one or more ways. As for greed, I might point out that I have licensed ZMODEM-90(Tm) under much more favorable conditions than Frank da Cruz has offered to license me the current Kermit technology. Thye July Kermit News obfuscates this issue by claiming Kermit software was never public domain. In fact, until recently developers were free to incorporate the Kermit source code into their programs. Apparently the financial situation at Columbia U has changed. >version of zmodem were available, and Omen just happened to make the >best quality implementation, you shouldn't have any problem with Yes, we do make the best implementation, which is why Frank da Cruz was careful not to use it for his so-called "True-Life Benchmarks" in his hit piece on ZMODEM. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ Omen Technology Inc "The High Reliability Software" 17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 49457 of comp.dcom.modems: Newsgroups: comp.dcom.modems,comp.unix.questions Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!uunet!news.crd.ge.com!sixhub!davidsen From: davidsen@sixhub.tmr.com (Bill Davidsen) Subject: Re: DSZ for unix Reply-To: davidsen@tmr.com (bill davidsen) Organization: TMR Associates, Schenectady NY Date: Wed, 8 Dec 1993 03:30:02 GMT Message-ID: References: <1993Dec1.143941.252999@ucl.ac.uk> Lines: 30 Xref: cs.utk.edu comp.dcom.modems:49457 comp.unix.questions:57484 In article wjones@tc.fluke.COM (Warren Jones) writes: | If you have kermit version 5A, you can teach it to use sz/rz as | external protocols. Put something like this in $HOME/.kermrc: | | --------------------------- cut here ---------------------------------------- | # Generic external protocol | # | def extern ! exec /usr/local/bin/\%1 \%2 <\v(line) >\v(line),- | echo,- | connect Only on some implementation of UNIX. On some the serial port is owned by uucp (or bin, root, or ???) and the comm progs must run setuid. And in sysV you can't setuid to euid unless you are root or have V.4. Therefore you (as your login id) can't open the serial port with redirection, and the trick doesn't work. The solution is to add code to Kermit to run the prog using the port as stdin and stdout, and I did it, and am sending the code to Frank to incorporate. I really needed it, although Kermit is much faster than Zmodem on some lines, since zmodem seems to get a long way past an error before starting the retry (or something). The line is a modem pool connected via enet to the system called, and with the net and protocol and modems playing packets the zmodem performance is slower. -- Bill Davidsen, davidsen@tmr.com | C programming, PC based UNIX, data TMR Associates, +1 518-370-5654 | acquisition, device drivers. _____________________________________|______________________________________ cat - 'kat, a purr bearing mammal -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!emory!europa.eng.gtefsd.com!library.ucla.edu!agate !headwall.Stanford.EDU!Csli!paulf Message-ID: <1994Jan21.200109.12743@Csli.Stanford.EDU> Organization: The Three Packeteers References: <2hlpdn$e3m@golem.wcc.govt.nz> <1994Jan20.193454.25924@omen.UUCP> <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan21.181856.2768@omen.UUCP> Date: Fri, 21 Jan 1994 20:01:09 GMT From: paulf@Csli.Stanford.EDU (Paul Flaherty) Subject: Re: Protocol Shootout Results caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >Paul, could you be so kind as to provide the pathnames for these files? >I don't see any of the three Kermit books in Columbia University's public FTP >area. All I found was a copy of an antique Kermit spec. Please provide >pathnames for: > 1. current Kermit protocol spec ~ftp/kermit/e/kproto.ps > 2. Using C-Kermit ~ftp/kermit/b/ckuker.ps > 3. Using MS-DOS Kermit ~ftp/kermit/a/mskerm.ps Those files, plus the most current .bwr text files, AND SOURCE CODE, make up an outstanding documentation example. -- -=Paul Flaherty, N9FZX | "Fighter pilots make movies. Bomber pilots make ->paulf@Stanford.EDU | history." -- Jake Grafton -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!emory!europa.eng.gtefsd.com!uunet!omen!caf From: caf@omen.UUCP (Chuck Forsberg WA7KGX) Subject: Re: Protocol Shootout Results Organization: Omen Technology INC, Portland Rain Forest Date: Sat, 22 Jan 1994 13:04:28 GMT Message-ID: <1994Jan22.130428.10097@omen.UUCP> References: <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan21.200109.12743@Csli.Stanford.EDU> <1994Jan21.181856.2768@omen.UUCP> In article <1994Jan21.200109.12743@Csli.Stanford.EDU>, paulf@Csli.Stanford.EDU (Paul Flaherty) writes: > >caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >>Paul, could you be so kind as to provide the pathnames for these files? >>I don't see any of the three Kermit books in Columbia University's public FTP >>area. All I found was a copy of an antique Kermit spec. Please provide >>pathnames for: >> 1. current Kermit protocol spec > >~ftp/kermit/e/kproto.ps No, that's the 1986 spec. It doesn't describe "Real Kermit" according to Columbia University. >Those files, plus the most current .bwr text files, AND SOURCE CODE, make up >an outstanding documentation example. Paul must think "Kermit" means "free". This is no longer true. Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New York. The C-Kermit software may not be, in whole or in part, licensed or sold for profit as a software product itself, nor may it be included in or distributed with commercial products or otherwise distributed by commercial concerns to their clients or customers without written permission of the Office of Kermit Development and Distribution, Columbia University. This copyright notice must not be removed, altered, or obscured. -- Chuck Forsberg WA7KGX caf@omen.COM 503-621-3406 Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ Omen Technology Inc "The High Reliability Software" TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate !headwall.Stanford.EDU!Csli!paulf Message-ID: <1994Jan22.184854.18205@Csli.Stanford.EDU> Organization: The Three Packeteers References: <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan22.130428.10097@omen.UUCP> <1994Jan21.181856.2768@omen.UUCP> <1994Jan21.200109.12743@Csli.Stanford.EDU> Date: Sat, 22 Jan 1994 18:48:54 GMT From: paulf@Csli.Stanford.EDU (Paul Flaherty) Subject: Re: Protocol Shootout Results (Really: Kermit Legal Status) caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > >No, that's the 1986 spec. >It doesn't describe "Real Kermit" according to Columbia University. Well, that's the current protocol spec. If by "Real Kermit" you include stuff like the command interface, that can be had from reading the source code. The status of the protocol spec is listed in the forward: #begin kermit.columbia.edu:~ftp/kermit/e/kproto.doc# PREFACE TO THE SIXTH EDITION The sixth edition (June 1986) of the Kermit Protocol Manual is being issued for two major reasons: to correct minor errors in the fifth edition, and to include new sections on two major protocol extensions: long packets and sliding win- dows. No attempt has been made to reorganize, rewrite, or otherwise improve the protocol manual. The Kermit protocol has been presented in an entirely different -- hopefully more thorough, organized, coherent, and useful (if not more formal) -- manner in the book, "Kermit, A File Transfer Protocol," by Frank da Cruz, Digital Press, Bedford MA (1987), ISBN 0-932376-88-6, DEC order number EY-6705E-DP. If you have the book, you won't need this protocol manual. On the other hand, if you don't have the book, this manual should still contain all the necessary information. The Kermit Protocol Manual will continue to be freely distributed in perpetuity. #end kermit.columbia.edu:~ftp/kermit/e/kproto.doc# >Paul must think "Kermit" means "free". This is no longer true. You're confusing "free" with "public domain". There are all sorts of copyright arrangements in which the author maintains the copyright, but the product remains economically free. The purposes behind keeping the copyright include but are not limited to: preventing other people from exploiting your work for financial gain, preventing others from introducing bugs into software with your name on it, granting special conditions to certain user communities, etc. > Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New > York. The C-Kermit software may not be, in whole or in part, licensed or > sold for profit as a software product itself, nor may it be included in or > distributed with commercial products or otherwise distributed by commercial > concerns to their clients or customers without written permission of the > Office of Kermit Development and Distribution, Columbia University. This > copyright notice must not be removed, altered, or obscured. Nothing in this notice is inconsistent with economically free availability. Now, before you bring up your previous argument with respect to Kermit News Volume 5, let me do it for you: #begin kermit.columbia.edu:~ftp/kermit/e/newsn5.txt# It's KermitWare! While Kermit software is not a commercial product, it is not in the public domain either, and never has been. It is not "shareware." It's not "freeware." It is copyright by Columbia University. See page -TERMS for our terms and conditions. #end kermit.columbia.edu ~ftp/kermit/e/newsn5.txt# This is meaningless unless you also quote the TERMS page: #begin kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc# TERMS AND CONDITIONS The Kermit software--including source code--is furnished without warranty of any kind, and neither Columbia University, nor the individual authors or publishers, nor any institution that has contributed Kermit material, acknowledge any liability for any claims arising from the use of Kermit. Since source code is available, users may fix bugs and make improvements, and are encouraged to contribute their work back to Columbia for further distribution. Kermit software may be ordered by private individuals, corporations, academic or government institutions, and other organizations for their own internal use, but the software may not be resold or otherwise redistributed to external clients, customers, or contractors without written permission of the Manager of Kermit Development and Distribution at Columbia University. Contact us for further information. #end kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc# Again, nothing is inconsistent with economically free availability. Note especially the phrase "Kermit software is not a commercial product", and the fact that "The Kermit Protocol Manual will continue to be freely distributed in perpetuity". Looks pretty free to me. -- -=Paul Flaherty, N9FZX | "Fighter pilots make movies. Bomber pilots make ->paulf@Stanford.EDU | history." -- Jake Grafton -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!utah-morgan!hellgate.utah.edu !cc.usu.edu!jrd Message-ID: <1994Jan25.173740.8796@cc.usu.edu> Date: 25 Jan 94 17:37:40 MDT References: <1994Jan24.011009.2030@eisner> <1994Jan25.151426.22711@omen.UUCP> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Protocol Shootout Results In article <1994Jan25.151426.22711@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > In article <1994Jan24.011009.2030@eisner>, > billy@mix.com (Billy Youdelman) writes: >>In article William C Fenner >> writes: >> >>> But Kermit, in the way that it was set up for Columbia's test, has no >>> way to interrupt the transfer *at*all*. Tough luck if something happens >>> and you don't want to see all the spew on your screen. >> >>How about sending it an error packet? >> >>Billy Y.. >> > > Neat idea. Perhaps the next version of C-Kermit and MSKermit will do that. > Of course an error packet may be as effective as stopping the Queen Mary > by dragging an oar if Kermit already has five 5000 byte packets queued up. > > -- > Chuck Forsberg WA7KGX caf@omen.COM 503-621-3406 > Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ > Omen Technology Inc "The High Reliability Software" > TeleGodzilla BBS:621-3746 FAX:621-3735 CIS:70007,2304 -------------- An error (E) packet is just fine, and it works unless the other side has become rather hopelessly locked up. As I mentioned offline to another person I think I've tried ^C^C maybe twice over the past year, and I tend to use Kermits rather frequently (I wonder why). An Error packet is available from the keyboard during a file transfer session, as are less drastic X (skip this file) and Z (skip the rest of the file group) keyboard interruptions. These features have been in Columbia Kermits for years and years, are part of the original protocol, are described in the user's manual books, are on the screens. Consequently the comment at the top of the inclusion is false. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!nntp.memst.edu!ukma!eng.ufl.edu!saimiri.primate.wisc.edu !sdd.hp.com!sgiblab!darwin.sura.net!howland.reston.ans.net !sol.ctr.columbia.edu!news.columbia.edu!usenet Message-ID: <2i699f$5h2@apakabar.cc.columbia.edu> Date: 26 Jan 1994 17:29:19 GMT References: <1994Jan26.162400.4383@omen.UUCP> Organization: Columbia University From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Protocol Shootout Results In article <1994Jan26.162400.4383@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > > In article <758917572snx@crynwr.com> nelson@crynwr.com (Russell Nelson) > writes: > ... > Bravely spoken by someone with a commercial link to Columbia > University's Kermit software. > ... > The real "wonk issue" is that Columbia knows my observations are > correct. They have not even attempted to rebut them. Frank da > Cruz declined to appear at the Jan 6 Protocol Shootout knowing > full well the troubling questions about Kermit News he would be > forced to address. > I already addressed all these points weeks ago. Chuck clearly believes that by reiterating them on a daily basis, they will become gospel. However, I will not engage in public bickering with someone whose primary debating tactic is to always get in the last word. The Kermit News article speaks for itself -- Chuck can refute it all he wants to, and you, good readers, can judge for yourselves. Bear in mind, however, that this is not an all-or- nothing issue -- use one, use both, use neither. I am only posting this to dispel the notion that anyone is hiding, and to point out that Chuck is acting an awful lot like Senator Joe McCarthy of yore, brandishing his lists, naming names, and assigning guilt by association. I would not like to think that participants in this newsgroup hesitate about their postings for fear they will be publically vilified and ridiculed. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!nntp.memst.edu!ukma!asuvax!farallon.farallon.com!agate !howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!usenet Message-ID: <2imthj$pu5@apakabar.cc.columbia.edu> Date: 2 Feb 1994 00:53:07 GMT Organization: Columbia University From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Protocol Shootout Results Lines: 441 Against my better judgement I promised Chuck I would respond to his "Protocol Shootout Report". I apologize for prolonging this ridiculous debate, and I would encourage Chuck to refrain from further gratuitous snipes at each person who posts a message even remotely supportive of Kermit or critical of Zmodem, not to mention using innocent questions -- even on unrelated topics -- as an opportunity to fire off another salvo. I think everybody comes off looking and feeling better if we just answer users' questions and try our best to solve their problems, and stop using this forum as a soapbox. Chuck says: > For Russ' sake I do hope Crynwr software derives more income as a > result of their relationship with Columbia Kermit than the cost of a > single $20 DSZ registration. And for Chuck's sake, I hope he does not make a regular practice of disclosing business details about his customers in public. This is not a big confidence builder for potential customers. Chuck says: > ...as it was written and as people read it, Kermit News #5 is a > promotional piece that seeks to enhance Columbia's revenues by > trumpeting the relative performance of Columbia's product under a > selected set of conditions and alternatives carefully contrived to > promote the idea that Kermit is faster than competitive alternatives. > Of course it's a promotional piece. However, the test conditions are fair. Four representitive types of files -- including the ones where Zmodem's well-known strengths lie -- were transferred over different types of connections. Chuck's primary complaint, as I understand it, was that I did not use ZMODEM-90(TM)-Moby-Turbo(TM) extensions in my tests. Fine, I never said I did. I used the software that everybody uses and compares Kermit against, the packages we have heard about constantly over our many years of help-desk experience, and the article is totally explicit and detailed about what was tested. Chuck says: > So we're back to where we started before Columbia University's Kermit > News #5 broadside attack on their competition: Use Kermit for > traditional IBM mainframes and other weird iron, otherwise use ZMODEM > to get the best in speed, the reliability of 32 bit CRC, and Crash > Recovery for real world error recovery. That's clearly a skewed opinion. Here is my skewed opinion: Use Kermit anywhere at all. Use Zmodem on a small subset of "anywhere at all". You can't use Zmodem on the rest of "anywhere at all" because it does not work, or it does not exist, in that environment. This includes at least all 7-bit connections, which are quite common outside the BBS world, and all of the "oddball" operating systems that one finds on IBM mainframes, etc, which, one supposes, are only to be sneered at. I would be very surprised to learn of a connection where Zmodem works and Kermit does not. On those connections where "regular" Zmodem protocol works at all, you can get Kermit to work just as well or better. Zmodem-90-Moby-Turbo(TM) might well go faster than Kermit if you have it available to you on both ends, and the connection is cooperative, and if that is true, then hats off to Chuck. Chuck says: > Columbia could have improved on this situation by developing a > compact, high performance version of the WKERMIT (The Source) Kermit > driver that could be used by bulletin boards, Telix, ProComm, Qmodem, > et al. Perhaps it is not too late for Columbia to correct the > situation. This is absolute nonsense, and a red herring on two counts. The implementation Chuck is referring to (a) is nine years old, (b) was a quick hack that hardly ever worked, and (c) depended, in the PC version, on proprietary libraries for communications functions. The "WKERMIT" Chuck is referring to did not allow long packets, had horrible error-recovery characteristics, and because of the communications strategies used, would get hopelessly hung if there were any confusion about modem signals, to the point that you'd have to reboot your PC, and it did not support any kind of flow control. Furthermore, it had no terminal emulator, no script language, no convenience features like key mapping, and none of the server-related Kermit protocol functions are supported. Anybody who wants to check out this "compact, high performance version" of Kermit for themselves, feel free: host kermit.columbia.edu, directory kermit/extra, files wkermit.*. Note: wkermit.exe is binary, the rest are text. In short, it is a primitive package and its Kermit protocol implementation is limited and fragile. It was a stopgap commissioned by The Source [an early online service], cobbled together in a hurry by a contract programmer from even-then obsolete C-Kermit source code, to be used until the real thing came along. Although it was some time in coming, the real thing did, indeed, come along, and WKERMIT was promptly retired. > Columbia could have improved on this situation by developing a > compact, high performance version of the WKERMIT (The Source) > Kermit driver that could be used by bulletin boards, Telix, > ProComm, Qmodem, et al. Perhaps it is not too late for Columbia > to correct the situation. > Red Herring #2 -- Suppose we rephrase this as: "Omen Technology could have improved on this situation by developing a compact, high performance version of the Zmodem-90(TM)-Moby(TM)-Turbo(TM) driver that could be used by bulletin boards, Telix, ProComm, Qmodem, et al. Perhaps it is not too late for Omen Technology to correct the situation." SHOOTOUT RESULTS Chuck says: > Last July Columbia University used its non-profit mail permit to > distribute thousands of copies of Kermit News Number 5. > Point for Chuck. Yes, as a nonprofit institution, we do indeed get a break on bulk 3rd-class mailings. So what? > In "The Truth about Kermit File Transfer Performance" tenured > Columbia University professor... > That I'm not. > ...Frank da Cruz proudly announces that Kermit "outperforms X-, Y-, > and ZMODEM protocol transfers every time." Out of context. Anybody who reads the article knows that that "ZMODEM protocol transfers" refers to the ones that were performed in the suite of tests, using the specified software (Procomm, Telix), and "every time" refers to each test that was performed. Again, I invite anybody who is interested, and especially anyone who feels compelled to take sides on this issue, to actually read the article. I will be glad to send you printed copy if you send me your postal address. You can also ftp it from kermit.columbia.edu, directory kermit/e, files: newsn5.txt (ASCII) newsn5.ps (PostScript) > It is not my intention to defend a competitor's product. But, > the reported Kermit efficiency of Procomm Plus (93%) and Zstem > (97%) are very close to that of Columbia's own MSKermit (99%). > Right; I did not want to imply that all non-Columbia PC Kermit implementations are lousy, but I did want to show that MS-DOS Kermit is equal to or better than the best of them. I also left out some others that were ridiculously bad. > Frank's 104% figure for MSKermit is misleading because the reduced > control character prefixing responsible for the MSKermit speedup also > works sending to Procomm Plus. Columbia does not disclose this > inconvenient result. In fact, C-Kermit sending to Procomm Plus > transferred some of Columbia's test files in less time than the > C-Kermit-MSKermit combination required. > Score half a point for Chuck. It's true, I did not know that Procomm could handle unprefixed control characters. In fact, it can handle *some* unprefixed control characters. But carriage return (Ctrl-M) is not among them, so all we gain in text file transfers in this case is the ability to send linefeed bare. When I repeated the test downloading the same text file to Procomm under the same conditions as the original test, except with all possible control characters unprefixed, Procomm's score went up from 93% to 94%. > After shading the truth about competitors' Kermit downloading > performance, Frank's paper proceeds to redefine the YMODEM protocol > I developed in the 1980's. > Sorry if I misrepresented YMODEM -- Nevertheless, the YMODEM protocol used in the tests was as stated: sb on the host, and YMODEM protocol in the PC software. Whatever it is! > Thanks to Columbia's ignorance of file transfer protocols I don't know > what protocol they actually used for the "XMODEM" and "YMODEM" tests > listed in Columbia's True-Life Benchmarks. > It's clearly stated in the article: sx and sb on the host, XMODEM or YMODEM protocol in the PC software. > But Columbia's published numbers reveal a seriously slovenly > experimental procedure. XMODEM and ZMODEM in all their forms transmit > file data verbatim, without any prefixing. As a result, data patterns > have no effect on X/YMODEM throughput. > The results given in the article are exactly as reported by the software, and each trial was run three or more times. Theory is fine, but in the real world all sorts of factors can cause variations. We have been through this time and again. > In addition, Columbia Kermit programs significantly understate the > time required to perform a file transfer. Kermit reports a file > transfer took 112.98 seconds when in fact the machines were tied up > more than nine seconds longer. > Here's what actually happens: if you install C-Kermit according to instructions, it comes with an initialization file that reads in your dialing and services directories and defines all sorts of macros. Obviously, this can take some time, especially on slow computers. These are convenience features that have nothing to do with file transfer, that can be skipped. sz does not have features like script programming, dialing directories (let alone dialing), and so starts up faster. If you want Kermit to start up as fast as sz, you can tell it to skip the initialization file and give the file-sending and parameter-setting commands on the command line, for example: kermit -Y -v 5 -e 5000 -s foo.zip For real speed, you can even build a nonstandard version of Kermit that excludes all sorts of time-and-space-consuming features: the interactive command parser, the built-in debugger, the character-set translator, etc, and reduce the startup time to practically nil AND make it run faster too. I did not do that, because it would not be representative of the C-Kermit software that people actually use. Second, there is a deliberate default delay of 5 seconds after you give a SEND command to a remote-mode C-Kermit, to give the user time to "escape back" to the local Kermit and give a RECEIVE command. This is purely a convenience feature and has nothing to do with the protocol -- it gives the user time to read an instructional message and then to escape back without seeing the first packet on the screen. Of course you can set the delay to be any length of time you want, including zero, and you can disable this feature altogether. (AND you can also use the autodownload feature to obviate the need for escaping back altogether -- yes: Kermit has autodownload too, *and* autoupload). For the record, Kermit's timers start ticking when the first packet is sent or received, and stop when the last packet is sent or received. > One set of Columbia's measurements was so preposterous that I > simply couldn't resist having a bit of fun with it. We noticed > that cutting the communications speed from 19200 to 9600 > actually increased the speed of a Columbia Kermit file transfer > from 2648 to 2736 characters per second. (p.13, Tables 2 and 5.) > This is indeed what happened. Explain it any way you like. > One of the tricks Columbia used to discredit ZMODEM in their > "True-Life Benchmarks" was to carefully select files with > redundant data that responds unusually well to Kermit's run > length compression while at the same time refusing to use ZMODEM > compression. > In fact, we chose four types of files: 1. A typical text file (the IBM Mainframe Kermit manual). 2. A UNIX binary file, which, admittedly, had big runs of zeros. 3. An MS-DOS binary (.EXE) file (MS-DOS Kermit itself). 4. A ZIP file (the MS-DOS Kermit distribution file set). Each of these files illustrates properties of the two file transfer protocols. Nothing is rigged or pre-engineered here -- these are perfectly normal files. We could easily have left out (for example) the ZIP file, which would have skewed the results far more in favor of Kermit, or picked a text file that could have been compressed a lot more. > The most egregious instance of this deception is seen with Columbia's > selection of a Sun Sparc binary of the "uuencode" program. This is a > tiny program stored in a 24576 byte file. All but a few thousand are > nulls. Naturally this does wonders for Kermit transfer speeds. Had > Columbia's protocol boffins read the sz 3.24 documentation they could > have discovered that ZMODEM compression does even better. > But only if you use it with PC software that includes ZMODEM-90(TM)-etc extensions. I actually did use the compression option (-Z) on sz, but it had no effect since, apparently, Procomm and Telix don't do anything with it. And yes, the "uuencode" file was chosen deliberately to illustrate the dramatic effects of Kermit compression on this type of file. So what? People actually do transfer this type of file from time to time. > Real world users download mostly compressed files,... > This is debatable. As I pointed out yesterday, the readers of this newsgroup are are not typical of the world's computer users at large. > ... and here the winner is YMODEM-g, closely followed by MobyTurbo(Tm) > ZMODEM, regular ZMODEM, with Kermit bringing up the rear. > YMODEM-g has not much more resemblence to a file transfer protocol than Kermit's TRANSMIT command, or "copy foo.zip com1". If it works, of course it's fast, because it doesn't do anything other than blast the data at the other end, all in one piece, with a filename on the front and checksum on the end (I'm sure Chuck will correct me if this is a gross misrepresentation of YMODEM-g technology). Recovery from transmission errors is, to use Chuck's words, "by sudden death". > So why is Kermit not the fastest when it only prefixes a few control > characters? The question is incorrect. Columbia claims that only 0, > 1, and 129 need to be prefixed, but this doesn't work sending to > MSKermit 3.11. > Of course it doesn't, we never said it did. We were using MS-DOS Kermit version 3.13, which is the first release to support this feature. Also, our advice about which characters need to be prefixed goes into a lot more detail -- there are no simple formulas. Today, for example, I found that when using a local Annex terminal server, the following characters must be prefixed in addition to whatever might be required by the Kermit programs themselves: 15 18 21 23 29 127 143 146 149 151 157 255. Not all connections in the world are totally transparent, the way BBS users are accustomed to. > The most impressive demonstration, and the likely reason Frank da Cruz > did not choose to appear at the Shootout is Kermit's performance in > the noise test. Or, to be more precise, Kermit's non-performance. In > the Kermit News True-Life Benchmarks, Frank da Cruz specified a window > size of 5 and a packet length of 5000. Undoubtedly Frank chose this > long packet length to minimize Kermit's high per packet overhead > compared to ZMODEM SUBpackets. > 8-10 bytes out of 5000 = 0.18 percent. Who is going to quibble about that? Of course I chose long packets to improve performance -- that's what they're for. This is all explained in the article. > XMODEM, YMODEM and Kermit cannot resend a packet with a different > size. The problem is even worse with Kermit's selective > retransmission protocol. When we attempted to replicate Columbia's > 9600 bps plus noise test (Table 5) Kermit failed every time. Well, > almost every time. The first few times Kermit worked, but that was > only because C-Kermit quietly refused to send the specified 5000 byte > packets because a needed "set buffer" command was not included. When > Kermit actually uses the specified 5000 byte packets with noise bursts > at 2 second intervals, no data packets get through. Why? It takes 5 > seconds to send a 5000 byte packet at 9600 bps but the specified noise > bursts come faster than that. Kermit croaks every time unless the Jim > Kirk Kobiashi Maru procedure is used (relax the test). > Chuck makes a good point here. He's right: if the noise bursts came at precise 2-second intervals, the first data packet would never have gotten through. But the noise bursts were being generated on a UNIX system, whose actions are governed by a scheduler, and are therefore not precise. Once the first data packet got through, the remaining packets were shortened automatically. I deliberately chose the worst possible conditions under which Kermit could function at all with the same settings that I was using in the preceding tests. I could have sweetened the results considerably by tailoring Kermit's settings *in advance* for noise resistence, and increasing the noise level. For example, noise every 1/2 second, and short, 94-byte packets (which are, by the way, Kermit's default) rather than 5K packets. Kermit would have come out even further ahead than it did in the article. > I made an informal survey of the guests at the shootout. As so > many have noted, line noise today manifests itself mostly in > disconnected calls. > We've been through this before too. Just because this is 1994, you can't assume that all telephone connections are clean (here in the New York City area, T1 clock slippage is still a frequent occurrence). Ask residents of other countries -- especially in Eastern Europe, the former Soviet Union, China, Africa, and South America, about their telephone systems. We also cannot assume that everybody in the world is using error-correcting modems. Even assuming all that were true -- no more noise, no more errors -- we still have other sources of error, overlooked all too often: improperly (or un-) implemented flow control, data overruns on PCs that do not have buffered UARTs, interrupt conflicts, etc. > When this happens ZMODEM's Crash Recovery is relevant, allowing the > safe resumption of interrupted file transfers. Since Kermit has no > such feature Columbia chose not to discuss this most vital of ZMODEM's > many features. > ZMODEM's crash recovery is indeed a useful feature, but... (a) It only works for binary-mode transfers. (b) It only works when the file sender has a stream-oriented file system that supports an "fseek()" operation. It doesn't work for text-mode transfers because files can change size during text-mode transfer because of record-format conversion. It doesn't work on record-oriented file systems, or with record-oriented file formats. A fully capable "crash recovery" feature would work for both text and binary mode transfers, and it would not make any assumptions about the features of the file system. It would be built into the protocol at the session layer. It would involve checkpoints, commitments, and protocol messages that would allow resumption not only of an interrupted file transfer, but even of the connection itself. These are complicated issues requiring a lot more thought than "hmmm, how long is the file? n bytes? OK, fseek(n) and start blasting away". This kind of "crash recovery" could be added to Kermit software with about five minutes' programming time, but it would be useful only in the circumscribed world where Zmodem's method is also useful, and Kermit caters to a more diverse audience. When crash recovery appears in Kermit protocol and software, it will be generally useful. Later, Chuck says: > This historical dissertation overlooks one critical fact. If a > desired text translation is not performed by the file transfer > protocol, the translation can be made later. No information lost. > > But when Kermit modifies files with spurious text translations > that file is destroyed. > > In the real world one cannot equate the two situations. > No matter whether the default transfer mode is text or binary, somebody will transfer files in the wrong mode; it can't be avoided. Chuck is right, transferring a binary file in text mode results in garbage. But: "If a desired text translation is not performed by the file transfer protocol, the translation can be made later. No information lost." Is it? Maybe this is true in the English (ASCII) speaking world. Do any readers of this newsgroup transfer textual data written in Albanian, Bulgarian, Byelorussian, Czech, Danish, Dutch, Faeroese, Finnish, French, German, Hebrew, Hungarian, Icelandic, Irish, Italian, Japanese, Macedonian, Norwegian, Polish, Portuguese, Romanian, Russian, Serbocroatian, Slovak, Slovene, Spanish, Swedish, or Ukrainian? Between unlike systems that use totally different encodings for the "special characters" of your language? Did you know that Kermit handles the character sets for all these languages, and more? Let's look at just (say) German. Here are a few of the common *and* *totally* *different* encodings I can think of for German: German ISO 646, ISO 8859-1 (and -2), IBM PC code pages 437, 850, and numerous others; IBM Mainframe (EBCDIC) code pages 037, 500, and numerous others; DEC Multinational, Data General International, Macintosh, Atari, HP Roman8, NeXTSTEP. Is it the responsibility of every German-speaking computer user to know all of these character sets and have translation utilities that work between every pair of them on every kind of computer? OK, so everybody should speak English and then everything works. But then what about record formats? Suppose I transfer a text file from a record-oriented system in binary mode by mistake. I lose the record boundaries. Suppose it's a BASIC or FORTRAN program, or a poem. Vital information is lost -- the program won't compile, the poem won't scan. In an ideal world, computers would have been designed from the beginning with considerations like this in mind. Imagine how easy all our lives would be if file systems and organizations and character sets were all compatible? Then we would have one and only one transfer mode, and it would always work, and always produce useful results. But this is the real world, in which nobody can agree on anything, and everyone proclaims their own way of doing things a "standard". - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!ornl!rsg1.er.usgs.gov!darwin.sura.net!howland.reston.ans.net !cs.utexas.edu!uunet!nwnexus!camco!camco!not-for-mail Date: 23 Feb 1994 19:42:27 -0800 Organization: Celestial Software, Mercer Island, WA Message-ID: <2kh7n3$h26@camco.celestial.com> References: NNTP-Posting-Host: camco.celestial.com From: bill@camco.celestial.com (Bill Campbell) Subject: Re: SCO kermit In frank@tsh.com (Frank Mostek) writes: : :Would a kind soul please email me the SCO version of kermit? I bought :the source, but our customer does not have the C compiler on the SCO :box, and I don't have access to a SCO box. Considering that the binary for 3.2v4 is 437632 stripped, this isn't really a candidate for e-mail. I have it on ftp.celestial.com if you have ftp access. Bill -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.dcom.modems Path: cs.utk.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com !library.ucla.edu!ihnp4.ucsd.edu!dog.ee.lbl.gov!hellgate.utah.edu !cc.usu.edu!jrd Message-ID: <1994Mar7.093039.12780@cc.usu.edu> Date: 7 Mar 94 09:30:39 MDT References: <1994Mar7.134440.29536@ibr.cs.tu-bs.de> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Kermit: How to get rid of echos ? In article <1994Mar7.134440.29536@ibr.cs.tu-bs.de>, c0033010@ws.rz.tu-bs.de (Sven Kuehne) writes: > > I don't know if my question will fit into this newsgroup, but comp.protocols. > kermit seems to be a bit deserted ... > > How can I tell Kermit to be quiet when executing a script ? I only wanna > see thing I write out by using 'echo ...'. I don't want things from > 'output ...' or the replies of the other side written to the screen. I've > tried 'set local-echo off' but it doesn't help ! > > Does anyone know how to achieve this ?! It might be simple ... > Sven > #===========================================================================# > # Sven Kuehne Rechenzentrum tel +49 531 391-5548 # > # TU Braunschweig fax +49 531 391-5549 # > # Abteilung Netze und Hans-Sommer-Str. 65 email c0033010@ws.rz.tu-bs.de # > # Arbeitsplatzrechner D-38092 Braunschweig s.kuehne@tu-bs.de # > #===========================================================================# Two answers for you. 1. As discussed in the user's manual, the book "Using MS-DOS Kermit", the script commands INPUT and OUTPUT control their echoing with SET INPUT-ECHO ON or OFF. Maybe you need to acquire the manual, details on screen two of the Help command. 2. The Kermit News group material goes straight to Columbia rather than being reflected worldwide. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone !newsxfer.itd.umich.edu!caen!usenet.cis.ufl.edu!usenet.eel.ufl.edu !news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net !news.sprintlink.net!EU.net!sun4nl!echelon!kees Organization: Echelon Consultancy, Enschede, The Netherlands Date: Mon, 31 Oct 1994 17:01:10 GMT Message-ID: References: <392u8h$hvr@apakabar.cc.columbia.edu> From: kees@echelon.nl (Kees Hendrikse) Subject: Re: ANSI (Was: MS-DOS Kermit 3.14 Beta-9 Ready) In <392u8h$hvr@apakabar.cc.columbia.edu> Frank da Cruz writes: > > In article kees@echelon.nl (Kees Hendrikse) writes: >> (...) would it be very hard to also implements the 'SCO console' emulation, >> a.k.a. SCO-ANSI? > I believe this is basically the current ANSI screen handling, but with the > keyboard handled differently -- instead of transmitting the characters > associated with the keys, the scan codes are transmitted. Scan codes are optional (settable with stty for scan-code terminals). In Ascii-mode the function keys send escape sequences. F1 sends ESC[M, shift-F1 sends ESC[Y etc. Screen handling is PC-Ansi/vt100-like, except for scrolling, coloring, special things like 'send-screen-to-host'. > To the best of my knowledge, this is used only for communicating with the > SCO console driver. True? SCO ansi can be used via the serial driver as well, by using the 'ansi' termcap/terminfo entries. Quite a few terminal-emulation packages have a sco-ansi option now (James River's Ice-ten, for example), which makes it the emulation of choice with these programs. -- Kees Hendrikse | email: kees@echelon.nl | ECHELON consultancy and software development | phone: +31 (0)53 836 585 PO Box 545, 7500AM Enschede, The Netherlands | fax: +31 (0)53 337 415 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu !vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com !news.mathworks.com!udel!news-4.nss.udel.edu!chopin.udel.edu!not-for-mail Date: 1 Nov 1994 16:10:18 -0500 Organization: Broken Toys Unlimited Message-ID: <396arq$fqc@chopin.udel.edu> References: <1994Nov1.100933.2067@gems.vcu.edu> From: darkstar@chopin.udel.edu (Jerry Alexandratos) Subject: Re: More lines per page? In article <1994Nov1.100933.2067@gems.vcu.edu>, Brainwave Surfer wrote: :Dear Netbeings, : I have a wonderful relationship with MS-dos kermit. apart from dos, :the package is fine. I'd like to figure out how to set the video such :that I can use one of the other modes, like 50 lines per screen, etc. :Everything else is ok, but i'm lusting for more of the page like I can :get on my Decterms in Motif. : :Jim [sig deleted] Okay, here's what you need to do on both ends of the connection. PC--make sure you've got either an EGA card (for 43 line mode) or a VGA card (for 50 line mode). Some cards support some funky things like 60 lines under some Super-VGA setting or another. make sure you load an ANSI driver like ansi.sys or nnansi.sys issue the following mode command `mode con: lines=50'. start kermit. UNIX-connect to host. issue an eval `tset -sQI ` command to set the TERM and TERMCAP environment variables. For example eval `tset -sQI vt220` evaluates and sets the variables for vt220 term. Make sure that you put in the ``I'' argument. If you don't, then you'll see your screen cut in half and only the first 25 lines being drawn on. If this happens, then you'll have to go to the kermit command line and do a `ru mode con: lines=50' command to reset your local terminal. Issue the `stty rows 49' command to set the number of rows (or `stty rows 50' if you don't use the status line at the bottom of the screen), followed by a `reset' command. That should do it. I don't know how to do this if you're connecting to other types of host. I think that for IBM's it doesn't make a difference if they're in fullscreen mode, then they'll use all of the available lines. As for other types of hosts, your mileage may vary. --Jerry -- |> Jerry Alexandratos ** "vengo de la tierra del <| |> darkstar@strauss.udel.edu ** fuego ten cuidado cuando <| |> darkstar@canary.pearson.udel.edu ** llamas mi nombre..." <| -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu !vixen.cso.uiuc.edu!howland.reston.ans.net!gatech !news-feed-1.peachnet.edu!emory!metro.atlanta.com!spcuna!ritz!kudut References: Organization: Mordor International BBS - Jersey City, NJ Date: Tue, 1 Nov 1994 18:03:47 GMT Message-ID: From: kudut@ritz.mordor.com (Ken Udut) Subject: Re: Receiving files "automatically" In article , drw@runge.mit.edu (Dale R. Worley) writes: > >I'd like to know if there's any way that I can get (MS-)Kermit to >receive a file "automatically" when the remote end runs a Kermit that >is attempting to send a file. As far as I can tell, right now once I >start the remote Kermit sending, I have to get out of CONNECT, and >then manually issue a RECEIVE command, then reconnect. This seems >quite pointless, so probably there is a way to make it all happen >automatically. But I haven't been able to find it in the >documentation. What version of Kermit are you running? Latest beta test is 3.14, revision 10, available at kermit.columbia.edu under the directory: /kermit/test/bin/mstibm.zip To automatically send/receive files via Kermit, please check out the KERMIT.UPD file that comes with the beta. It explains how to engage autoupload/download with Kermit. NOTE: MS-Kermit must be version 3.14, and C-Kermit (assuming that is what is on the host side) must be version 190. >Also, is there a "dial this number and connect me to it" command? >So far, I have been stuck doing a CONNECT and then manually issuing >ATDT to the modem. To dial, type "dial xxx-xxxx" or edit the DIALUPS.TXT file and add the phone number you wish to dial in the format specified in that file. If I'm not mistaken, if you use the "dial" macro, it will connect you. Otherwise, if you are a purist and want to do ATDT before the phone numbers, then put a CONNECT at the bottom of your MSCUSTOM.INI. >And why is it that Kermit comes with almost no documentation? It comes with a *lot* of documentation. The KERMIT.BWR and KERMIT.UPD file are both sets of documentation. If you issue a HELP at the Kermit prompt, you get more information. While you are typing in a comment, but you are not sure what to type in next, press a ?, and you will magically get help for that command. Indeed, you can learn almost everything there is to know about MS-Kermit, programming scripts, macros, etc. (which aren't really all that hard!) simply by using the information provided with the Kermit distribution. >Or is the rumor that Kermit is "free" just a front for selling books? Indeed - it is a rumour. Is it true? No. Ken kudut@ritz.mordor.com LISTOWNER of Y-RIGHTS@SJUVM.STJOHNS.EDU-'discussion on the rights of kids/teens -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!wupost!simtel.coast.net!w8sdz Message-ID: <9411030524.AA13559@SimTel.Coast.NET> Date: Thu, 3 Nov 1994 05:24:58 GMT Organization: SimTel, the Coast to Coast Software Repository (tm) References: <397oln$cp3@israel-info.datasrv.co.il> From: w8sdz@SimTel.Coast.NET (Keith Petersen) Subject: Re: Zmodem on kermit 4dsoft@zeus.datasrv.co.il (4th Dimension) writes: > >Im looking for a way to perform file transfer via the Zmodem utilities >while working in kermit. > >Examples will be appreciates. ; ;Thanks to Jason Merrill for this ;define to add zmodem protocol transfers. Add it to your mskermit.ini. ; define rz run dsz F ha cts est 0 14400 rz \%1 \%2, define sz run dsz F ha both est 0 14400 pB4096 sz \%1 \%2, define t run dsz F ha cts est 0 14400 t \%1 \%2, Keith -- Keith Petersen Moderator of comp.archives.msdos.announce and the MSDOS-Ann mailing list Internet: w8sdz@SimTel.Coast.NET or w8sdz@Vela.ACS.Oakland.Edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu !cc.usu.edu!jrd Message-ID: <1994Nov3.223304.31997@cc.usu.edu> Date: 3 Nov 94 22:33:04 MDT References: Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: 132-column Mode and MS-Kermit Verbs In article , korty@london.physics.purdue.edu (Andrew J. Korty) writes: > > My friend and I just discovered the world of 132-column mode, and we > have a few questions for all who are familiar with its numerous > wonders. > > 1. My friend wants to define a key to switch between the modes while > in terminal emulation mode, but we couldn't find a verb that does > this. Is using verbs the only way? Also, we'd like to know if > there's a way to define a key to escape back to command mode and > execute a Kermit command (of any kind). Check the user's manual, the book "Using MS-DOS Kermit" whose details are given on the Kermit HELP screen and the *.UPD files issued since then. You can assign a Kermit macro as the definition of a key. The macro can do anything you could say at the Kermit prompt, including issue SET TERM commands. Syntax is SET KEY keycode {\Kmacroname} and the \K must be inside the curly braces. > 2. I'm running DOS Kermit under OS/2 in a full-screen DOS session. > When I use 132-column mode, everything works fine until I switch back > to the desktop, at which time the video proceeds to get completely > screwed up. The only way to save things is to go back to Kermit and > do an Alt-X (which puts the screen back in 80 column-mode) and then go > back to the desktop (which is still screwed up) and activate a screen > saver or something to refresh the screen. It's between OS/2 and your video driver and your monitor. Please remember that there is no standard on 132 column video modes so that OS/2 has no idea of what state the display is in and hence little idea of what to do about it. Better video drivers could help more, however. > 3. Also, Kermit's documentation claims that it can auto-detect the > screen width requested by the host, but doesn't seem to. Maybe you mean the opposite here. Hosts can request 80 or 132 columns from VTxxx terminals, nothing more. Kermit obeys those requests. Perhaps you mean that Kermit can tell the host its current screen size upon request, which is true. There is no "auto-detect" in this arrangement, by either host or terminal emulator. Kermit can also report screen size in Telnet Options packets, if the host agrees to do so. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu !news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net !sol.ctr.columbia.edu!news.columbia.edu!usenet Date: 7 Nov 1994 22:26:13 GMT Organization: Columbia University Message-ID: <39m9i5$e00@apakabar.cc.columbia.edu> References: <39lv9v$2s@vixen.cso.uiuc.edu> From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Will the New MS-DOS Kermit have MINPUT? In article <39lv9v$2s@vixen.cso.uiuc.edu> adam@symcom.math.uiuc.edu (Adam H. Lewenberg) writes: > > Will the New MS-DOS Kermit have the MINPUT command? I would like my > scripts to work in both MS-DOS Kermit and C-Kermit, so it would be > nice if MINPUT was supported n MS-DOS Kermit. Adam Lewenberg > It is kind of late in the Beta cycle to consider adding this. However, you might be able to make do by defining an MINPUT macro, something like this (courtesy of James Sturdevant): define minput set alarm \%1,- :top,- if alarm end 1,- input 1 \%2,if success asg mynput 1,if success end 0,- if not def \%3 goto top,reinp 0 \%3,if succ asg mynput 2,if succ end 0,- if not def \%4 goto top,reinp 0 \%4,if succ asg mynput 3,if succ end 0,- if not def \%5 goto top,reinp 0 \%5,if succ asg mynput 4,if succ end 0,- if not def \%6 goto top,reinp 0 \%6,if succ asg mynput 5,if succ end 0,- if not def \%7 goto top,reinp 0 \%7,if succ asg mynput 6,if succ end 0,- if not def \%8 goto top,reinp 0 \%8,if succ asg mynput 7,if succ end 0,- if not def \%9 goto top,reinp 0 \%9,if succ asg mynput 8,if succ end 0,- goto top and then use it like this: minput 60 CONNECT ERROR {NO CARRIER} BUSY RING if fail errfail {No response from the modem} if eq \v(program) C-Kermit asg mynput \v(minput) goto CASE_\m(mynput) - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu!news.mathworks.com!hookup!swrinde!cs.utexas.edu!uunet!winternet.com!jamess From: jamess@winternet.com (James Sturdevant) Subject: Re: Will the New MS-DOS Kermit have MINPUT? Date: 8 Nov 1994 23:35:50 GMT Organization: StarNet Communications, Inc Lines: 21 Message-ID: <39p20m$rn1@blackice.winternet.com> References: <39lv9v$2s@vixen.cso.uiuc.edu> <39m9i5$e00@apakabar.cc.columbia.edu> NNTP-Posting-Host: icicle.winternet.com X-Newsreader: TIN [version 1.2 PL2] Jeffrey Hurwit (jhurwit@netcom.com) wrote: : In article <39m9i5$e00@apakabar.cc.columbia.edu>, : Frank da Cruz (fdc@fdc.cc.columbia.edu) wrote: : >In article <39lv9v$2s@vixen.cso.uiuc.edu> adam@symcom.math.uiuc.edu (Adam H. : >Lewenberg) writes: : >> : >> Will the New MS-DOS Kermit have the MINPUT command? I would like my : >> scripts to work in both MS-DOS Kermit and C-Kermit, so it would be : >> nice if MINPUT was supported n MS-DOS Kermit. Adam Lewenberg : [macro and example of how to use it deleted] : Yes, this would work, but it's a little big, and memory is at a : premium for some of us. I tend to use take files more, and save : memory for key settings and screen rollback. Well, there is no reason that you can't put the text into a take file and then define minput to take the take file. Macros are no more than memory resident take files. JamesS -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu !news.mathworks.com!udel!gatech!howland.reston.ans.net !sol.ctr.columbia.edu!news.columbia.edu!usenet Date: 8 Nov 1994 16:52:40 GMT Organization: Columbia University Message-ID: <39oaco$5us@apakabar.cc.columbia.edu> References: From: fdc@fdc.cc.columbia.edu (Frank da Cruz) Subject: Re: Receiving files "automatically" In article drw@runge.mit.edu (Dale R. Worley) writes: > Hmmm... Just checked my KERMIT.HLP (version 3.13, gotten from > watsun.cc.columbia.edu, I think, but I can't check right now, its FTP > server is hosed), and it doesn't say that, although it does mention > the DIAL command in passing at one point. > My comments were in reference to version 3.14. I think you will find a lot of improvements in version 3.14 over 3.13. > If I wanted to buy the manual for a telecomm program, I'd go to my > local software store and buy Procomm. > A noble attitude. In other words, since you don't want to buy a manual, you expect real human people to work for you, for free. To develop software for you AND document it, AND answer your questions, all for free, and listen to your complaints about how they did it. Please, go buy Procomm. - Frank -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone !newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!news.mathworks.com !hookup!usc!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu !cc.usu.edu!jrd Message-ID: <1994Nov10.062523.32448@cc.usu.edu> Date: 10 Nov 94 06:25:23 MDT References: <39kmo6$k82@ctsc.hkbc.hk> Organization: Utah State University From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: Can Kermit 3.14 run on PCTCP's ODIPKT In article <39kmo6$k82@ctsc.hkbc.hk>, s11976@ctsc.hkbc.hk (PM Wong) writes: > > We have been using Kermit's telnet (over either packet driver or Novell's > ODI, i.e. Da Lancinni's ODIPKT) for quite some time now. Recently some > PCTCP's apps have to be run and we want to keep the user Kermit telnet. > So it'll be handy if Kermit can run on top of PCTCP's ODIPKT > (I don't want to go for the tnglass option as batch files have been > written that use kermit's telnet all along) ---------- I replied to this privately but here is a summary. FTP Inc's ODIPKT has a license detection feature in ARP which prevents Kermit or other non-FTP program from accessing ARP packets over their ODIPKT. Both FTP's stack and Kermit will run over Harvard's ODIPKT, but never together. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com !howland.reston.ans.net!news.sprintlink.net!nwnexus!news.halcyon.com!coho!ken Date: 9 Nov 1994 19:46:33 GMT Message-ID: <39r8up$37e@news.halcyon.com> References: <39eco1$h7k@news.halcyon.com> From: ken@coho.halcyon.com (Ken Pizzini) Subject: Re: C Kermit and meta keys In article <39eco1$h7k@news.halcyon.com>, Ken Pizzini wrote: > > In article , > Jason Venner wrote: >> >>I use C-Kermit on my linux machine and dial into various unix hosts. >> >>Kermit does not seem to honor the meta key. >>Is there a way to make it recongnize 8 bit characters and pass them through >>to the remote side? > > set term byte 8 This was only a partial answer. He also needed to set command bytesize 8 --Ken Pizzini -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Newsgroups: comp.protocols.kermit.misc Path: cs.utk.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Subject: Re: C-kermit -ix and binary transfers (not working) Message-ID: <1994Nov19.182311.33328@cc.usu.edu> Date: 19 Nov 94 18:23:11 MDT References: <3am2rr$ete@vixen.cso.uiuc.edu> Distribution: usa Organization: Utah State University Lines: 34 In article <3am2rr$ete@vixen.cso.uiuc.edu>, adam@symcom.math.uiuc.edu (Adam H. Lewenberg) writes: > I am having some trouble sending binary files from the UNIX machine at > school to my OS/2 system at home. Here is what happens: > > 1. If I type kermit -ix, escape back to my OS/2 Ckermit, and then type > 'get file.zip', my OS/2 C-kermit starts receiving the file but announces > that the FILE TYPE is "TEXT (no translation)". Huh? > > 2. If I start kermit with no command line options, type > 'set file type binary' at the C-kermit prompt, type 'send file.zip', > escape back to the OS/2 C-kermit and then type 'receive' my OS/2 > C-kermit recieves the file and tells me the FILE TYPE is BINARY. > > > Why does 2 work while 1 does not? Shouldn't the '-ix' force all file > transfers to be binary? I used to have NO trouble (before I installed > the current version of the Unix C-kermit). > > The Unix C-kermit is > > C-Kermit 5A(190), 4 Oct 94, for Solaris 2.x > Copyright (C) 1985, 1994, > > while the OS/2 kermit is > > C-Kermit 5A(190) BETA.23, 18 Sep 94, for OS/2 2.11 32-bit > Numeric: 501190 ----------- I believe the release notes for C Kermit explain that the client now controls file TYPE via the SET FILE TYPE command given on the client. It's part of file attributes, named the "whatami" component, where the client informs the server of its binary/text state. It's a step forward, really. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1194 of comp.protocols.kermit.misc: Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!spool.mu.edu!agate!overload.lbl.gov!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc,alt.winsock Subject: Re: winsock/pkt dvr hack possible? Message-ID: <1994Nov21.105430.33454@cc.usu.edu> Date: 21 Nov 94 10:54:30 MDT References: <3a67j8$j39@Mercury.mcs.com> <3anvci$dut@relay.tor.hookup.net> Organization: Utah State University Lines: 29 Xref: cs.utk.edu comp.protocols.kermit.misc:1194 alt.winsock:12192 In article , soren@aztec.co.za (Soren Aalto) writes: > In article <3aoc2h$bit@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes: > >>>> Jeff is correct. The top of a sockets API is a TCP stream channel of >>>>bytes, not packets. "It could be done..." means creating a second TCP/IP >>>>stack feeding from the streams channel and packaging it into TCP/IP over >>>>Ethernet frames to be passed to the application. Not very desirable, nor >>>>realistic. >>>> Joe D. > And _that_ is the real problem. I have wondered at times if the > TCP/IP stack functionality and the Comms/SLIP/PPP functionality > shouldn't be separated into two programs--you could have a > packet driver that "reflects" stuff & attach the comms driver > for SLIP/PPP/whatever to one side and Winsock to the other. ----------- Nice idea but not practical here. There are a great many coupling threads (variables, calls) between the high level and comms level material in Kermit so that control may be exercised and speed retained. And there is much more to comms than serial or the internal TCP/IP stack; SET PORT exhibits the list (and some choices transparently encompass two or three variations from the same vendor). Winsock is for pure Windows programs, not for DOS programs. MS-DOS Kermit removes itself from comms channels when done with them. Few commercial TCP/IP stacks do so (none that I know of). Were winsock guys to get off the pot when done the problem would be smaller. So please consider hounding your winsock vendor to go un-TSR upon last close and to not be present until an application makes a demand. Joe D. -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===- Article 1176 of comp.protocols.kermit.misc: Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!library.ucla.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.kermit.misc Subject: Re: Question about ASK usage in MS-Kermit script Message-ID: <1994Nov20.184340.33391@cc.usu.edu> Date: 20 Nov 94 18:43:40 MDT References: Organization: Utah State University Lines: 23 In article , mrbaker@hodcs.ho.att.com (-M.BAKER) writes: > Hello: > > I have a question about ASK. I am writing an MS-Kermit > script which prompts > the user to enter a filename, so I "ASK" for it. No problem > there. But I would like to be able to detect if the user merely > hits the ENTER key without typing anything else in first. > > There is probably an obvious answer. I have looked all over & > experimented with no success. I am a new user of Kermit, hence I > am working from .HLP, .UPD, and .BWR while waiting for my copy > of "the book" to arrive. > > Can someone please help? (Examples appreciated) ----------- ask \%a prompt> prompt>