Info-Kermit Digest Mon, 16 Sep 1991 Volume 14 : Number 5 Today's Topics: MS-DOS Kermit 3.11 is Released! New Second Edition of "Using MS-DOS Kermit" Kermit, TCP/IP, Packet Drivers, and the Future Adding TCP/IP Features to MS-DOS Kermit Digest submissions may be sent to Info-Kermit@WATSUN.CC.COLUMBIA.EDU or KERMIT@CUVMA.BITNET. Requests for addition to or deletion from the Info-Kermit subscriber list should be sent to LISTSERV@CUVMA.BITNET or LISTSERV@CUVMA.CC.COLUMBIA.EDU. These messages must be of the form: SUBSCRIBE I-KERMIT (To start a subscription) UNSUBSCRIBE I-KERMIT (To cancel a subscription) REGISTER I-KERMIT (To correct your name) Kermit files may be obtained over networks and by mail order. On the Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280 running UNIX (SUNOS 4.1), IP host number 128.59.39.2. Login as user anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired files. The Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e. Test versions are in kermit/test. All files in these directories should be transferred in text (ASCII) mode. Binaries are in kermit/bin (use ftp in binary mode). You can also get Kermit files over the BITNET/EARN network; to get started send a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA. For detailed instructions, read the file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV). To order by mail, request a complete list of Kermit versions and an order form from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025 USA. ---------------------------------------------------------------------- Date: Mon, 16 Sep 1991 14:00:00 EDT From: Christine M Gianone Subject: MS-DOS Kermit 3.11 is Released! Keywords: MS-DOS Kermit 3.11, TCP/IP, MCGA, Dialing Directory, Windows 3.0 This is to announce the final release of MS-DOS Kermit 3.11 from Professor Joe R. Doupnik of Utah State University, and a new Second Edition of the documentation, "Using MS-DOS Kermit" (see message below). The major new feature of version 3.11 is its built-in support for TCP/IP networking, adapted from parts of the Waterloo TCP package from Erick Engelke of Waterloo University in Ontario. Also included are script language improvements that allow for a much improved DIAL command that can use a plain text file as a dialing directory, and VT220 emulation to fill the gap between VT102 and VT320. And finally, a last-minute, down-to-the-wire improvement: support for high-resolution Tektronix graphics on the PS/2 Model 25 and 30 MCGA video adapter. Give the command SET TERMINAL GRAPHICS VGA to use it (otherwise Kermit thinks the MCGA is a CGA, and uses low-resolution graphics). TCP/IP NETWORKING Why add TCP/IP to Kermit? Many people use both network and serial connections, and until now had to switch between a Telnet program (which doesn't support serial connections) and Kermit (which didn't support Telnet connections). For file transfer, the TCP/IP FTP protocol, while fast, does not support many of Kermit's advanced features. Kermit offers you features not found in Telnet and FTP: a script programming language, flexible key mapping, macros, international character set translation, and VT320 and Tektronix 401x terminal emulation. Perhaps most important of all, now you have a single application program and a common user interface for both serial and network communication. Kermit's TCP/IP and TELNET implementation takes up only about 30K of additional program space. It runs only over Ethernet-style packet drivers (see Joe's article below) available from your network board vendor, or via anonymous FTP from Clarkson University, host sun.soe.clarkson.edu [128.153.12.3], cd pub/ka9q, use "type binary", get the appropriate zip, arc, zoo, etc, files, use PKUNZIP, PKXARC, or ZOO on your PC to unpack them, read the files READ.ME, MANIFEST.DOC, and INSTALL.DOC, and take it from there. Copies are also available on watsun.cc.columbia.edu in kermit/packet-drivers (source and documentation) and kermit/packet-drivers-bin (PC binaries). Kermit supports downloading of its network parameters from BOOTP and RARP servers, making it possible for all users of a corporate or campus network to have the same initialization file -- a big plus for network managers. Keep your network information in a central database, rather than spread around on scattered PC hard disks and diskettes! Kermit's TELNET implementation automatically negotiates TELNET protocol parameters such as local echoing, so connecting to a linemode TELNET server (such as found on an IBM mainframe) works automatically. However, Kermit does not include built-in 3270 terminal emulation, so it is not (yet) a replacement for tn3270. But, it can be used with reverse telnet terminal servers connected to IBM 7171 or other 3270 protocol converters. Contrary to expectations, Kermit *can* make TCP/IP connections from within a Microsoft Windows 3.0 Enhanced Mode window. Kermit does not support multiple simultaneous TCP/IP sessions, and the fact that you can run it under Windows is not, unfortunately, an escape clause to this rule. The packet driver only allows one one application per protocol; this also means, for example, you can't use Kermit and (say) NCSA telnet at the same time for TCP/IP connections. However, you can still have multiple copies of Kermit running, as long as each one is using a different communication method, or a different serial port. Read the new help and beware files for more information about TCP/IP. DIALING DIRECTORY AND MODEM SUPPORT Kermit's new dialing directory is an ordinary plain-text file that Kermit's DIAL macro searches using Kermit's new OPEN, READ, and CLOSE commands. To take advantage of this new feature, make sure you get a copy of the new sample initialization file, MSKERMIT.INI, as well as the Hayes modem dialing script program, MSIHAY.SCR (which you must rename to HAYES.SCR). A sample dialing directory is available as MSIDIA.TXT (which you must rename to DIALUPS.TXT). Kermit can also manage other types of modems besides Hayes. Two steps are necessary: (1) change the definition of the "_modem" variable in MSKERMIT.INI, and (2) write a dialing script program for your modem, to substitute for HAYES.SCR. An example is provided for the IBM/Siemens/Rolm CBX data phone (ROLMphone) in the file MSIROLM.SCR (which you should rename to ROLM.SCR). Readers are encouraged to develop scripts for other kinds of modems and dialing methods, following the conventions used in HAYES.SCR and ROLM.SCR, and send them in to us for distribution. NEW FILES: Internet anonymous ftp EARN/BITNET watsun.cc.columbia.edu KERMSRV@CUVMA Description GENERAL FILES kermit/a/mskerm.hlp MSKERM HLP Help file (plain text) kermit/a/mskerm.bwr MSKERM BWR "Beware File" (bugs & limitations) kermit/a/mskermit.ini MSKERMIT INI Sample initialization file kermit/a/mskermit.pch MSKERMIT PCH Sample patch file kermit/a/msidia.txt MSIDIA TXT Sample dialing directory file kermit/a/msihay.scr MSIHAY SCR Hayes modem dialing script kermit/a/msirolm.scr MSIROLM SCR ROLMphone dialing script EXECUTABLES kermit/bin/msvibm.exe (none) Executable Kermit program for IBM PC kermit/bin/msvibm.pif (none) Microsoft Windows 3.0 PIF file kermit/a/msvibm.boo MSVIBM BOO BOO-encoded .EXE file for IBM PC kermit/bin/msvgen.exe (none) Generic MS-DOS exectable kermit/a/msvgen.boo MSVGEN BOO BOO-encoded .EXE for generic DOS SOURCE FILES kermit/a/ms*.asm, ms*.h MS* ASM, MS* H Microsoft assembler source files kermit/a/msn*.* MSN* * C-language network source files kermit/a/msv*.lnk MSV* LNK Linker command files kermit/a/msv*.mak MSV* MAK Makefiles for "make" All MS-DOS 3.11 IBM PC Kermit files have been removed from the test directories, kermit/test/ms*.* on watsun and T:MS* * on KERMSRV. The ".boo" files for each version are .EXE files encoded in a printable ASCII format, suitable for BITNET, e-mail, and other nontransparent modes of transmission. You can decode the boo-files back into .EXE files using any of the MSBPCT.* programs available in kermit/a/msbpct.* or MSBPCT * from KERMSRV. See msbaaa.hlp for details. For a detailed description of the MS-DOS Kermit file naming conventions, see the file msaaaa.hlp (MSAAAA HLP). The MS-DOS Kermit implementations for non-IBM compatibles (except the generic DOS version) have not yet been upgraded to 3.11 level -- volunteers? Once again, thanks to Joe for his skill, generosity, patience, dedication, perserverence, and endurance (we're running out of adjectives for Joe!) in putting this new MS-DOS Kermit version together and sharing it with us. And thanks to the beta testers who sent in such prompt and detailed reports of problems so Joe could fix most of them so quickly! ------------------------------ Date: Mon, 16 Sep 1991 13:00:00 EDT From: Frank da Cruz Subject: New Second Edition of "Using MS-DOS Kermit" Keywords: MS-DOS Kermit 3.11, Using MS-DOS Kermit MS-DOS Kermit 3.11 is accompanied by a brand-new revised and expanded Second edition of Christine Gianone's book, "Using MS-DOS Kermit", Digital Press, Bedford, MA, USA (1991), order number EY-H893E-DP, Digital Press ISBN 1-55558-082-3, Prentice Hall ISBN 0-13-952276-X. The book includes a 5.25-inch 360KB MS-DOS Kermit 3.11 diskette. The US single-copy price is $34.95, up $5.00 from the first edition (not bad for 100 extra pages and 6 months work). To order, call (USA, toll free) 1-800-343-8321. It is also available from Kermit Distribution at Columbia University and in software stores and computer bookstores (where you'll recognize it easily by its new purple cover). A German language edition, "MS-DOS Kermit -- das universelle Kommunikationsprogramm, Einfuehrung und Referenz", is published by Verlag Heinz Heise GmbH & Co KG, Hannover, Germany, ISBN 3-88229-006-4, translated by Gisbert W. Selke (proprietor of the Old Curiosity Shop from Info-Kermit V14 #4), 5.25-inch 360KB diskette included, with many of the text files translated into German, price 69 DM. The new edition describes all the new features of version 3.11, including everything that was added in versions 3.01, 3.02, and 3.10. It has a new chapter on local area networks (including TCP/IP); a new appendix with a complete technical description of Kermit's terminal emulator with tables of all the escape sequences recognized and sent by Kermit in both text and graphics mode; expanded descriptions of many of Kermit's features, including printer control and the script programming language, including the new dialing directory features; an improved index. There are also new instructions for running Kermit under Windows and DesqView, for using LK250 keyboards, and there are many new tables, including one for Cyrillic character sets. The new book remains an excellent introduction (Einfuehrung) for the novice, and it is now an even more complete reference (Referenz) for the expert. The first edition of "Using MS-DOS Kermit" was received with unanimous approval by the critics. Some samples from the book reviews: "...one of the finest user guides, commercial, shareware, or otherwise, that this reviewer has had the pleasure of reading." - Tom Nichol, Link-Up, July/August 1990 (p.8) "An excellent introduction to computer communications, [Using MS-DOS Kermit] explains in simple but intelligent language how to set up and get going." "Must-read for PC buffs..." - Anne M. Russell, Working Woman, September 1990 (p.94) "While the book is aimed at nontechnical readers, I highly recommend it to all technical personnel in the computing field, particularly those who abhore software manuals." - William Oblitey, ACM Computing Reviews, V32 #6, June 1991, pp.283-284 Both the English and German versions of the Second Edition should be available in late September or early October. Every copy sold helps support the Kermit development and distribution effort, so don't be shy! ------------------------------ Date: Mon, 9 Sep 1991 20:38 MDT From: Joe Doupnik Subject: Kermit, TCP/IP, Packet Drivers, and the Future Release 3.11 of MS-DOS Kermit for IBM-PCs and compatibles opens a new communications channel for Kermit: many hundreds of thousands of machines around the world attached to the cooperative Internet network. The lingua franca of that channel is the TCP/IP protocol suite, including the Telnet interactive protocol. This is networking with a capital "N". We have received many requests for Kermit to "talk over the Ethernet" to other machines. The impression held by those unfamiliar with the mysterious art of communications is that one simply puts individual bytes on the Ethernet much as we do with ordinary RS232-C wires. Alas, the opposite is true so it might be worthwhile reading the few paragraphs on this technical matter. Even if you know the Packet Driver story from my Novell activities skim it for a repeat performance now underway with PD + NDIS + ODI. After that I'll mention some items about how Kermit handles Telnet. Ethernet, Token Ring, and similar network transport systems are party lines carrying traffic for many machines and using many different protocols. To keep the traffic flowing to the right places without ambiguity, the data -- our information -- is wrapped in administrative red tape with From: and To: addresses and much more. These ensembles are called packets or frames, and their rules of construction and manipulation are aptly named protocols, not unlike the Kermit protocol itself. IP is one protocol, TCP is a higher-level protocol that uses IP as a shipping agent. Novell has the SPX and (shipping agent) IPX protocols, and so on. Fortunately each of these can share the communications wire, time-sharing the party line, with the others because they obey the same rules for primitive addressing in the outermost wrapping of the packet or frame. That's about all they have in common: they drive on the same side of the road and they recognize traffic lights. The Internet is a massive voluntary interconnection of machines around the world. So not only do we have local addressing to do, but we have to be able to send and receive packets through gateways to distant lands. Interestingly, with TCP/IP we, as people, typically use the names of the machines, but on the wire only a numerical identification is employed. So behind the scenes name server machines have to quietly tell our program the number of the host whenever we use the name. We say NETLAB.USU.EDU but on the wire this machine is known as 129.123.1.11, a 32-bit quantity. As you might imagine, each protocol has its own distinct rules about names and numbers, as if the other protocols did not exist. More alchemy. What we see so far is that sending data bytes over Ethernet involves a lot of busy work preparing packets in just the right format, with the address of both sender and receiver and other vital administrative detail. The wire can carry a large variety of these packets. This means each machine hears all the packets, the network adapter board filters out all but those addressed to the itself (and the broadcasts), and the machine must have code to pick out the packets it wants and to wrap/unwrap (encode/decode) the interior shipping instructions particular to the protocol it understands. Serial RS232-C links avoid all of this because there is only one machine at each end. This brings us to a very local problem to be solved. Our PC might wish to use several protocols simultaneously. For example, a NetWare (or StarGROUP or PATHWORKS) file server is used to provide file service and we also want to use TCP/IP Telnet to log onto a remote machine in Logan, Utah (Logan is always "remote", no matter how close to it one may be). That means both IPX and IP need to share the Ethernet (or Token Ring, etc) communications board, or we will need a board per protocol. Thus the problem is: what hardware or software will we need to use two or more protocols simultaneously? Until a couple of years ago the solution to the problem was to purchase a network adapter board for each protocol in each client machine. Software of one protocol attached to a board and knew how to converse with it (that's a ticklish job known as being a device driver). Pretty soon there were lots of different boards, and one needed to buy software tailored for each one. In many cases, with only one board we had to reconfigure and reboot one's PC in order to switch among different networking applications. FTP Software Inc. of Wakefield, MA, USA, a vendor of PC-based TCP/IP programs, soon went bananas trying to write drivers for each new Ethernet board on the market. They wisely decided that what was needed was a small piece of code, called a Packet Driver, which did all the board-specific functions yet provided a standardized interface (a virtual board) to the application software. They wrote the Packet Driver (PD) Specification, made it public, and suggested that board makers write their own Packet Drivers so that FTP Inc and other software houses could get on with their primary task of creating useful communications programs (see John Romkey's recent article in BYTE magazine). More came of this than they may have realized. Two aspects make Packet Drivers very popular. One is that the programs are tiny, only about 2.5KB, and "relatively easy" to write. Thus software vendors can provide a PD interface as yet one more choice of board and save many tens of thousands of dollars of development effort per product per year, per vendor. That was FTP's intention too: save internal resouces. We benefit by lower software production costs. The second benefit is greater from the perspective of users (vs vendors). That is, the PD specification permits several protocols to call upon it, the owner of a single board, and each receives only the packets it wants. The requesting program thinks it owns a whole board. So a user can run several non-competing protocol stacks (networking software systems) at the same time, each asking for different kinds of packets, yet using only one physical network adapter. For example, Kermit can send a file from a Novell file server to a TCP/IP host, using a single Ethernet board. Now we are getting somewhere! The demand for Packet Drivers became large quickly. Individuals around the world started writing them because board vendors were too slow. Russel Nelson, then at Clarkson University, established a clearing house for user-written Packet Drivers and made them available at no charge. Oh boy, free and available now, available even across the network via anonymous FTP. A personal observation is that the general public, or at least a broadly based non-commercial group, is needed to make a standard take root and prosper; individual companies have their own territory and traditions to contend with. In the interests of completeness I need to mention two roughly similar systems that arose after Packet Drivers. The first is NDIS, Network Driver Interface Specification, by 3Com and Microsoft. NDIS performs the same functions as a Packet Driver, and a few more. NDIS programs are entirely commercial endeavors at present and all are much much larger than Packet Drivers. The most recent addition to the business is Novell's Open Datalink Interface, ODI, also commercial presently and sized between PDs and NDIS. ODI includes more features that the other two. NDIS is used by Lan Manager systems (DEC PATHWORKS, AT&T StarGROUP, 3Com 3+Open, and others); ODI is used only by Novell NetWare at this time. It appears that all three will live side by side for some time to come. But what about this side by side stuff; didn't we just solve that for the network adapter case? Now a new question arises: Can I run TCP/IP with a Packet Driver interface for the program (say Kermit) together with AT&T StarGROUP together with NetWare? Golly, will demands ever end? The answer is: it can be done, easily! FTP Software, again, wrote a small program called DIS_PKT, and I expanded on their effort with a program of the same name. DIS_PKT sits on top of NDIS and provides a Packet Driver interface for programs that want to communicate this way, and it allows NDIS-style programs to use NDIS simultaneously. Dan Lanciani of Harvard has a preliminary program called ODIPKT that lets Novell's ODI material sit on top of a Packet Driver, and Don Provan of Novell has another named PDEther. These little programs are given the trade name of "shims", and for many of us they are worth their weight in gold (saved from buying more LAN adapters, which if you recall, is where we came in). Well, that was an educational diversion. Back to TCP/IP in MS-DOS Kermit. TCP/IP is a mature protocol with many many features. Telnet is a protocol sitting on top of TCP/IP which provides an error-checked terminal-like communications pathway to a host. The software to implement Telnet, and TCP, and IP is complicated and normally fairly large. Erick Engelke at the University of Waterloo, Ontario, Canada, wrote a TCP/IP kernel which was small enough to be considered for inclusion within Kermit itself, rather than relying on programs such as NET14 and TNGLASS coupling to exterior TCP/IP programs. Much work later we accomplished the goal of embedding Telnet plus TCP plus IP plus a good Packet Driver interface within Kermit, for an overall cost of roughly 30KB increase of program size. That's a bargain, folks. Kermit includes procedures to talk with name servers to do that translation of host names to numbers. It has procedures for Kermit to learn its own Internet address from servers of such things, via the BOOTP and RARP protocols. BOOTP can also supply name server addresses, a gateway address, and so on. Name resolution, etc, is all automatic from the user's perspective, and based on the nuts and bolts discussion above it had better be automatic! The performance of built-in Telnet is much greater than the alternative of coupling to an exterior TCP/IP program via BIOS Interrupt 14H, and of course it is far faster than a serial RS232-C connection. All connections require a communications program pay attention to the wire very frequently. LAN connections on Ethernet or Token Ring require even closer than normal attention because packets arrive at incredible rates and will jam up in the LAN adapter unless the communications program lends a hand. So Kermit has a small invisible background procedure to run the Telnet code while Kermit itself sits at the command prompt or is sleeping while you are shelled to DOS. This reduces the clutter of fresh packets when Kermit is not actively seeking them directly and it keeps the host happy. By the way, for the benefit of network managers, Kermit does not send only one data byte in an individual IP network packet. It gathers as many bytes as will fit before a timer expires and exports few network packets. A network monitor shows Kermit file transfer activity to look much like FTP file transfers. I tried to make Kermit be nice to networks, and to their managers. Another issue concerns running Kermit's Telnet path while in Windows 3. The technical problem is the Packet Driver calls on Kermit when each new packet arrives, but Windows may move Kermit about in memory and thus the call goes to the wrong spot (Uh-Oh time). There is a simple solution. Using the PIF editor for a KERMIT.PIF file find the box labeled "Lock Application Memory" in the Advanced Options section. Check it. That says don't move Kermit in memory. The nice consequence is Kermit is able to run in a window of Enhanced Mode, and it will continue to run even when reduced to an icon. Having Kermit use Telnet for local or long distance communication across existing networks raises some interesting points. The usual file transfer program for TCP/IP work is FTP, File Transfer Protocol. Those who use it will tell you it is quick but not exactly smart nor user-friendly. The Kermit file transfer protocol is slower because it is designed for the worst case situation of going from point A to B by many methods. So FTP is faster than Kermit-to-Kermit file transfers on a fast link. But: Kermit can use many kinds of links whereas FTP can't, Kermit can transfer the file time-and-date stamp, it can skip individual files or stop the entire group of files when you wish during a big transfer, it can do character-set to character-set transfers for international language documents, it can rename files to avoid destroying originals, and so on. The process of moving information, not just raw bytes, is more advanced in Kermit than in FTP. In addition, Kermit is driven by user feedback and we respond quickly. FTP is not about to change much in the near future; what you have now is what you will have several years from now. Kermit's advanced features are negotiated between any two Kermits so they always work even if one program is five years older than the other, and runs on a vastly different machine than the local PC. It has been stated many times that there is a Kermit implementation for almost every kind of computer in this world; the size of the Columbia University Kermit archive supports it. These programs are written by individuals, volunteers, on a not-for-profit basis (costs usually are born by them too). New features appear at the rate which we, the volunteers, can create them; the Kermit Project at Columbia exercises overall control so matters remain coherent across Kermit software programs. The popularity of Kermits, their responsiveness to the "marketplace" (i.e., the users), and their ability to work together between almost any pair of machines makes Kermit an good vehicle for advancing the state of the art of information exchange across communications channels. Kermit is not wedded to one communications method or protocol; it uses serial ports and MS-DOS Kermit uses most of the commercially available networking channels. However, adding new features costs: in time, money, and energy of talented and experienced writers. Each major addition, say adding 3270 emulation or advanced Tektronix graphics support to MS-DOS Kermit, becomes a significant project lasting months to years. We are accomplishing with few people (who by the way have regular full time jobs and careers other than Kermit) what commercial software houses do with larger full-time paid staffs. Thus major advances need the support of the entire community, particularly from commercial and government enterprises that benefit so heavily by not having to pay hundreds of dollars per program per copy per year for connectivity. Some companies have been very helpful by providing boards, software, or complete operating environments. Those contributions are much appreciated and needed. A firmer long-term basis is required so we can plan and implement the strategically meaningful advances. Kermit software has saved the corporate, government, and academic sectors countless millions of dollars in its first ten years of existence. As the sophistication and demands of computer users grow, so too does the complexity of the programming task. If Kermit is to continue fill your needs and save you money over the next ten years, let's hope some of the well-endowed corporations and agencies that have done so well by our efforts will think about supporting them in the future. Additional features that many of you are requesting -- more ASCII terminal emulations, multiple host sessions, 3270 emulation, ReGIS graphics, Tektronix 41xx and 42xx graphics, full integration with Windows 3.0, a fancy menu-driven user interface with internationalized locales, etc -- each of these is a massive project requiring additional dedicated programming staff if these features are to be available in a timely fashion. I ask for your understanding when I say that these can't be provided in one or two releases. The existance of strong requests is our reward that we are doing a good job as you see it. ------------------------------ Date: Mon, 09 Sep 1991 18:18:46 EDT From: Erick Engelke Subject: Adding TCP/IP Features to MS-DOS Kermit Connectivity has come to mean much more than the RS-232 wires and modems that webbed our offices in recent years. Today's networks are connected using a plethora of incompatible networking hardware, systems software and hardware platforms. But under the TCP/IP family of Internet protocols, all these barriers melt away. The newest version of MS-DOS Kermit is capable of dealing with these intelligent, high-performance networks just as easily as it has worked over other communication media for years. The Waterloo TCP (WATTCP) code was developed at the University of Waterloo to simplify creation or adaptation of TCP/IP-based utilities. It uses a simple and well defined application programmer's interface (API) based on a loose adaptation of BSD networking functions. The TCP portions actually execute off the application program's stack. This unusual practice simplifies development and testing by allowing the application and the network functions to all coexist in the same task. One of the first applications written to demonstrate the capabilities of WATTCP was a little program called TCPPORT which let Kermit or most other communications programs be used as a TELNET client. Although it seemed to be merely an academic achievement and totalled less than 100 lines of 'C' code, I started getting a growing quantity of mail from the masses who needed the capabilities of MS-DOS Kermit in a TELNET package. The most common reasons cited were Kermit's international character support, its unmatched emulation capabilities, and Kermit file transfers to machines not supporting FTP. Within days I received a brief message from Frank da Cruz (C-Kermit author) who had found the program and tried it with relative success. To anyone foolish enough to actually implement a TELNET client, there are hundreds of documents (RFCs) which are required reading and nearly one hundred of them are pertinent specifically to TELNET. After much reading you must start the eternal process of testing your version with everyone else's implementation. One of the known problems TCPPORT had was the ability to crash some VMS systems running poor but common TCP/IP implementations. Frank's experience from C-Kermit quickly resolved these and other problems. By this time, Joe (author of MS-DOS Kermit) and Christine Gianone (Important Kermit Person) had entered into our mail conversations and we started discussing how we might incorporate the functionality of TCPPORT right into MS-DOS Kermit. MS-DOS Kermit had always packed an enormous number of features into a pretty small package, but we felt we could add TELNET capabilities without increasing the executable by more than thirty kilobytes. This was a small cost for the enormous benefits. It also a hard promise to keep - we had overlooked some hidden data areas. As soon as he had time, Joe dove right into the project and scrutized every line of my code. Since I had only started the WATTCP project about seven months earlier, there were a number of areas which had not been fully tested or which were incomplete. During the Kermit-ization process, I mostly gave advice and concentrated on the TCP core section while Joe did an amazing amount of work in adapting and occasionally rewriting my efforts to fit his needs. He also acted coordinator, so we did not have to remember what everyone else was doing. Some of the features of my original code were of little use to MS-DOS Kermit, so it became sort of a WATTCP-Lite, actually consuming less than twenty-five kilobytes of the final Kermit executable. Despite the occasional simplification, we kept the API identical to the documented WATTCP API, allowing us to keep our efforts coordinated for future revisions. The process of perfecting the TELNET features was greatly simplified by the Internet itself. Whenver we were told of problems TELNETting to a particular computer, we could KERMIT/TELNET there ourselves and solve the problems without additional help. In fact, we used Kermit to transfer updates to each other. This also allowed us to tune the long-distance capabilities which are essential to a TELNET program. The final product has the benefit of Frank, Christine, obviously Joe, and the many volunteers whose efforts were too numerous to list. This distributed group of people has once again brought MS-DOS Kermit to the leading edge by adding to its description: an excellent TELNET program. Erick Engelke WATTCP Architect Faculty of Engineering University of Waterloo Waterloo, Canada ------------------------------ End of Info-Kermit Digest *************************