Columbia Macintosh Kermit version 0.8(34): Known problems and Limitations ------------------------------------------------------------------------- Last update to this file: 27 July 87 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. To alleviate the problem, MacKermit has been submitted to a number of user groups for wider diskette distribution, and Columbia itself is now distributing Mac Kermit on diskette. ----- 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.) One user claimed to be able to reproduce the problem by using Mac Kermit to GET any file whose name starts with X from the Unix Kermit server (yet others can't reproduce it this way). ----- Certain VT100/102 functions are not supported, including: . Double-height lines . Double-width characters . VT102 printer port commands . etc (See CKMVT1.DOC for a complete list) ----- Character attributes (bold, inverse, etc) are not preserved when restoring the screen after it has been overlaid by another window. The program does not have code (or buffer space on a thin Mac) to do this. ----- 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. ----- When a Settings file is saved, it does not store the Command-Shift-1... Command-Shift-9 flag, so it has to be set every session if it is to be active. ----- After a file transfer, successful or otherwise, the mouse cursor does not turn from a watch back into an arrow. An appropriate message is printed, however. ----- Reportedly, Kermit will die during terminal emulation when certain things happen at the bottom of the screen, e.g. when using the VAX/VMS TYPE/PAGE command, and typing ^Y or ^C instead of CR at the bottom of a page; may have something to do with trying to write on the 25th line in reverse video... A similar problem was reported by a user typing a command into the EMACS echo area (again, at the bottom of the screen) when a "send" came in. ----- Various other (nonfatal) problems are reported to occur at the bottom of the screen, involving status lines or "wholines", forced scrolling in EMACS, etc. ----- 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. ----- Reportedly, the program can be made to hang getting retries and no packet transmission if an earlier file transfer was terminated using Command-dot. (Since Command-dot doesn't send any notification - e.g. an Error packet - to the remote Kermit, the latter is probably going through its timeout/retry cycle. If you experience this symptom, wait for the remote Kermit to exceed its maximum retries.) ----- Reportedly, if you receive a file (interactive), toggle disk drives and insert a new disk, the program may bomb during initialization (the only reported instance of this occurred using RAM Disk "RamStart" from net.sources.mac.) ----- The responses to REMOTE commands come in the small SHOW RESPONSE window. The window might need to be stretched in order to view the entire width of the response (this may not be obvious to the user). ----- The SHOW 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. ----- Reportedly, the lower right corner of the SHOW RESPONSE window is "dead"; clicking on it will not bring the window to the front. ----- Reportedly, the Mac will hang if the ScreenSaver DA blanks the screen during a file transfer. Not clear whether fault is Kermit's or ScreenSaver's. ----- Reportedly, the TRANSFER command will crash the Mac with error ID = 26 when used to launch an application from a different disk. ----- The VT102 emulator may overflow after a few screens of continuous scrolling at 9600 baud. ----- When sending files in TEXT mode, Mac Kermit does not strip the high order bit. This would not normally be a problem, since text files aren't supposed to have high-order bits anyway, but reportedly some applications (like MacWrite) leave a few high bits on even when you instruct them to save "text only". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~THINGS TO DO~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix bugs listed above. ----- The following changes should help the terminal emulator keep up with continuous input from the port at 9600 baud (or higher): . Use arithmetic instead of calling 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. ----- Make the program 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~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Include the ability to log a terminal session to a file (save lines scrolled off top, and/or save screen, cut and paste, etc). Similarly for transmitting raw text (a la MacTerminal pasting onto the 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 response window, or at least a way to reclaim the memory it's using. ----- Add missing VT100/102 functions. ----- Add some kind of login script facility. ----- UNDIGESTED: ------- Date: Sat, 22 Feb 86 02:23:04 EST From: "Michael C. Adler" Subject: MockWrite under HFS The MockWrite editor desk accessory (version 4.0) does not work under HFS. For reasons beyond my comprehension, bit 9 of all the file I/O traps was set. This causes the OS to interpret standard file traps as HFS traps. Although I have patched a version that works, I hesitate to upload it since it is not my software. However, if you have a suitable hex file editor, you can use the following patch list. At each of the offsets specified, change the value A2xx to A0xx. The offsets are into the DRVR resource. If you are editing the resource file as a byte stream, search for the hex sequence: 24 00 00 08 01 6a ff 35. The offsets are from the beginning of this sequence. Offset Current value 6d6 a208 6f4 a20c 716 a20d 726 a200 758 a203 75a a218 766 a212 768 a201 772 a213 a4c a200 a4e a211 ae4 a202 af0 a201 b22 a201 Good luck, -Michael ------------------------------ Date: Wed, 25 Jun 86 16:55:34 cdt From: Peter Wu Subject: CKMKER 0.8(34) bug When using Macintosh kermit ckmker 0.8(34) with the note-pad window opened and the cursor inside the note-pad window, note-pad changes the cursor to an ibeam and kermit changes it back to an arrow, resulting in an alternating cursor of ibeam and arrow. peter ------------------------------ Date: Sun, 7 Dec 86 11:29:35 pst From: gould9!joel@nosc.ARPA (Joel West @ Western Software Technology) Subject: Uploading Macintosh Binhexes with Kermit Keywords: UNIX, MacKermit, hqx I've been meaning to send this along for a while, but I wasn't sure anyone was interested. A query on INFO-MAC prompted this posting. It is a UNIX csh script (MACKERM) that I use to upload binhexes using kermit. If for a file foo.hqx, it first sends the header (before the binhex) as 'About foo', then sends foo.hqx. I use the header to later note the origin on the final unhexed file. To make this work, you need to take the first file (usually a short About... file) manually, selecting the target directory. Then place your MAC in server mode, since each 'kermit' command at the UNIX side is a separate session, and the Mac would otherwise quit file transfer mode. Oh yeah, it also works on ordinary files, preserves actual names ('FooBar' instead of 'FOOBAR') and NEVER transfers a directory. So it's real useful to type mackerm * place the Mac in server mode, and walk away. Joel West joel%gould9.UUCP@NOSC.MIL ihnp4!gould9!joel ==File ===== #!/bin/csh # by Joel West, ihnp4!gould9!joel, 11/14/86 # Script to send binhexes and other files # Also preserves exact upper/lower case name set noglob foreach f ($*) if (-d $f) continue set typ=$f:e switch ($typ) case hqx: case hex: set r=$f:r set T1=/tmp/kermdat_$$ set T2=/tmp/kermhqx_$$ rm -f $T1 $T2 cat $f | cutat '(This' $T1 $T2 kermit -s $T1 -a "About $r" kermit -s $T2 -a $f rm -f $T1 $T2 breaksw default: kermit -s $f -a $f endsw end == EOF == [Ed. - Thanks. This hint has been added to the Macintosh Kermit .BWR file, CKMKER.BWR.] ------------------------------ Date: Fri, 06 Feb 87 09:22:45 ULG From: Andre PIRARD Subject: MacKermit CMS TAKE file To: Frank da Cruz I told you some time ago of national characters and an emerging IBM EBCDIC set called "table 500" to support them. I've composed an according conversion table to be TAKEn on CMS KERMIT for use with MacKermit. Pittifully, it's only useful in file transfer mode. I see no way in terminal mode (on the 7171) that would not involve screen codes translation on the Mac. By the way, there is still the problem of the "OPTION dot" key that is nowhere to find on our national keyboards. We have : (colon) where you have . (dot) and our dot is the shifted key to the right of your M (which is our (dot) and our dot is the shifted key to the right of your M (which is our ",?" (isn't that easy?)). Neither OPTION : nor . (which needs the shift key) nor others yield the interrupt. Do you have a hint? Or wouldn't there be a more "international" choice to be chosen in a future version? Here goes my file for anyone it can help: * CMS KERMIT TAKE file to convert Apple Macintosh extended ascii * international characters to their EBCDIC IBM table 500 equivalent. * use: TAKE KERMAC * within CMS KERMIT connected to a Mac before file transfer. * Andre Pirard * Service General d'Informatique * Universite de Liege * Belgique * SET ATOE 128 099 SET ATOE 129 103 SET ATOE 130 104 SET ATOE 131 113 SET ATOE 132 105 SET ATOE 133 236 SET ATOE 134 252 SET ATOE 135 069 SET ATOE 136 068 SET ATOE 137 066 SET ATOE 138 066 SET ATOE 139 070 SET ATOE 140 071 SET ATOE 141 072 SET ATOE 142 081 SET ATOE 143 084 SET ATOE 144 082 SET ATOE 145 083 SET ATOE 146 085 SET ATOE 147 088 SET ATOE 148 086 SET ATOE 149 087 SET ATOE 150 073 SET ATOE 151 206 SET ATOE 152 205 SET ATOE 153 203 SET ATOE 154 204 SET ATOE 156 222 SET ATOE 157 221 SET ATOE 158 219 SET ATOE 159 220 SET ATOE 161 144 SET ATOE 162 176 SET ATOE 163 177 SET ATOE 167 089 SET ATOE 174 158 SET ATOE 180 178 SET ATOE 190 156 SET ETOA 099 128 SET ETOA 103 129 SET ETOA 104 130 SET ETOA 113 131 SET ETOA 105 132 SET ETOA 236 133 SET ETOA 252 134 SET ETOA 069 135 SET ETOA 068 136 SET ETOA 066 137 SET ETOA 066 138 SET ETOA 070 139 SET ETOA 071 140 SET ETOA 072 141 SET ETOA 081 142 SET ETOA 084 143 SET ETOA 082 144 SET ETOA 083 145 SET ETOA 085 146 SET ETOA 088 147 SET ETOA 086 148 SET ETOA 087 149 SET ETOA 073 150 SET ETOA 206 151 SET ETOA 205 152 SET ETOA 203 153 SET ETOA 204 154 SET ETOA 222 156 SET ETOA 221 157 SET ETOA 219 158 SET ETOA 220 159 SET ETOA 144 161 SET ETOA 176 162 SET ETOA 177 163 SET ETOA 089 167 SET ETOA 158 174 SET ETOA 178 180 SET ETOA 156 190 ------------------------------ Date: Fri 20 Mar 87 11:01:04-EST From: MacIntosh User Group Subject: Kermit on the Macintosh II While in California for the AppleWorld sideshow I was left alone for two hours with a Mac II during which time I had opportunity to pop a Kermit disk into its gaping maw . . . You may be happy to know that, as far as I could tell, the program seemed to run just fine. According to Didier Diaz, the Mac II project coordinator, about 30 to 40% of the programs written for the Mac don't run on the II due to their not following "Inside Macintosh" stringently enough. He was happy to see Kermit faring so well by comparison. Father Mack + (a.k.a.: Fr. Larry D. McCormick, President, CUMUG) ------- Date: Wed, 1 Apr 87 22:23:12 pst From: uw-apl!apl-em!dunlap@beaver.cs.washington.edu Subject: MacKermit 34 on 128K Keywords: MacKermit > Date: Sun, 15 Feb 87 11:58 EST > From: Mark B. Johnson > Subject: MacKermit on a 128K Machine? > Keywords: Mac Kermit > > Is anyone successfully using MacKermit V0.8(34) on a 128K machine? I am sure > we had done it here sometime back, but I have tried it recently with several > different versions of the Finder and System and keep getting system crashes > when trying to Send files. We are sure it is the System and Finder, and are > wondering if anyone who might be doing it successfully could send us their > configuration. Thanks again. I think MacKermit V0.8(34) is too big for a 128K Mac. I have experimented a bit by taking out the VT100 fonts and the "blank cursor" which had been added using the Resource Mover according to Davide Cervone. Without those it gets a bit farther in sending and receiving files. In the receive cases where three dialog boxes are overlaid it bombs. And when sending it bombs when trying to display the files to chose in a dialog box. I have tried this with slightly different results (but not good) using both the original (Summer 1984) system and finder as well as the March 1985 update which includes finder version 4.1. John Dunlap Applied Physics Lab, University of Washington dunlap%apl-em%uw-apl%uw-beaver@washington.edu ------------------------------ Date: 10-JUN-1987 17:35:59 From: DB_WILSON@UK.AC.OPEN.ACS.VAX Subject: Bug in Mac Kermit 0.8(034) Using 2-byte Checksums Keywords: MacKermit I have found a problem using Macintosh Kermit with two byte checksums when the data packet can have bytes with the eighth bit set. The resulting checksum is consistent with such bytes being negative in the range -128 to -1, i.e. bytes are treated as signed -128..127 rather than unsigned 0..255. The Kermit book makes it clear (c.f. page 224) that the latter is correct. The workaround is easy - don't use two byte checksums for binary files. Regards, David. [Ed. - Note: this bug applied to all Kermits based on C-Kermit, and should be fixed in C-Kermit 4E]. ------------------------------ Date: Mon, 20 Jul 87 14:09:03 EDT From: Charlie C. Kim Subject: Mac Kermit and Mac II Keywords: MacKermit (In response to people who complained that Mac Kermit doesn't work on the Mac II) -- MacKermit works on a Mac II; however, the Sumacc C compiler runtime library does not. Unfortunately, the current version of MacKermit is built with the Sumacc C compiler. The problem is the traps and calls to various in-rom/ram packages on the Macintosh are built in-line, on the stack as I remember, by the Sumacc C compiler runtime libraries. This doesn't work too well on a 68020 based system like the Mac II because the 68020 has an instruction cache. If you are willing to live with a (moderate) performance degradation, simply turn off the instruction cache with following MPW asm program: Machine MC68020 nocache main clr.l d0 movec d0,cacr rts ENDP end Simply "restart" your machine to turn the cache back on. Charlie C. Kim User Services Columbia University Here's the corresponding compiled program in binhex 4.0 format: ---------------- CUT HERE ---------------- (This file must be converted with BinHex 4.0) :#@j[)'PMB@0SC3""8&"-2j!%!*!)!@qqk!#3"!%!N!-",!#3!b`!N!0$!4JQEJ! @)'hkZL*Z!!J`%8'm(rrP3#K`!!!H&!*(!2m#H#i!!J#3!d&38%`rN!3!N!S*R`# 3"N&38%`rN!3!N"LG*p!U!*!'!@m"DN(ZrIBI%$mm!2p1V3&53qlqpR"!)YK63'l k3QG"l[lf,`J[,J!12bi!$%KZrrj1Z[ib%"pR%MmZrri[,J!),bi!%NkY!(*J$%* R,bi!##m,6Ud!FNcI')"1AL"Ih[`!%Nl3d&*23d968dm!N!3,SJ9J!!j19[cq)'i !#%2Zr`#3""J!N!-S!!!#!*!%#!#3!b!!!$mm!!'Tm!#3!``!N!-"F!"1H`!#6R8 !!!%!N!-",!#3!b`!N!0$!!,Sk!AL!*!$(!!q!!"$6d4&!!%!#J!!rrmJ!*!)!3! !&!!!(!!#k'`%6@&TE[M5!: [Ed. - Note: Sumacc-related problems should disappear when Mac Kermit is built with Megamax C or other native Mac C compiler.] ------------------------------ Date: Sun, 13 Sep 87 12:41:28 edt From: "Robert B. Stam" Subject: MacKermit on an SE Keywords: MacKermit Here's a copy of the fix I had to use to get Kermit to run on an SE (as opposed to a Plus or earlier). This is a copy of an article posted to comp.sys.mac In a recent posting I commented that I was not able to get MacKermit to run correctly on my Mac SE, and that it seemed to be a problem with fonts. A local insightful chap suggested that MacKermit as delivered from columbia might not have a FOND resource. In fact it does not (this is true of both ckmker.hqx and xkmker.hqx). The fix is as follows: 1) Make a copy of MacKermit. 2) Run Font/DA mover 3) Close the system file fromt the left window 4) Click the left Open button with the option key down (the option key tells it to open all kinds of files, like MacKermit) 5) Find and open the original copy of MacKermit 6) Click the right Open button with the option key down 7) Find and open the duplicate copy of MacKermit 8) Select and remove the 2 fonts (VT100 etc...) from the right hand window (ie, from the copy of MacKermit) 9) Select and copy the 2 fonts (VT100 etc...) from the left hand window, thus copying the 2 fonts from the original copy of MacKermit to the duplicate copy of MacKermit 10) Close everything and quit. MacKermit should now work. This is not quite the NOP operation it looks like. When Font/DA mover moves a font it looks to see if the destination has the appropriate FOND resource, and if not it adds it. Many thanks to Oliver Steele of UNC who guessed what the problem was and suggested that I look for the FOND. Happy Kermitting ... Robert B. Stam CSNET: stamr@unc.cs.unc.edu UNC Computer Science Department ARPA: stamr%unc@mcnc.org Sitterson Hall 083A UUCP: {ihnp4|decvax}!mcnc!unc!stamr Chapel Hill, NC 27514 Phone: (919) 962-1826 ------------------------------ 17-Sep-87 14:42:04-EDT,2388;000000000011 Return-Path: Received: from ACC-SB-UNIX.ARPA by CU20B.COLUMBIA.EDU with TCP; Thu 17 Sep 87 14:41:55-EDT Received: by ACC-SB-UNIX.ARPA (5.51/4.7) id AA23529; Thu, 17 Sep 87 11:43:43 PDT Date: Thu, 17 Sep 87 11:43:43 PDT From: kevin@ACC-SB-UNIX.ARPA (Kevin 0'Gorman) Message-Id: <8709171843.AA23529@ACC-SB-UNIX.ARPA> To: sy.fdc@cu20b.columbia.edu I found this in ckmker.bwr in the 4E(066) distribution. I ran into a very similar problem I thought I would pass along. > 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.) One user claimed to be able to reproduce > the problem by using Mac Kermit to GET any file whose name starts with X from > the Unix Kermit server (yet others can't reproduce it this way). I was reading the kermit distribution from a VAX running 4D kermit, and 4.3 BSD with a Mac Plus running 0.8 Kermit. The VAX was running as server, and I requested x*. I would get the first file okay, but all others would pass by VERY fast, with the notation "Discarded" and "K bytes: 0" on the Mac. When I renamed that first file, that had arrived okay, so that it was no longer selected by x*, I got the new first file okay, but all others were passed over. This repeated ad infinitum. I renamed all files on the VAX so that none began with "x", and they came across just fine. Another thing I noticed, that may bear on this, is that the renaming of the files did not agree with the documentation. Some of my files had more than one period in the name (I originally was trying to get compressed files named like ckusr.c.Z), and I found that the mac reported the filename being recieved as CKUSR.CXZ. I gathered that it was changing things so that there were never more than 1 "." in a filename. I can't tell which system did this. Since "x" is special in this way, the special code may be munging incorrectly on subsequent files of a set. I dunno. I just thought I would pass along instructions on how to repeat this.