![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to ckuker.bwr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / contrib / kermit|
Return to ckuker.bwr CVS log | Up to [CSRG BSD Unix] / 43BSD / contrib / kermit |
1.1 ! root 1: C-Kermit Version 4C(057): ! 2: Status, Bugs, and Problems ! 3: As of: 2 Aug 85 ! 4: ! 5: Note: Version numbering system changed from decimal notation (like 4.2) ! 6: to number-letter notation (like 4C) to avoid confusion with Berkeley Unix ! 7: version numbers. ! 8: ! 9: See ckuker.upd for list of bugs already fixed. ! 10: ! 11: -- SUPPORT FOR DIFFERENT SYSTEMS: -- ! 12: ! 13: 4.2BSD: "make bsd" works. Should work on VAX, SUN, Pyramid, & others. ! 14: ! 15: 4.1BSD: "make bsd" should work for this too (did not in C-Kermit v4.2). ! 16: ! 17: 4.3BSD: unknown, but "make bsd" should(!) work. ! 18: ! 19: 2.9BSD: Support in but untested: "make bsd29". Should be the same for 2.8. ! 20: ! 21: Version 7: works ok on the systems tested so far using "make v7", but some ! 22: fiddling with the make file is necessary for proc table definitions; see ! 23: the makefile and also ckuv7.hlp for details. ! 24: ! 25: PC/IX: should work ok with "make pcix". ! 26: ! 27: ATT 3Bx systems: should work ok with "make att3bx". ! 28: ! 29: Most other System V or System III based systems can build a working Kermit with ! 30: "make sys3" ! 31: ! 32: PDP-11's running a System III or V based Unix and which have no I & D space ! 33: should use "make sys3nid". ! 34: ! 35: DEC Pro-350 or -380 with Pro/Venix V2 (not V1) -- uses the regular "make sys3" ! 36: or "make sys3nid", but the file ckcfio.c might have to be edited first to ! 37: reduce the value of MAXWLD and/or SSPACE. See below under HINTS for details. ! 38: ! 39: For other Unix systems, see the makefile. ! 40: ! 41: VAX/VMS: support added by Stew Rubenstein at Harvard and Martin Minow at DEC. ! 42: Has to be built with CKV*.COM, needs development to handle all the VMS/RMS ! 43: features and to improve performance. Has its own build procedure. See ! 44: CKV*.*. VMS-specific bugs in CKVKER.BWR. ! 45: ! 46: Macintosh: Support added at Columbia, has own makefile, etc. See CKM*.*. ! 47: ! 48: ! 49: -- HINTS -- ! 50: ! 51: - If the program dies with a message like "malloc fails in splitpath()" ! 52: whenever it tries to parse a filename (as in the "send" command), then ! 53: the amount of space allocated for filename expansion in the module ! 54: ckufio.c must be reduced. This can be done by changing the #defines ! 55: for MAXWLD (the maximum number of filenames) and SSPACE (the size of ! 56: static string space) to make the numbers smaller. ! 57: ! 58: - When modifying or writing KERMIT code, do NOT pass to a function ! 59: (e.g., "signal") the address of a static function. Doing so may ! 60: break VENIX code mapping. If you must pass the address of the ! 61: function, make it global and pick a "non-generic" name for it that ! 62: will hopefully be unique and yet informative. ! 63: ! 64: ! 65: -- BUG LIST -- ! 66: ! 67: First, a disclaimer must be made. C-Kermit attempts to support all post-V6 ! 68: Unix variations on all machines. This is a tall order, and requires careful ! 69: attention to certain details. As changes are made (and C-Kermit is still in ! 70: stage of fairly rapid development), there is always the chance that a change ! 71: -- made to introduce a new feature or fix a bug -- will not work as intended ! 72: on some systems, even though it was tested successfully on others. The main ! 73: area to watch out for is not system differences (which are handled fairly well ! 74: in the system-dependent ck?[ft]io modules), but in compiler differences, ! 75: especially int/char confusion. Characters should be stored in variables of ! 76: type char, not int, and char/int conversion should be avoided because of ! 77: problems introduced by sign extension. And i/o should not be used to read ! 78: characters into int variables, because the way in which the system stores the ! 79: character in an int varies from system to system (e.g. 68000s put them on the ! 80: left, the VAX on the right). ! 81: ! 82: If you have received a C-Kermit release that does not work correctly (except ! 83: for the bugs & restrictions noted below), it is not because the release was ! 84: not thoroughly test -- it was -- but because it was not tested on your system ! 85: since the last time changes were made, because of a lack of such a system to ! 86: test it on. If this happens to you, please try to track down the problem and ! 87: report as specifically as possible back to us. ! 88: ! 89: ! 90: General problems: ! 91: ! 92: - The program is too big, with too many features; source is too large to fit on ! 93: some disks. Needs to be reorganized so that a minimal Kermit can be built ! 94: for any system, and then frills can be added on if desired -- interactive ! 95: command parser, help strings, dial command, script command, etc. ! 96: ! 97: - There's not a full enough set of features available from command line ! 98: invocation. Commands like "bye" are missing. This is mainly to keep the ! 99: "kermit -h" help message small enough to fit on one screen. ! 100: ! 101: - Conditionalizations are not done clearly. In some cases it might be ! 102: better to have compile-time flags for features, rather than systems, or ! 103: generic system names, rather than specific vendor/machine names, to ! 104: avoid excessive nesting or repitition of compile-time variables. ! 105: Constructions like "#ifdef FOO | BAR" are avoided because many compilers ! 106: don't understand them; the alternative is to repeat code under different ! 107: conditionals (to accomplish an OR) or to include it within nested ! 108: conditionals (AND), sometimes applying De Morgan's law to achieve the ! 109: desired result... ! 110: ! 111: - Program's return code might be wrong in some cases (in 4.0, it was always ! 112: zero; in 4C some attempt is made to return correct codes for failure and ! 113: success). ! 114: ! 115: - On some systems (e.g. TRS-80 Model 16 with Xenix V7, or HP-9000 HP-UX) ! 116: C-Kermit reportedly runs VERY SLOWLY. The program could certainly do with ! 117: some tuning -- but not at the expense of modularity and transportability! -- ! 118: but in the meantime, it can probably be sped up a lot by removing the ! 119: -DDEBUG from the makefile, eliminating hundreds of function calls, many of ! 120: them in critical code. Another speedup could come from allowing more ! 121: systems to take advantage of "myread()" -- the nonblocking version of ! 122: read(); see below. ! 123: ! 124: - Micros like the DEC Pro-350, when in "IBM mode" (set flow none, set ! 125: handshake xon), might not be able to keep up with incoming packets, even ! 126: at relatively low baud rates. The Pro-350 OS relies heavily on ! 127: XON/XOFF to avoid losing characters at the port, but XON/XOFF must be ! 128: disabled for communicating with IBM mainframes. The only solution is ! 129: to lower the packet size to 20 or 30 to reduce the probability that ! 130: data is lost in any particular packet, and maybe also reduce the baud rate. ! 131: ! 132: - Need 'set' command for retry-threshhold. ! 133: ! 134: - The program could be a little bit less cavalier in its treatment of files. ! 135: For instance, when receiving a file (with "warning" turned off) it will ! 136: overwrite any existing file of the same name. That's ok, but what if the ! 137: user types ^F or ^B to interrupt the transfer? This does not save the ! 138: existing file -- it's already been destroyed by the open() of the new copy, ! 139: which in turn is discarded as a result of the interruption. Maybe Kermit ! 140: should always make a temporary, unique name for incoming files, and then ! 141: rename them to their real names only after the transfer is complete. But ! 142: that's no good on systems (like the Macintosh) that don't have disk space ! 143: to burn. ! 144: ! 145: - Local versus remote mode is not, and probably can not, be determined ! 146: automatically upon startup. For instance, if you build Kermit with ! 147: "make sys3" on a 3B20 and a 3B2, the program has no way of knowing whether ! 148: it's running on a timesharing system (the 3B20, where it should be remote ! 149: by default) or a workstation (the 3B2, where it should be local by default). ! 150: If you find that Kermit comes up on your system in the wrong mode, you can ! 151: put the appropriate "set line" command in your .kermrc file -- "set line ! 152: /dev/tty" will always put you in remote mode. ! 153: ! 154: - Local mode file transfer display could be improved. On tty-style displays, ! 155: the "percent done" could be shown by doing something like ! 156: "0...1...2...3...4...5...6...7...8...9...". ! 157: ! 158: - If the program crashes or is halted (killed) from outside while it has the ! 159: terminal in a not-normal mode during command parsing or file transfer, the ! 160: terminal mode is not restored, and lock files are not cleaned up. There can ! 161: be no fix for this within C-Kermit itself. ! 162: ! 163: - The shell's interrupt, delete, and kill characters may interfere or ! 164: conflict with those used by the Kermit command parser. In any case, there ! 165: is no way to change Kermit's editing characters to conform to user's taste. ! 166: ! 167: - Status info should be updated only for real file transfers, not transactions ! 168: like "finish". ! 169: ! 170: - "!" command requires a space after, contrary to the Unix user's normal ! 171: expectation. ! 172: ! 173: - Many people have asked for a system-wide startup file similar to ! 174: the user's .kermrc file, perhaps with a conditional way to escape from ! 175: it if the user has her own .kermrc file. This notion might be extended ! 176: to include the entire hierarchy system -- home -- current directory. ! 177: ! 178: - A deeper problem with the initialization files is that the file is only ! 179: taken when the program enters interactive command dialog. To be consistent, ! 180: it should also be taken when the program is run via command line arguments. ! 181: ! 182: - Some users report that it would be more desirable to have an error during ! 183: execution of a take file return directly to command level, rather than ! 184: pop to the invoking take file (why?). ! 185: ! 186: - Some users report that the program should make no internal distinction ! 187: between running in foreground or background (why?). ! 188: ! 189: - Since kermit opens and closes the communication line with each command line ! 190: invocation, it is not convenient to use it in scripts in which it is ! 191: repeatedly invoked (e.g. a print spooler). ! 192: ! 193: - Variable names are sometimes confusing, especially the send/receive parameter ! 194: pairs (spsiz/rpsize, mystch/stchr, npad/mypadn, rtimo/timint, etc). This ! 195: is mostly history... they tend to agree with the names used in other Kermit ! 196: programs. Still, they should probably be changed. Ditto for some of the ! 197: procedure names. ! 198: ! 199: - Some C compilers do not support variable names longer than 6, nor function ! 200: names longer than 5, and some are not case sensitive (the DEC-20 C compiler ! 201: has all these restrictions, and the V6 Unix C compiler has some of them). ! 202: To ensure the widest possible portability, all identifiers should comply ! 203: with these restrictions -- currently many do not. ! 204: ! 205: - When the C-Kermit server is given a host command (or even some generic ! 206: commands like 'space'), it might have to think for a long time before ! 207: returning output. In this case, it should set a timer while waiting for ! 208: input from the fork and whenever the timer goes off, it should send a null ! 209: data packet to prevent the other Kermit from timing out. ! 210: ! 211: - When connecting back to C-Kermit after a transaction, or after finishing ! 212: the server, it may be necessary to type a ^Q to clear up an XOFF deadlock. ! 213: There's not much the Kermit program can do about this... ! 214: ! 215: - When interrupting a send with ^F or ^B, an appropriate message does not ! 216: seem to make it into the transaction log. ! 217: ! 218: ckufio.c: ! 219: ! 220: - ckufio currently goes to a lot of trouble to traverse the directory in ! 221: order to expand "*" and "?" in wildcards. Maybe it should just fork the ! 222: user's customary shell and have it do the expansion. This would allow ! 223: fancier filespecs to be given, like "~/ck*.[cwh]". But it would slow down ! 224: features like filename completion and menus in the interactive command ! 225: parser. (Find out how Unix FTP does it...) ! 226: ! 227: ckutio.c: ! 228: ! 229: - Myread() should be expanded to include systems that can't do nonblocking ! 230: reads, but can find out how many characters are in the input buffer -- this ! 231: would eliminate calling read() in a loop for each character during packet ! 232: transmission (e.g. Pro/Venix V1 could use "ioctl(x,TIOCQCNT,&y)", V7 could ! 233: use its buffer-queue-peeking trick, etc). ! 234: ! 235: - There should be a timed option for ttoc() for use during connect so you ! 236: can escape from XOFF'd or other stuck conditions. ! 237: ! 238: - There's no good way to select baud rates higher than 9600. Most Unix systems ! 239: don't supply symbols for them (unless you use EXTA, EXTB), and even when they ! 240: do, the program has no way of knowing whether a specific port serial ! 241: controller supports those rates. ! 242: ! 243: - Use of RAW|TANDEM in 4.1 BSD gives only unidirectional, not bidirectional, ! 244: flow control -- xoff's from the terminal are treated as data rather than ! 245: control signals. Symptom: possible loss of characters during CONNECT. ! 246: ! 247: - On some systems, there is an undesired interaction between the various ! 248: open() modes, fnctl(), and ioctl() invocations when modem-control lines ! 249: are involved. Some of this due to bugs in some Unix implementations or to ! 250: inconsistencies between them (e.g. as to the behavior of TIOCEXCL, etc). ! 251: ! 252: ckudia.c: ! 253: ! 254: - Some systems do not allow users to manipulate dialers directly. ! 255: - Should support a "phone book" (this would actually go in ckuus*.c). ! 256: - Pro/Venix V2 (and some other Sys V-based systems) are having DTR-dropping ! 257: problems when dialing. With Pro/Venix V2, a workaround is to get the system ! 258: to ignore the modem control signals and treat the line as a direct line by ! 259: issuing a "setline -d xxx" command, where "xxx" is the device node (e.g. ! 260: com1), rather than "setline -m xxx". ! 261: - Hayes modem dial string should be ATD, not ATDT, so that dialing will occur ! 262: in the mode that the modem is set up for (does everyone agree?). ! 263: ! 264: ckuus*.c: ! 265: ! 266: - The send command should have the same syntax as the get command to allow ! 267: multiple filenames to be given on a single line: ! 268: ! 269: send foo bar baz <-- send all these files ! 270: or: ! 271: send ! 272: Local file(s) to send: foo bar baz ! 273: Name(s) to send it/them under: x y z ! 274: ! 275: The latter form could be risky, of course, when mixed with wildcards, ! 276: and in any case would require major rewriting of many parts of the program ! 277: (which probably will never be done). ! 278: ! 279: - Baud rate selection currently requires user to type a number, which is ! 280: then verified against a system-dependent table. Better to have a baud rate ! 281: keyword (cmkey) table defined in the system-dependent module, so user ! 282: can abbreviate (e.g. '9' for '9600'). ! 283: ! 284: - No way to put trailing comments on commands. ! 285: ! 286: - ckuus2.c makes the C optimizer run out of space under PC/IX and some other ! 287: systems. ! 288: ! 289: Protocol (ckcpro.w, ckcfn*.c): ! 290: ! 291: - No way to interrupt a protocol transaction until after it starts ! 292: successfully. For instance, no way to interrupt the timeouts and ! 293: retransmissions of the initial packet when the other side is not ! 294: responding, except for killing the whole program. Cure: check for ! 295: keyboard "interrupts" during the send-init process, set c[xz]seen. ! 296: But doing this will make the state table a lot more complicated... ! 297: Maybe change ^C trap to get back to command mode rather than exit ! 298: the program. ! 299: ! 300: - When parity is in use and the other Kermit cannot do 8th bit prefixing, ! 301: the user is not warned that binary files will not be transferred correctly. ! 302: This can be easily remedied by calling screen(SCR_WM,...) after the ! 303: send-init exchange has occurred, but this would make a dialog box pop ! 304: up during protocol on the Macintosh... ! 305: ! 306: ckucon.c: ! 307: ! 308: - Doesn't do any particular kind of terminal emulation. It wasn't meant to. ! 309: Filters can be used for this. Or a replacement module can be written ! 310: (as has been done for the Macintosh). ! 311: ! 312: - When sending BREAK, should clear output buffer first (this is done in BSD, ! 313: should be added for other systems to ttsndb() in ckutio.c). ! 314: ! 315: - Performance is poor on systems that can't check the input buffer or ! 316: do nonblocking read() calls. See the horrendous code that was added for V7 ! 317: to get around this (peeking into tty buffers in kernel memory). ! 318: ! 319: - As structured, connect mode can't include commands to toggle logging on ! 320: and off or to change settings, because the fork that reads keyboard input ! 321: doesn't share variables with the fork that does port i/o. ! 322: ! 323: - The program may become stuck if the two sides get into an XOFF deadlock. ! 324: There should probably be a timer around (or in) the ttoc() call. ! 325: ! 326: - Reportedly, a control-S typed at the keyboard doesn't always seem to "take" ! 327: when doing terminal emulation under Pro/Venix V2 (DEC micros, terminals, ! 328: devices, systems are notorious for their insistence on doing XON/XOFF and ! 329: attendant problems. Remember the VT180?)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.