2 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 LCD 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 todays GUIs coupled with removal of the 8.3 restrictions it is common for the filename 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 acheived. 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 accomodate 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 its 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 Masters 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 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 / 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