Known problems with Mac Kermit version 0.8 ------------------------------------------ Last update to this file: 11 July 1985, applies to edit 33 ----- The biggest problem with Mac Kermit is installing it on your Mac if you don't have it on a diskette already. For tape distribution, the program is encoded in Binhex Version 4 (.HQX) format, and you need (a) a way of getting the .HQX file onto your Mac in the first place, and (b) a copy of Binhex Version 4 to convert it into a runnable application. It is assumed that most sites receiving Kermit tapes that are interested in running Macintosh Kermit will have some method of initially downloading the .HQX file, and will have a copy of Binhex. ----- Occasionally, files transferred to the Mac with apparent success will be empty. This happens very rarely and cannot be reproduced. It has only been reported twice, once on a Hyperdrive system, and once on a Mac with a Tecmar disk after the screen had been dumped to the printer. (this problem may be rectified in edit (33), which now terminates on failure to close, attempting to report an appropriate error.) ----- Reportedly, the program can be made to hang getting retries and no packet transmission if an earlier file transfer was terminated using Command-dot. ----- Character attributes (bold, inverse, etc) are not preserved when restoring the screen after it has been overlaid by another window. ----- When mapping the OPTION key to CTRL, certain characters (notably CTRL-v, where v is any lowercase vowel) have to by typed twice in order to send them. This is a feature of the Mac, sort of like Command-Shift-1...9, but unlike Command-Shift-1...9, MacKermit doesn't have a command to disable this feature. ----- In terminal emulation, bold characters seem to be different sizes from the regular screen characters, but Kermit apparently uses the same width information for both, resulting in a slightly fractured display. Often, parts of bold characters will be left on the right margin of the screen. ----- After a file transfer, successful or otherwise, the mouse cursor does not turn from a watch back into an arrow. ----- The terminal emulator uses a hardwired roman (english) font. This could present problems to non-english users whose systems use other alphabets. ----- Switching between Mac Kermit and MacTerminal may result in repeated errors if Macterminal closes the serial port. ----- Starting up MacKermit when there is output going to the port can result in an address error. ----- The remote response window accumulates everything that has been sent to it; you can always scroll back to the beginning. That's nice, but there's no way to make space when it fills up. And when it does fill up, it will probably crash the program. At the very least, cutting and pasting should be allowed. ----- VT102 emulation -- some terminal sequences cause garbage: [Mark Thompson] ...my 'status' line is a 'wholine' output in the bottom line of the screen. It sends: "\33\67\33[1;23r\33[24;1f\33[1;7m ", /* save, scroll, jump, rvid */ a line of status, then: "\33[m\33[0K\338", /* normal vid, erase eol, pop */ this is done once at the beginning, to set up the screen: "\33\67\33[1;23r\338\33[A\33[m\12", /* sigh. */ ----- The VT102 emulator still overflows after a few screens during scrolling at 9600 baud; some improvements that could be made: Use arithmetic instead of the routines fndrel, fndprev, and fndabs. Zeroline could be improved by using a blockmove, or munger. Tabs could be improved by using an array, indexed by current position which results in the count of spaces until the next stop. This would cost MAXCOL*(sizeof short) but that's not much. Since no matter what we do will probably be insufficient we should allow the user to set a parameter saying whether to use XON/XOFF. After all, the VT100 can't keep up either, it just XOFFs the host. As long as we can guarantee that we can handle one screen's worth we won't have any problems from EMACS and other non-scrolling full screen applications. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~THINGS TO DO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The handling of data and resource forks should be improved in various ways. For instance, the transmission of files containing both forks should be allowed. ----- Finish and test line insert/delete in the terminal emulator. ----- Make Kermit as small as possible by compressing anything you can get your hands on! It must always be able to run on a 128 K Mac. ----- Make the autowrap setting on the communications menu work. ----- Many system calls do not check the error codes. This could be a problem. Look especially in ckmfio.c and ckmtio.c. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~SUGGESTIONS~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Translate to a native Macintosh C compiler (which one is best?). Preferably do it in such a way that it can be easily ported to other compilers, and still built by SUMACC. This is desirable not only so that people without VAX Unix systems can work on the program, but also because SUMACC does not generate segmented code, which imposes a strict limitation on the size of the program, preventing the addition of many desirable features, like the ones below. ----- Include the ability to log a terminal session to a file (save lines scrolled off top, and/or save screen). ----- When a file of type RSRC is downloaded add it to the "Launch" menu. ----- Allow both ports. Also allow two windows open at once, one for each port. ----- Add the ability to clear the screen from a menu. ----- Allow cutting and pasting in the remote commands window. ----- Respond to VT100 cursor position report escape sequence from host, [6n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~FIXED~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do parity in software, don't use the chip. Keep the chip in 8-bit/no-parity mode. This is because the chip would discard incoming characters whose parity it didn't like, and because the techniques used for setting up the chip for mark and space parity didn't really work anyway (which caused incoming underscore characters to be discarded when using mark parity). Fixed June 20 by Frank. During terminal emulation, ignore incoming DEL (0177) characters. Fixed 20 June, Frank. Fix software parity generation for odd parity -- this had been busted all along in all the C-Kermits. Fixed June 21, Frank. Make parity and speed variables in C-Kermit reflect the values from the communications dialog. Fixed by Bill. Fixed on Apr 19 by Bill: Add new tables in ckmutl to translate between the two. Use Kermit's values as the globals. ----- Make the handshake character in the protocol dialog reflect reality. This means that if it is turned off "none" should be lit [WBC]. Fixed on Apr 21 by Bill: Correctly set and test turn when dealing with turnch. ----- Fix the version string!!! (April 1984) [Alan]. Fixed Apr 21 by Bill: Remove paramtext'ed version string from dofiledialog. ----- The event stuff makes for weird empty or partially empty dialog boxes. I did a receive file and got an empty dialog box that eventually (5 minutes) filled itself in [Alan]. Fixed Apr 21 by Bill: Rewrite event handling in screen, loop until all events are handled (deplete event queue). Also merge event handling in screen with miniparse handling so events are not lost between the two. ----- Local echo mode gets goofed up when host echos too. Set local echo on and then connect to PACX to see what I mean. Local echo doesn't echo each character as typed; it only echos an entire line of typein when you hit return [Alan]. Fixed Apr 21 by Bill: Call erase cursor, call flushbuf and draw cursor for each character when in local echo mode. ----- Put local echo support in the terminal emulator [Alan]. Fixed Apr 19 by WBC3: Did not work; reason: no code; solution... add the code. ----- Interrupt protocol on Command-. at any point. Fixed on Apr 21 by Bill. Add the code to support this, can't get eventt type "abort" from the event manager (don't know why) so check the key code instead. Add miniparse to handle this and update events while in protocol. ----- Better ("global") update event handling. Fixed Apr 21 by Bill: this was fixed with the other minparser routine and rewrite to screen. ----- Frequent calls to SystemTask must be made. Fixed Apr 21 by Bill: this was fixed with the other minparser routine and rewrite to screen. Although we are still limited by the frequency of the protocol callbacks to screen. ----- Error messages from ZCLOSE are annoying. Fixed Apr 21 by Bill: Remove the error message when the file is not open and we are trying to close it -- just return in this case. ----- Sending/getting from a second disk does not work. Fixed on Apr 21 by Bill: Set global variable volnum after SFGetFile in ckuser.c; this variable is used by zopeni/zopeno. ----- Problem with terminal emulator. Try "mon" on the vax and look at the first line; the cursor positioning is off by one. Apparently, this only happens on the first line [Alan]. "Fixed" on Apr 22 by WBC3: Could not reproduce the problem, but it may be related to the fact that the tab stops were set wrong. ----- Auto resource/data selection doesn't work nicely. First you are never told which fork the information is going into. Second the selection uses the destination filespec, not the source; so if you GET FOO.RSRC to FOO it goes into the data fork. Make Resource/Data buttons really work for both sending and getting. Make lowercase .rsrc and .data trigger the code as well as uppercase. Improved on Apr 22 by WBC3: Most of this is fixed. GET FOO.RSRC into FOO must work that way so that wild carding will work. You are now always told what fork the data is going into. Capitalization now takes place. ----- A file cannot be deleted when it is in use. This error is not displayed on the GET dialog after the user has told the alert box they want to rid the old version. Fixed on Apr 22 by WBC3: Not only this error but a number of others in ckzmac.c where not reported. All errors noticed should now be reported. ----- If possible make all the debugs and tlog null in a small version of Kermit for skinny Macs. This might save a lot of space. Done on Apr 22 by Bill & Bill: This is accomplished at present with by use of the constant DEBUG. If not defined then neither debug() or tlog() show up. ----- Emulator does not respond to query terminal requests (who are you?) [FdC] Fixed on Apr 23 by WBC3: It now responds that it is a VT102. Better handling of unrecognized escape sequences is now done. (Sequences starting with ESC (, ESC ) and ESC # did not use to be thought of as escape sequences now they are and are thrown away.) Some minor speed up is another result by using a single variable for emulator state flags and a case statement; less overhead is incurred for chars not in an escape seq. Setting smooth scrolling on no longer puts you in insert mode. ----- There seems to be some strange behavior with the Command-. stuff. It seems to cancel on any character and never quite completely. [WBC3] Command-. does not interrupt protocol during send init [Bill]. Need to look at state change stuff WBC put in. Fixed on Apr 23 by WBC3: There were some problems in the protocol state table that caused other problems as well, such as sending a NAK rather than resending the Init packet on receiving a NAK. Command-. still takes a full time out interval to take place, but it does work. ----- Typein to the terminal emulator is bizzarre when a desk accessary is active which also accepts typein. Need to check if FrontWindow before sending characters to terminal driver. Fixed on Apr 23 by Bill & Bill: Now only front window gets input. This is not perfect, if the Remote window is up you can no longer use the terminal emulator. ----- Sending the resource fork doesn't seem to work. [WBC3] Fixed on Apr 24 by WBC3: zchin() was returning -1 on end of file and a char otherwise. It was not type char so any character with the high bit on (as many in a resource fork are) would be sign extended and signal end of file. zchin() is now typed as unsigned char. ----- Can't send ^^, ^@ or ^_. [UI.Stac] Fixed on Apr 24 by WBC3: They show up as ^6, ^2 and ^-. Changed the table contcharmap to reflect that fact. ----- Start of packet char is munged on a restore. [Bill] Can't do "too many" loads and saves of settings. This may be a problem with the Mac as MacTerminal crashes as well doing the same thing. [Bill] Fixed Apr 25 by Bill: Whoops. ----- Mackermit sends lower case file names when it shouldn't. [Doug Brutlag]. Fixed on Apr 30 by Bill*2: Two problems, no null was appended to the converted (upper-cased) name and the routine to convert was not being called when the "AS" filename field had something in it. The "AS" filename field would always have something in it because we stuffed both of the file name fields in the modal dialog -- remove the "AS" stuffing. This is edit V0.6(1) to MacKermit. ----- Switcher does not see a newly transferred file. [Doug Brutlag]. Fixed Apr 29 by Bill: Needed a call to FlushVol in zclose. V0.6(2). ----- Using Apple menu to return to switcher does not work. [Elgin Lee]. Fixed Apr 30 by Bill: Yup, any DA name which does not have a NULL as the first character of the name will fail. This is because the standard SUMACC method for doing this stuff uses the DAname routine. The _mactrap on a GetItem is converting the name into a C string and junking the NULLs, so DAname was designed to put them back. This doesn't work when you are dealing with DA names which may or may not have NULLs in them. Use a local replacement for GetItem called mygetitem which keeps the string in pascal form. V0.6(3) ----- Problem with Saved settings file not getting closed. [Doug Brutlag] Fixed Apr 30 by Bill: Needed a FlushVol after a close in the save routine. Fixed in V06.(4). ----- Loading settings file sometimes results in "couldn't open, error -39" Double clicking on settings file same... [Thompson, Lee]. Fixed May 1 by Bill and Jeff: Many settings related problems resulted when the SUMACC definition of AppFile defined the size of fName to be 1 instead of 255. This made names of 1..4 work fine but larger names smashed the stack and got various errors. This is fixed in edit V0.6(5). ----- When I "RECEIVE" a file, I would like to be able to specify which disk to save it on. There should be a standard Mac volume window, which shows disk name, says "DRIVE", "EJECT" etc. etc. [Harry Saal] Fixed V0.7(19) by Bill. ----- Transfer screen says 'transfered OK' in cases where that is clearly not true. [Mark Thompson] Fixed V0.7(19) by Frank and Bill. ----- The debugging appears not to be written yet. [Mark Thompson] Fixed V0.7(19) by Bill. I removed the debug option, sorry but this is one of the restrictions of using the Mac until we can transfer the program to a compiler that allows for segments. Since the protocol code is common to a number of kermits this is not high priority. ----- Need to display message about "Command-." at some point. [Doug Brutlag]. Nowhere does it tell the user to use Command-. to cancel the transaction. Fixed V0.7(19) by Bill: Mackermit now tells you about this. ----- There is no line terminator (CRLF) translation available at present. This may cause problems trying to use MacWrite files. [Everyone] Fixed V0.7(19) by Bill: There is now, it is called "Text" mode. ----- Use a fixed width font in the TextEdit box for remote commands. Also add a blank line after each request is complete. Allow the window to be cleared. Fix the scrolling as well. Closed V0.7(19) by Bill: Fix width font is now used, dashes between command. Cut/paste in this window will do the clearing, but that is on the wish list. ----- Receive does not allow "receive as" or explicit fork selection. [WBC3] Fixed V0.7(19) by Bill: It does now. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~UNDIGESTED~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1) When running in TOPS20 EMACS as a VT100, if I move to the next screen of a file by moving down one line at a time (i.e. ^N^N^N etc. past the window bottom) it inserts a spurious blank line in the display where the previous last line was. I suspect this may be a fence post problem with region scrolling (I suppose it may also be an incompatability between VT100 and VT102, but I don't see it with MacTerminal). 2) What may be the same problem. When I run Gosling's EMACS, again as a VT100, and delete a line only the bottom line on the screen changes, the rest do not scroll up. 3) The first couple of times I ran MacKermit there was a bit of garbage at the left edge of the top line on the screen, which stayed around through the session. That went away after awhile and hasn't come back so I have no idea whether it's reproducable. Dan Tappan, BBN