The known problems-with/deficiencies-of Amiga Kermit are: 1) Wildcards are not allowed in filenames 2) No LOCAL commands are supported (DIRECTORY, CWD, etc.) 3) No DIAL or login scripts 4) The SERVER mode only does GET, SEND, BYE, FINISH and REMOTE HELP 5) No XON/XOFF flow control 6) REMOTE command messages go to the DOS window, not the KERMIT window (in fact, they don't show up until you exit from Kermit) 7) No terminal emulation (just a dumb terminal in CONNECT mode) 8) File transactions all report elapsed time of 0 seconds (although timeouts work properly) 9) Initial SEND delay is always 0 even when reported to be 5 seconds. 2-May-86 18:32:40-EDT,9040;000000000001 Received: from CUVMA by CU20B with HASP; 2 May 86 18:32:39 EDT Received: from UORDBV(DPVC) by CUVMA (Mailer X1.23a) id 6057; Fri, 02 May 86 11:54:31 EDT Date: Fri, 2 May 86 10:59 EST From: Subject: Alternate Amiga Kermit To: sy.fdc@cu20b.columbia.edu X-Original-To: frank, DPVC Frank: I received a copy of Phil Julian's C-Kermit for the Amiga, yesterday, and have begun to test it. There are a number of distinct advantages to their version: 1) It is a full-function kermit; that is, it implements all the commands, including CWD, DIRECTORY, and other shell commands, as well as the full set of SERVER commands (I have not tested the SERVER yet). 2) It supports wildcarded file names using the standard '*' and '?' wildcards, but only allows one such character per directory sub-level (not confirmed). 3) It does multi-character, buffered IO both to the screen and to the serial port (my version uses only single-character IO, until I got the manuals, I could only make assumptions about how the serial driver worked. My version performs reasonably well, even at rates of 9600 baud. I allow you to specify 19200, though the throughput is about the same as it is for 9600, so I suspect the single character IO won't take advantage of this speed, though no errors seem to occur). The screen painting is perceptibly faster, though at 1200 baud, it won't make much difference. I intend to include buffering in my next release. 4) It does not require the "printf" to "printf2" conversions that I had to do, because it replaces "stdin", "stdout", and "stderr" in the internal file data structure with the newly opened window. That was what I wanted to do, but I did not have the information about the structure. There are a number of problems, however: 1) There is no "emergency exit" gadget or key sequence that I can find. This is fine when file trasnfers are proceding normally, but I often have had to cancel transfers when they are not initiating properly, (on many machines, not just the Amiga) and would miss this feature in their version. 2) The initial window size fills only half of the screen, which makes it too small to hold some of the HELP messages and the SHOW display. This is fixed easily in one line of code. 3) The window does not update itself when you resize it, so that you can get half characters, and no cursor, if you aren't careful. This is not a big deal, since many programs for the Amiga do this, but I think it is sloppy. 4) It is compiled with v3.04 of Lattice C (which I don't have), and the author claims it WON'T compile with v3.03 (which I DO have). I did not test this. 5) It still uses the (057) code, which is easily fixed. 6) The function keys, arrow keys, and other special keys (including the keypad keys, I think) produce garbage characters (actually, well organized garbage, but meaningless both to the C-Kermit from-end, and to most other computers that I know of). My version maps these keys to empy strings (no characters roduced), and maps the HELP key to '?' so that it will give help on the C-Kermit command line. This also provides the ability to map the keyboard to any set of keys that you want, though I did not use the standard Amiga method for doing this. 7) The transfer time does not seem to be correct. I have not completely diagnosed this, but I did receive a count of 26 million seconds for a very short file transfer (which I aborted before it succeded). Perhaps he is reporting time in milli-seconds. 8) I have a concern about the method used to buffer the output, but have not been able to confirm my suspissions. I think that there is a case where the output buffer may be over-written before it is fully transmitted by the serial driver. THIS IS NOT CONFIRMED. 9) The changes in the UNIX modules are not documented, and are not in a form where the files can still be used by UNIX compilers. That is, some UNIX code is commented out, while some other code is completely removed (I have seen this only in one place). There are #IF 1 ... #ENDIF constructions that I think should be #IFDEF AMIGA ... @ENDIF, and some other ineligancies. 10) The author did not follow the Kermit file naming convention, and named some files "consoleio.c", "serialio.c", etc. This is not hard to correct, but does show a lack of concern, at least, for the distribution process. 11) There is no BLD file on the disk that I got, although a MakeFile exists. Unfortunately, MAKE is not a part of the Amiga environment. A number of MAKE programs exist for the Amiga, but I would not assume everyone has one, and in particular, the same one that Phil Julian is using. There is nothing identifying which version he is using, nor how to get a copy, nor how to use it. There is a COMP-ALL (compile all file), and a link file, so people without MAKE can do it, but again, there is no documentation, and the COMP-ALL routine is neither freindly nor informative about where it may be having problems. These files also assume that your system disk is your Lattice C disk (mine is not), and that you have enough disk space for the object code and the source code on the same disk (which means it can't be the Lattice C disk). This makes it difficult to compile on a one-disk system (like mine) without modifying the command procedures. In summary, I think that the product is solid as far as a stand-alone program is concerned, and is superior to my version in perfromance and functionality, with only minor problems (the missing "emergency exit" being the only major drawback). I do not think, however, that it is in shape to be distributed as is. It is possible to correct these problems, but Phil Julian will have to do that himself, as I do not feel that it would be the best use of my time to do that myself. It also would be possible to incorporate a number of his features into my version, although I feel that it would be better for me to add these to my next version, which I already am developing (I am working on the menu interface now). In view of his code, I see that there are a number of things in my version that could be done in better ways, and I suspect that when the Amiga hackers get their hands on my code, they may change some of them. I hate to see inferior code go out (there was really no question that it would be inferior, as I new at the time I was writting it that I did not have complete information on the devices and drivers that I was attempting to use), but I don't think Phil's version is ready for distribution as it stands. You may wish to contact them about this. I would like to see a full-featured version distributed, but I do not feel that I can recommend theirs in its current state. You will have to decide what you want to do about distributing one or more versions. I would suggest you speak to them about their version and how they plan to support it if you use it (I noticed that the author has the copywrite notice in his name; my version has the Columbia University notice). Are they planning updates? How will questions be answered? I'm sure you know better than I what issues are at stake. If you do use my version, I suggest that you rename CKU*.[HC] to CKI*.[HC], as I am more and more displeased with the "printf2" solution, and I don't think we need to confuse the UNIX community with it, especially as it will not be a part of my new, menu-driven version (i.g., it is only a temporary patch). When you change the names, however, you will have to change the references to the files in CKIKER.BLD, CKILNK.COM and CKIKER.MAK. I can send updated copies of these, if you want (they are pretty small). Please let me know which version you will be distributing. I will be on vacation all next week, so you can have as much time to decide as you want. I will call in periodically to check my mail, but won't do any official work until the following monday. If you have any questions, feel free to mail them, or call me at (716) 275-2811 (work) or (716) 352-1135 (home, please don't give this one out). Davide P.S., I've heard from a number of Amiga users who are using my version and they all seem pretty happy with it, even without the other features. Since the Amiga is a multi-tasking machine, it's not so important to be able to do local shell commands from within Kermit.