FILE CKMKER.BWR MACINTOSH KERMIT "BEWARE" FILE May 1996 Mac Kermit version: 0.993(192) / C-Kermit 6.0.192 Beta This last file updated: Sat May 18 17:19:05 1996 Author: Frank da Cruz, Columbia University e-mail: fdc@columbia.edu *** MACBULLETINS *** Mac Kermit 0.993(192) dated 16 May 1996 or later uses the Communications Tool Box and so should get around bombs and other unpleasantness when trying to open or close the serial communication device, and it should also let you use communication devices other than the modem port and the printer port. Mac Kermit 0.991(190) dated 8 August 1994 or later fixes the problem with downloading under newer System releases (7.1.x). Now files can be downloaded on newer systems such as Centris 660 AV with OS 7.1, Power Mac 7100/66 with OS 7.1.2, etc, without bombs or other nasty effects. The "0.991" designation differentiates the version that has this fix from "0.99" versions that did not have it. Other fixes new to 0.991(190) include: . OPEN READ / READ / CLOSE READ fixed. . LOG { SESSION, TRANSACTION, PACKETS } fixed, and the format of the resulting logs is now correct and the creator of these logs is now shown as TeachText ('ttxt') so you can click on them and get normal-looking text on your screen. . Downloaded text files now also are TeachText. . Incoming files now obey the file-type attribute (text or binary) that precedes the arriving file, unless Mac Kermit has been manually placed into MacBinary mode, or "WHOAMI" comes into play (see ckcker.upd). . The Command Window SET FILE TYPE command now works right, even for MacBinary. . The Command Window CD and PWD commands now work. . A DIRECTORY command has been added to the Command Window, showing the names and sizes of all the regular files (but not folders) in the current directory. . The current directory is now shown in the file transfer display, and the other items (e.g. "sending" vs "receiving"; "text" vs "binary" vs "macbinary", etc, should now be correct. . "Writing to console not allowed" alert boxes should be eliminated. . The SET FILE COLLISION APPEND, UPDATE, and DISCARD commands have been removed, since they didn't work (or worse!). . All \v(...) variables are now set correctly, including \v(home), \v(dir). So if you want to set your prompt to show your current directory, you can "set prompt [\v(dir)] Mac-Kermit>". (But unfortunately, Version 0.991(190) now seems to lack the ability to be launched from a script program. The result is something like "Illegal Instruction at 006E4BCC mberto+6000". Cause & cure unknown.) (Also, here's another bad report on this version: "I am using mackermit 0.991(190) on a Mac SE with 4 megs. memory and whenever I attempt to receive a file I get an unexpected quit with an error 15. This is a 'segment loader error.' If I quickly start the program again, it will download the files correctly.") ***************** This document applies to the pre-pre-pre-pre-release of Mac Kermit 1.0. This is a work in progress, and progress is slow due to lack of funding and of volunteer programmers with expertise in Macintosh programming, plus the neverending proliferation of Macintosh models and software. Many features remain to be filled in, refined, fixed, or even designed before Mac Kermit is suitable for "1.0" designation. ----------------------------------------------------------------------------- Version 0.99 is the first Mac Kermit version built with the C-Kermit 5A file transfer protocol and user-interface modules, so it incorporates all the latest protocol features of C-Kermit, including sliding windows and character set translation, plus C-Kermit's command and script programming language. As yet, there is no documentation for Mac Kermit 1.0 except the Mac Kermit 0.9(40) user guide, this file, and the C-Kermit documentation, which describes the commands you can give at the Mac-Kermit prompt in Mac Kermit's new command window, which are useful in Mac Kermit for modem dialing, script programming, etc. C-Kermit documentation is: Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Digital Press / Butterworth-Heinemann, Woburn, MA, 1993, 514 pages, ISBN 1-55558-108-0 US single-copy price: $39.95; quantity discounts available. Available in computer bookstores or directly from Columbia University: Kermit Development and Distribution Columbia University Academic Information Systems 612 West 115th Street New York, NY 10025 USA Telephone: (USA) 212 854-3703 Domestic and overseas orders accepted. Price: $39.95 (US, Canada, and Mexico), $50 elsewhere. Orders may be paid by MasterCard or Visa, or prepaid by check in US dollars. Add $35 bank fee for checks not drawn on a US bank. Price includes shipping. Do not include sales tax. Inquire about quantity discounts. You can also order by phone from the publisher, Digital Press / Butterworth-Heinemann, with MasterCard, Visa, or American Express: +1 800 366-2665 (Woburn, Massachusetts office for USA & Canada) +44 1865 314627 (Oxford, England distribution centre for UK & Europe) +61 03 9245 7111 (Melbourne, Vic, office for Australia & NZ) +65 356-1968 (Singapore office for Asia) +27 (31) 2683111 (Durban office for South Africa) A German-language edition is also available: Frank da Cruz and Christine M. Gianone, "C-Kermit - Einfuehrung und Referenz", Verlag Heinz Heise, Hannover, Germany (1994). ISBN 3-88229-023-4. Deutsch von Gisbert W. Selke. Price: DM 88,00. Verlag Heinz Heise GmbH & Co. KG, Helstorfer Strasse 7, D-30625 Hannover. Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 53-1 29. This file contains information for both users and for implementors. Eventually everything will be sorted out and we'll have professionally published Mac-Kermit-specific user documentation. Send comments, bug reports, etc, to the author at the e-mail address above. If you are reading this file from the Mac Kermit diskette, please skip ahead to the NEW FEATURES section below. THE HQX FILE The Mac Kermit program is distributed on the Internet and BITNET/EARN in printable ASCII BinHex 4.0 form. Convert back into a runnable application using BinHex Version 4. If you have BinHex 5.0 rather than 4.0, you will have to edit away the plain-text line: (This file must be converted with BinHex 4.0) and, if there is an empty line below it, the empty line too. Then it should be covertible by BinHex 5.0. You can also order Mac Kermit on diskette, ready to run, from Columbia University at the address above. NEW FEATURES Multiple screen windows: for terminal emulation, command processing, text editing, server response, etc, managed in the normal Macintosh way, as well as with a new "Window" menu to select Mac Kermit windows explicitly. Cutting and pasting works among most of the windows, including double click to select a word, triple click to select a line. Material can be copied from the terminal window to other Mac Kermit windows, or to other applications. Pasting into the terminal window sends text to the remote computer. The terminal session can also be logged directly to a file. The Command window runs the C-Kermit command parser, just like on UNIX, VMS, or OS/2, and similar to MS-DOS Kermit. This gives you access to features that are not in the mouse/menu interface, most importantly the DIAL command and the script programming language, and allows the same script programs to be used by C-Kermit on UNIX, VMS, the Amiga, OS/2, etc, and by MS-DOS Kermit (with proper precautions about portability). Text command files can be used as Mac Kermit startup files ("init files", like for C-Kermit or MS-DOS Kermit). Filenames can be referred to by their full path names in the SEND command, etc, for example "send diskname:foldername:filename", or by relative pathnames, e.g. "send ::foldername:filename". An absolute pathname starts WITHOUT a colon (:). For example: hd80:test:folder:oofa.txt The first component of an absolute pathname is the disk. A relative pathname begins with a colon (:), meaning "the current directory". Two colons means "the superior directory", for example: cd :: means to set C-Kermit's working directory "up one" from its current one. Other new features include: . Window sizing (vertically only) using the size box, including the terminal emulation window. . Scrollback in most windows, including the terminal window. . Font selection in the terminal window. . More efficient file transfer via sliding window packet protocol and longer packets. The window size may be as big as 32 (the theoretical maximum) and packets can be up to about 5000 characters long. . File transfer character set translation (available only via the Command window). The commands are SET FILE CHARACTER-SET, SET TRANSFER CHARACTER-SET, and SET LANGUAGE. . Locking shift packet protocol for efficient transfer of 8-bit data over 7-bit communication channels. . Dynamic packet size adjustment to adapt to communication line quality. . File transfer thermometer. . Redesigned menus (but nowhere near final). . More advanced terminal emulation, including many (but not all) features of the VT220 and VT320 terminals. . Faster terminal emulation. . Many bugs fixed. MISSING OR DESIRABLE FEATURES . No Tektronix or ReGis graphics emulation yet. . Missing VT320 features, including 132-column mode, and VT220, VT102, VT100, and VT52 submodes, various reports. . Selection among VT320, 220, 102, 100, and 52 needed, with appropriate terminal-type ID in response to "What Are You?" queries. . No 3270 terminal emulation. . No color support, e.g. ANSI color directives during terminal emulation. . No "Print selection" and "Print screen" options selectable by mouse clicks (work is in progress). Presently, printing can only be done in the terminal window via escape sequences sent from the host. . No SET KEY command -- key settings are accessible only through the menu interface. . No network support, especially TCP/IP TELNET. . No APC support for autodownload, etc. . No multiple sessions -- e.g. modem port in one window, printer port in another. The hard part here is not putting up another window, but associating all the varied and many communication, protocol, and terminal emulation parameters separately for each window (this is not just a programming problem, but also a user interface design issue). . Internationalization of the user interface (this will be done before the final release) (well, it was going to be done, but all the participants in this project have vanished). . Operation as a server is problematic. Dialing in to a Mac running Mac Kermit in server mode is problematic because the needed modem signals are not available on the Mac. The server's response to REMOTE CD, REMOTE DIRECTORY, REMOTE DELETE, and similar commands is either not working or leaves much to be desired. Server end of REMOTE LOGIN is not implemented. . Some of the commands in the Command Window simply do not work. Other essential commands are missing. USING MAC KERMIT WITH MODEMS The Macintosh serial port is not an RS-232 device and does not support the full repertoire of modem signals needed for normal operation with modems. Communication with modems is accomplished using various "fakeouts", each of which sacrifices some feature in order to accomplish some other feature, since the Mac has only one modem signal to send to the modem, and reads only one modem signal from the modem. Thus, for example, the Mac can't hang up the phone by dropping DTR and use hardware flow control at the same time. To have the ability to hang up the phone by dropping DTR, you need a regular Macintosh modem cable that connects the Mac's "Handshake Out" signal (Mini-Din-8 Pin 1) to the modem's DTR signal (DB25 pin 20), and the modem should be configured to hang up when DTR goes down. In Mac Kermit, you should NOT check "DTR input flow control" or "CTS output flow control". To use hardware flow control with high-speed modems, you need: 1. A special Macintosh hardware-flow-control-modem cable that connects the modem's CTS signal (DB25 pin 5) to the Macintosh's "Handshake In" signal (Mini-Din-8 Pin 2) and the Mac's "Handshake Out" signal (Mini-Din-8 Pin 1) to the modem's RTS signal (DB25 pin 4). This cable *might be* available from stores or suppliers as a "Macintosh Hardware Handshake Modem Cable" (buy at your own risk). 2. You MUST configure your modem to ignore DTR ("&D0" on most Hayes and compatible modems) and to use RTS/CTS flow control. NOTE: This means you can't hang up the phone by "dropping DTR". Normally, it will hang up automatically when you log out from the remote computer or service. If it doesn't, use the escape sequence (such as +++) to get back to the modem's command processor, and then type the modem command for hanging up (usually ATH0). 3. In Mac Kermit's Communications Settings menu, uncheck Xon/Xoff flow control, and check DTR input flow control and CTS output flow control. To use the internal modem on the Powerbook, use the Portable or PowerBook control panel (depending on if you're using System 7.0 or 7.1) to switch between the internal modem and the external modem serial port. Reportedly, on the Duo (and perhaps other Mac models) the relevant control panel is in a subfolder within the Control Panels folder, and moving it one level up makes the modem work OK. Similarly, other "strange" communication devices, such as the GeoPort Telecom Adapter, must be selected from the Control Panel (turn on Express Modem, and set the modem port for "Use Express Modem"). Speaking of the Geoport Express Modem, one user reports: "Using Kermit 0.99(190) released Nov,'93 I cannot transfer more than 1024 bytes of a file. I have a Quadra 660av with the Geoport Express Modem and when I put my VAX account into a kermit server mode, Kermit 0.99 can tell it to send a file, and it begins transferring it. Then I get a system error. Sometimes it bombs with a "Floating Point processor not installed." Is this a bug of the GeoPort modem? I've had several programs bomb on me with that same message once in a long while." Reportedly, it is possible to have port-sharing (modem-sharing) on an AppleTalk network, using (for example) a Shiva Telebridge (serial port[s] on one side, AppleTalk port on the other, and appropriate drivers installed in the Macs, to make it appear to be the regular modem or printer port). It is not known whether Kermit works with such devices. Here's a tip from a user about using external protocols: "I love your Transfer APP command. It works well to change applications before your modem even realizes you had - I needed to do a Xmodem download, but I was already logged in through MacKermit." PRINTING The only kind of printing currently supported by Mac Kermit is host-directed printing, which occurs when the host sends VT100 "printer on" and "printer off" sequences. Thus the print menu is normally dimmed. When the host sends: ESC [ 5 i (or) ESC [ ? 5 i -- Turn on printer ...text... ESC [ 4 i (or) ESC [ ? 4 i -- Turn off printer The text between these two sequences is put into the "capture buffer". When the turn-off-printer sequence is received, the Print menu items become undimmed and you can print the captured text. There is a limit of about 32K on the size of this text. This type of printing is normally accomplished with a utility on the computer that you have connected with Mac Kermit, such a "pcprint" UNIX shell script. NOTE: As of edit 190, the Print menus have changed somewhat, but the operation is substantially the same. When transparent print material arrives, a box appears on the screen saying "Capturing text to be printed", and when the transparent print operation is complete, the "Print captured text" menu item is activated. There is a new "Print..." item which is undimmed at all times, but apparently does not do anything. Reportedly, host directed printing works better in 0.99(190) than in earlier edits, but the print buffer is never cleared. Hopefully, future releases of Mac Kermit will have additional printing capabilities: print screen, print selection, log session to printer, etc. TERMINAL EMULATION Most screen functions of the VT220 and 320 are supported, including selective control of character attributes, the DEC Technical character set, and Latin-1 and other Roman-based West European character sets, but Mac Kermit identifies itself as a VT100-series in response to a host-generated Terminal ID Query (ESC Z). Thus, to take advantage of Mac Kermit's VT220/320 features, you must manually identify your terminal type to the host software, for example in VMS: SET TERM /DEVICE=VT220 or in any of various ways in UNIX, such as: term vt220 TERM=vt220 ; export TERM export TERM=vt220 setenv TERM vt220 You can stretch the screen to different lengths other than the default 24. Kermit responds correctly to "resize" commands from the host, which attempt to learn the terminal's (i.e. Kermit's) screen dimensions, e.g. in UNIX: `eval resize` or in VMS 6.0 or later (but not earlier): SET TERMINAL/INQUIRE KEY MAPPING Keys may be mapped as described in ckmker.doc (Mac Kermit Doc on the Mac Kermit diskette), using the Set Key Macros item in the Settings menu. In addition, a selection of "keyboard verbs" similar to those in MS-DOS Kermit is available. These verbs can also be assigned to any key, and they are special in that they track the VT terminal keypad and cursor mode dynamically. The "Mac Key" column shows the default assignments for these verbs. Codes that sent by arrow keys: Cursor-Key Mode...... Mac Kermit Mac Key Cursor Application Keyboard Verb Up Arrow ESC [ A ESC O A \upparow Down Arrow ESC [ B ESC O B \downarrow Right Arrow ESC [ C ESC O C \rightarrow Left Arrow ESC [ D ESC O D \leftarrow Note: the host application software controls the cursor key mode via the following escape sequences: ESC [ ? 1 h SM Set arrow keys to cursor mode ESC [ ? 1 l RM Set arrow keys to application mode Codes sent by Numeric Keypad keys: DEC Mac Keypad Mode: Mac Kermit Key Key Numeric Application Notation PF1 clear SS3 P SS3 P \pf1 PF2 kp = SS3 Q SS3 Q \pf2 PF3 kp / SS3 R SS3 R \pf3 PF4 kp * SS3 S SS3 S \pf4 0 kp 0 0 SS3 p \keypad0 1 kp 1 1 SS3 q \keypad1 2 kp 2 2 SS3 r \keypad2 3 kp 3 3 SS3 s \keypad3 4 kp 4 4 SS3 t \keypad4 5 kp 5 5 SS3 u \keypad5 6 kp 6 6 SS3 v \keypad6 7 kp 7 7 SS3 w \keypad7 8 kp 8 8 SS3 x \keypad8 9 kp 9 9 SS3 y \keypad9 comma (,) kp + , SS3 l \keypad, minus (-) kp - - SS3 m \keypad- period (.) kp . . SS3 n \keypad. Enter enter CR or SS3 M \enter CRLF (newline ON) Note: The host controls the keypad mode with following escape sequences: ESC = DECKPAM Set numeric keypad to application mode ESC > DECKNPNM Set numeric keypad to numeric mode Note 2: there is no Keypad + on a DEC VT terminal. DEC User Definable Keys (UDKs) are not supported. There are no verbs for DEC VT220 function keys F6..F20 or editing keys, but their codes are constant. These codes may be assigned to the keys of your choice using Set Key Macros. The codes are as follows: DEC Key Code DEC Key Code F6 ESC [ 17 ~ F17 ESC [ 31 ~ F7 ESC [ 18 ~ F18 ESC [ 32 ~ F8 ESC [ 19 ~ F19 ESC [ 33 ~ F9 ESC [ 20 ~ F20 ESC [ 34 ~ F10 ESC [ 21 ~ Find ESC [ 1 ~ F11 (ESC) ESC [ 23 ~ Insert Here ESC [ 2 ~ F12 (BS) ESC [ 24 ~ Remove ESC [ 3 ~ F13 (LF) ESC [ 25 ~ Select ESC [ 4 ~ F14 ESC [ 26 ~ Prev Screen ESC [ 5 ~ Help ESC [ 28 ~ Next Screen ESC [ 6 ~ Do ESC [ 29 ~ GENERAL BUGS Mac Kermit versions past 0.9(40) are too big for 512K Macs or below. Reportedly, even attempting to start Mac Kermit on a 512K mac results in a System error that requires the Mac to be restarted. The DIAL command, although it works mostly as intended, seems to sometimes have nasty aftereffects, such as system crashes, which might appear later on in the session, e.g. after CONNECTing, escaping back the Command Window several times, etc, and then starting a file transfer. Approach the DIAL command with caution. Some of Mac Kermit's settings are not saved in the "Save Settings" file. These include the communication port, certain key settings, menu-command-keys active, etc etc. Some of these settings, however, can be saved in an ordinary text file as interactive-mode commands, such as "set port printer", etc. The interface used by "Save Settings" is not standard for Mac apps. It should automatically save the settings from whichever file they were loaded from and should not invoke the SPF Dialog unless Mac Kermit was launched without settings and has not loaded settings. If any setting has changed you should be prompted whether you want to save settings upon quit or load settings. Reportedly on a PowerBook 100 and SE30 (and perhaps other models), "put Kermit away in the finder menu by quitting using close or clicking on the close box. See the dimmed Kermit icon in the folder (normal so far). Now try to re-enter Kermit, either by double-clicking on the icon in the folder, or by selecting it from the Finder menu. Crash, bomb screen says "bus error" and allows you to restart. No funny type manager INITs. Doesn't seem to be bothered if the Kermit window is left open, only when it's closed but not Quit." Reportedly, "On a Mac LC III, running sys 7.1 *invariably* and *ALWAYS*; every time I save a macro or macro set, Kermit Crashes, giving an error message '#1'. This is independent of any INITS or CDEVs, and always occurs." Reportedly, "On a Mac II with System 6.0.7 with math coprocessor and Color Cursor, Dimmer, Mousekey, Programmer's key, Randomizer, and SAM Interrupt loaded, any attempt to save the settings file freezes the system." Reportedly, "Using a Mac Plus with 45Meg Rodime but running Kermit from a floppy, doing a GET FILE from PC to Mac at 19200 bps with the PC as server: when the PC says 100% transmitted I get System Error ID=27 on the Mac. The restart button on the error message box does not reboot." Reportedly, "Mac Kermit gives a repeated error 28 (ioNotOpenErr) dialog which you cannot cannot escape from. This happens after its serial port has been stolen away by some other app. This happened to me quite innocently - I was using Mac Kermit to access a BBS. I logged off (but left Mac Kermit running). Then I used my address book app to dial someone. Then I went back to Kermit and needed to use MacsBug to avoid rebooting my system." Reportedly, "When I use "Set Key Macro" to set F14 on my extended keyboard (F14 = at&fm0td7411400\015), Mac Kermit will crash when I have Appleshare and HP Background extensions installed. This only happened when I was also running "DiskStatus", a startup app. All under sys 7.0.1 tuneup 1.1.1. The crash clobbers system memory or something, because I must reboot, as 'es' in Macsbug is insufficient." Reportedly, "When my copy of Mac Kermit 0.99(188) (running under System 7.0.1 bullet on a Quadra 750) receives random garbage (either because I accidentally cause a binary file to be displayed, or because of the few garbage characters my modem always seems to spit out when the other end disconnects), Mac Kermit and the Mac occasionally hang, with roughly 10-20% probability. (The mouse cursor tracks, but no clicks or keystrokes are honored, and other "background jobs," including an on-screen clock, all stop.)" (This is evidently caused by reception of a Ctrl-S (Xoff) which is not followed by a Ctrl-Q... But Mac Kermit is supposed to wake up after 8 seconds from an Xoff deadlock...) Similarly (from another report about edit 188), "I can call the program without difficulty, but when I go to shut down the machine I get the message 'Shutdown could not be completed because the application "Kermit 0.99(188) could not quit'. When I click OK on this it says, 'The application 0.99(188) has unexpectedly quit because an error of type 87 occurred.'" Severe problems when running on a Mac (only under System 7?) that has SuitCase, Adobe Type Manager, TrueType, or Mac Layers Keyboard loaded, ranging from messed-up screens (bad font spacing) to Kermit or Mac bombs. Hopefully this will clear up when the new Macintosh Extended Latin font is finished and integrated with Mac Kermit. There also seems to be an incompibility between Now Utilities 4.01 and MacKermit. It worked OK with NU 4.0, but with NU 4.01, if you try to launch MacKermit from a pull-down NowMenu, the Mac (e.g. IIci, System 7.0 with TuneUp 1.1.1) freezes. One user reports that Mac Kermit bombs unexpectedly "when trying to use key settings" unless "32-bit addressing is turned off". Another user reports that Mac Kermit does not work at all in 32-bit mode, or with RAMDoubler, but only in 24-bit mode with no RAMDoubler: "I've tried MacKermit with 32-bit on and RAMDoubler on, with 32-bit on and RAMDoubler off, and with 32-bit off and RAMDoubler on. I had problems of freezes and keyboard locks under each scenario. In other words, it seems on the surface that MacKermit likes neither 32-bit mode nor RAMDoubler itself. I'm running system 7.1 on a IIsi with 5mb RAM. Under 24-bit mode w/o RAMDoubler, MacKermit works beautifully." Reportedly, "Sometimes, quitting a session does not release the 600K memory allocated by Kermit. I noticed this once when I quit without closing the connection. It may have happened on other occasions also." Reportedly, "When I close the Kermit window (using WindowShade) the mouse arrow stays invisible until I click over to some other application (or the finder.)" Reportedly, "The inverted screen setup somehow gets shut off when I log on to my account. In addition, inverting the screen should also invert the mouse arrow (which is black), but it doesn't, making the arrow invisible with an inverted screen." Kermit's ID (signature) is KR09, which hasn't changed in years, so if you have a lot of different Kermit versions on your disk, clicking on a Kermit startup file will start a random version of Kermit, not necessarily the one you want. The ID should be updated to KR10 (files ckmker.mak = kermit.make, ckmdef.h, ckmker.r, ckmkr2.r, ckmsav.c). Starting one copy of Mac Kermit while another one is active (e.g. under MultiFinder) results in lots of errors for both Kermits. Kermit always initializes the modem port when it starts up, and this hangs up any other version of Kermit (and who knows what other programs) that might be using the modem port. Kermit should (a) not touch the communication device until it needs to do i/o (this would give the selection of alternate communication devices the opportunity to take effect first), and (b) should (if this is possible on the Mac) detect whether the communication device is in use already, and if so, give an appropriate error message. Reportedly: "In the command window, I gave the command while = 1 1 {wait 10,output \013} and pressed return. In order to interrupt the loop, I pressed Cmd-., but Kermit sent "^A1 EUser cancelledS", which appears to be a Kermit protocol packet. After a couple of Cmd-.'s, the "Mac-Kermit>" prompt appeared." MENUS, WINDOWS, AND DIALOG BOXES The menus are not complete, and should be rearranged. They must fit on a small screen, even after translation into languages like Swedish, where the words are longer than English. See APPENDIX at the end of this file. The File menu (English version) is too long for a small screen. Some of the dialog boxes violate the Human Interface Guidelines (HIG) from Apple, and need redesigning also. The edit menu Undo command doesn't work, and the Edit menu lacks a Select All command. Typing a letter into a file dialog box tends not to scroll the file list. If you click on Load Settings in the File menu while the command screen is foremost, the terminal screen will come to the foreground. However, any characters you type still go into the command window. Load Settings should either leave you in whatever window you were in before, or else fully select the terminal window. Various items are not saved in the settings file: the communication port (modem or printer), character sets, etc. Various confusion with cutting and pasting between windows, especially after a window that has been cut from is closed. Pasting text into the bottom of a text window does not cause the scroll bar to update; any text below the visible region cannot be scrolled to or otherwise viewed. (Workaround: save and reopen the file.) Click and drag to select text doesn't scroll. Shift-clicking should be a workaround for the above problem, but it doesn't work exactly as it should either. If the selection is scrolled out of sight, you can only shift click if the selection is >0 characters long (that is, you can extend a selection, but not from a 0-length selection). When pasting text into the buffer, if the text is too long, the edit menu remains highlighted and Kermit appears to be out of commission. Using MacsBug to 'es' and restart it, repainting the screen in the editor buffer on the host that was being pasting into, shows that the pasting went partway and then some characters were lost. There is no way to select file and transfer character sets in the menus, or language rules. Furthermore, the present character-set menu applies only to the terminal emulation character set, and it lists many sets that are not implemented. These should be removed. The new menus should look approximately as shown at the end of this file, in the proposed menu design appendix. TERMINAL EMULATION BUGS & LIMITATIONS Various VT200/300 functions are not implemented, including the character-set related items described below, UDKs, various DECDSR, DECRQM, and other report requests (UDK status, keyboard dialect, keyboard action, insert/replace mode, newline mode, cursor key mode, numeric keypad mode, 132 column mode, smooth scroll, reverse video, autowrap, palette request, UPSS state, tab stops). Reportedly, if you increase your terminal screen size, Mac Kermit does not use the new screen size for scrolling until the host places material in the new bottom line by direct cursor addressing. Local echoing doesn't work very well. Reportedly the characters are the wrong size and appear at positions that are unrelated to the cursor or mouse location. Reportedly, "I have been using Kermit 0.99(188) on a Mac Classic with a 2400 Baud Hayes modem to connect remotely to a number of machines. When the remote text is formatted as bold, I tend to lose characters occasionally and spurious spaces are slipped in quite often. If I do anything to refresh the screen, such as activate and then deactivate the screen save, or type control-L, the spurious spaces disappear and the missing characters reappear. This behaviour is only observed with bold characters, and did not occur with Kermit 0.98." If you select Mouse -> Arrow Keys in the Terminal Settings dialog, there is no way to turn off this feature. Window height can be changed, but not width. Thus 132-column mode is not supported. Mac Kermit does not respond correctly to DECCOLM escape sequences from the host, i.e. ESC [ ? 3 h/l (h = 132 cols, l = 80 cols). Aside from not changing the screen width, Mac Kermit also neglects to perform the other actions associated with these sequences: (1) clear the screen, (2) home the cursor, and (3) set scrolling region to 24 lines. Reportedly, Mac Kermit occasionally forgets its window height. E.g. if you set the window height to (say) 38 by dragging the corner of the terminal window, and inform the host of your new terminal dimensions, eventually (maybe after several hours of correct operation), Mac Kermit will begin to scroll within a 24-line line window, even though the window is still 38 lines long. Keyboard handling is not independent of the keyboard driver -- it assumes the US keyboard driver. For example, Mac Kermit doesn't handle dead-key combinations used in France, Sweden, etc. Mac Kermit accesses the KCHR resource, which is a no-no for System 7. Beware of the Option key. It changes the value of any characters you use with it. If you type Option-F, the Mac will send a D, if you type Option-B, the Mac will send a ":", etc. If you want to use the option key as a modifier, be sure to check the "Unmodify" box. There is no mechanism (such as SO/SI, SS2, or SS3) for sending 8-bit characters to a 7-bit host during terminal emulation. Reportedly, trying to scroll the terminal window while data is being sent to it can crash the Mac (I can't reproduce this one, maybe it's fixed now... or maybe it only happens with SuitCase, etc, loaded). Various obscure bugs with VT220/320 character attributes (most frequently appearing when using the UNIX "more" command). Various failures with "vttest". Set Key dialog box should show what a key sends if it is "unbound". Set Key Macros should allow decimal and hex escapes as well as octal, like MS-DOS Kermit (or C-Kermit itself): \onnn = octal, \dnnn = decimal, \xnn = hex, \nnn defaults to decimal (of course changing the default will cause problems). C-Kermit already has code to parse these forms, as well as to handle grouping, e.g \{27}2 to send ESC followed by 2. Bad default mappings for many keys: Ctrl-1, Ctrl-2, etc, thru Ctrl-0. (Also Shift-Ctrl-1, etc). Ctrl-2 and Ctrl-Shift-2 should send NUL (ASCII 0). Ctrl-6 and Ctrl-Shift-6 should send Ctrl-^ (ASCII 30). The other top-rank number keys should send nothing when pressed with Ctrl. Reportedly, under System 7 some of these key combinations aren't even noticed. Others too: Ctrl-+, Ctrl-; have codes when they shouldn't, etc etc. An option to make the cursor change size depending on whether the VT emulator is in "insert" or "replace" mode might be desirable (handy for IBM mainframe Xedit users). A wealth of information about VT terminal emulation can be found in kermit/a/msvibm.vt (the online description of the MS-DOS Kermit terminal emulator) on kermit.columbia.edu, or (in more complete form) in Appendices I and II of "Using MS-DOS Kermit", Second Edition, by Christine M. Gianone, Digital Press, 1992. COMMAND BUGS AND PECULIARITIES The command parser (in the command window) is not well-suited for dealing with Macintosh filenames. Completion and file lists are not implemented. Spaces within names must be entered as \32 (32 is the ASCII code for space); for example, if you want to send a file called: Mac Kermit Doc you must type: send Mac\32Kermit\32Doc (Note: the CD command does not have this restriction, but most other file- and directory-related commands do.) The command window scrollback feature doesn't work until after you leave the command window and then reenter it. No filename completion when ESC or TAB is typed within a filename, no file lists are produced when "?" is typed in a filename, and yet there is no beep to indicate these features don't work (instead, the cursor disappears). Some SET and other commands have no effect, in particular all the SET TERMINAL commands, SET FILE NAMES, ... These should be filled in, i.e. hooked in with the Macintosh code so that both pieces of the program (Mac menu and C-Kermit command parser) use the same variables. The PAUSE command should wake up immediately (and fail) if the user hits a key or clicks the mouse. SET LINE should be converted to use a keyword table (the choices are MODEM and PRINTER). (Well, not really -- we still want them to be able to type real device names...?) Messages displayed by the DIAL command, by script execution, etc, do not appear on the command window screen until the next prompt appears. In fact, this seems to be true of the messages displayed by any command, but most other commands finish quickly and a prompt is issued right away, so you don't notice this effect except for DIAL, etc. SET DIAL DISPLAY ON doesn't work at all (even though dialing itself works fine). Reportedly, "Double clicking on a kermit script results in kermit waking up and dying with an error, at best and CHK error and reboot at worst. Double clicking on a kermit script with kermit already running results in "Unimplemented System Trap", and the machine reboots." FILE TRANSFER PROBLEMS Mac Kermit does not reject incoming files on the basis of size (the zchkspace() function in ckmfio.c is not filled in). File-append operations are not implemented, viz. appending to logs or downloaded files. Date-related operations, such as transmission of file dates, are not implemented. The SET FILE COLLISION UPDATE, APPEND, and DISCARD options are not implemented. In the file-send dialog box, an attempt to edit the "Send As" name results in a failure to display the file's name and "as-name" in the file transfer display. However, the file is still sent the the specified name. Similarly, when sending "the entire folder" from Mac Kermit, the file transfer display is not filled in properly, but all the files in the folder are indeed sent. Incoming MacBinary files are not recognized automatically -- you have to click the MacBinary button beforehand. (Not really a bug, just a desirable feature. Apparently some other Mac communication programs can do this.) Sometimes an incoming MacBinary file, even when when all transfer modes are set correctly, will fail to be recognized by Mac Kermit as MacBinary; reportedly this happens primarily when the files are very big. Mac Kermit will say it is reverting to ordinary binary mode / data fork, and yet still display "MacBinary" as the transfer mode in the transfer display. (Reportedly, when this happens, the StuffIt program can be used to convert the file -- if it really is in MacBinary format -- back into an application.) An incoming MacBinary file might have a garbage character stuck onto the beginning of its name (the suprious character will generally show up as a square on the Macintosh screen). If Mac Kermit is told to receive a file in MacBinary mode, and the file truly is not in MacBinary format, Mac Kermit always switches to "binary mode / data fork". There should be an option to let the user decide on the fallback transfer method (e.g. "binary / resource", needed for sound files). If a group of MacBinary files is transferred *to* Mac Kermit (remote Kermit has been told to "set file type binary" and "send *.macbinary", Mac Kermit has MacBinary selected in the File Settings dialog), only the first arriving file is treated as MacBinary. After that, Mac Kermit forgets that it is in MacBinary mode. Workaround: send only one file at a time to Mac Kermit in MacBinary mode. Sometimes (maybe always) MacBinary downloads, particularly of long MacBinary files, result in errors like: Zclose(): MacBinary botched: this file should NOT still be open Resource fork size mismatch... Data fork size mismatch... too many NAKs In general, the code that handles incoming MacBinary files needs a lot of work. There is no way to set the ID signature (associated application) of an incoming file. Text files (mode = text) all become TeachText documents. When "binary / resource" is chosen for downloads, Mac Kermit makes the file type APPL (an application). The ID signature is set automatically when downloading in MacBinary mode (when it works!). There should be a way to specify the ID for an incoming file. (NOTE: MPW C 3.2 has a new function for doing this: fsetfileinfo() -- see MPW release notes.) If an Appleshare or Novell file server disk goes away (e.g. because the connection dropped) in the middle of a file transfer, The Mac hangs and has to be rebooted with the programmer button. In the file-send dialog box, there is no way to mark selected files for sending (e.g. shift-click, shift-drag). You can only send a single file, or else all the files in a folder. (But you can use MSEND in the command window to send a selected list of files.) However, since the Command Window DIRECTORY command is not implemented, there is no way to get a file list. The file transfer display / dialog-box needs a button for "retransmit the last packet" to let the user wake up a transfer that seems to be stuck. Maybe also a "send XON" button to let the user try to break an XOFF deadlock (which is supposed to happen automatically after 8 seconds anyway). SET FILE DISPLAY NONE should be able to disable the file transfer display window altogether, for "silent running", for example, for people who want to incorporate Kermit into their BBS software. The "find a new unique filename" algorithm is not great. It starts with the filename, if it exists, appends ".0", then ".1", etc, up to ".99". However, this doesn't guarantee that the newly created version will be higher than all the others. If .1 and .3 exist, Mac Kermit will create .2. The File Settings menu selection "Supersede existing files of the same name" doesn't seem to work. But SET FILE COLLISION (in the command window) works correctly (except for APPEND, UPDATE, and DISCARD, which are not implemented). When a REMOTE command is given from the command window, the Response window does not pop up to show the response. However, if you select the Response window in the Window menu, you'll see the server's responses have been collected there. You can't cut or copy from the Response Window and paste into other windows. It would also be nice if the file transfer display showed the other info, as in C-Kermit's fullscreen file transfer display -- character sets, estimated time to completion, characters per second, etc. SERVER MODE 1. Mac Kermit server mode in general (NOTE: these haven't been checked recently, maybe they are fixed)... Sending a text file to the Mac Kermit server works fine. Getting a text file from the Mac Kermit server also works fine, except the status screen still says "Receiving". REMOTE SET FILE TYPE BINARY, sent by a client to the Mac Kermit server, works. Binary file transfers in both directions work fine. There is, of course, no way for the client to put the Mac Kermit server into MacBinary mode, because as far as the Kermit protocol is concerned, the only transfer modes are text and binary. REMOTE DIRECTORY sent to the Mac Kermit server, doesn't work (It sends back an E-packet saying "Can't list directory"). FINISH works, the file transfer status screen disappears, but the File Transfer top-level menu item remains highlighted. 2. MacBinary transfers with the Mac Kermit server. OK, now we want to transfer files in MacBinary mode with a Mac Kermit server. We click on MacBinary in the File Settings menu, then put Mac Kermit in server mode. GETting a file from the Mac Kermit server: screen display says "Receiving" (instead of sending). Giving a REMOTE HELP command to the server apparently makes it forget it's in MacBinary mode. A subsequent GET has Mac Kermit sending the data fork only (empty), in binary mode. Putting it back in MacBinary mode manually, and a subsequent GET, gives checksum errors. Then Mac Kermit forgets it's in MacBinary mode again. In general, there seems to be a lot of problems with Mac Kermit remembering that it's in MacBinary mode. This is no doubt because Mac Kermit keeps its own private variables (one for text / binary / macbinary, another for data / resource / both fork(s)) instead of using Kermit's built-in "binary" variable. This needs to be reworked. MAC KERMIT CHARACTER SET AND FONT BUGS An official, invertible translation between ISO Latin-1 and Apple Quickdraw does not exist. Our own Extended Mac Latin character set is used in this version. This set is specified in the separate file, ckmker.fon, which also discusses the other character-set and font-related issues. Mac Kermit's terminal emulator does not respond to host-generated escape sequences to designate selected character sets to G0..G3, for example ESC - A to designate Latin-1 to G1. Mac Kermit should support: ESC ( Designates 94-byte character set to G0 ESC ) Designates 94-byte character set to G1 ESC * Designates 94-byte character set to G2 ESC + Designates 94-byte character set to G3 ESC - Designates 96-byte character set to G1 ESC . Designates 96-byte character set to G2 ESC / Designates 96-byte character set to G3 where the are: Size Character-Set A 96 ISO Latin-1 B 94 ASCII (default in G0, G1) 0 94 DEC Special Graphics 1 94/96 VT100 Alternate ROM 2 94 DEC Special Graphics %5 94 DEC Supplemental Graphics = DEC Multinational Char Set > 94 DEC Technical There is no mechanism for the user to explicitly designate character sets to G0..G3. See menu design in the Appendix for how to do this. There is presently no way for users to specify their own character-encoding translations. The translations for file transfer and terminal emulation are built in to Kermit. A point size of 7 is listed in the Font menu, but it can't be selected. Mac Kermit's built-in VT100 terminal font does not scale well to any size other than 9. Mac Kermit's VT100 font has entirely different character codes than all the other Mac fonts for the "special" (8-bit) characters. If you switch to, say, Courier for terminal emulation, all the special characters (accented letters, etc) come out wrong. Furthermore, Apple character encodings (like Quickdraw) lack certain characters (e.g. Icelandic Thorn and Eth) needed for Latin-1. The VT100 font is built into Mac Kermit, which means it can't be hooked in to Key Caps, so you can never find out what keys to type in order to send special characters. This also seems to cause some problems with SuitCase and friends. The font should be externalized, but then it becomes difficult to install Mac Kermit -- you can't just stick in the disk and run it, you have to install fonts first. It would be best to keep the font defined in Mac Kermit, but also have an external copy for the benefit of Key Caps. You can use the Mac Latin font (which is supplied on the diskette) in Mac Kermit, but it won't do any good because the software itself is not coded to do the appropriate translations. However, if you download text files using the Latin-1 / MacLatin translation, then you can use the MacLatin font to look at these files and all the characters will be right. The VT100 font doesn't print correctly (accented characters, VT100 special and technical characters, etc). See the separate file, ckmker.fon (Mac Latin Doc on the diskette), for a detailed description of these problems and a proposed solution. Proportional fonts can be selected during terminal emulation, but of course they don't look right because terminals use fixed-width fonts. Maybe proportional characters could be displayed within fixed-size boxes. Or maybe Kermit should only allow monospace fonts in its font menu. Selecting a different font in the Terminal window tends to change the font used in other windows to a random font -- probably not the one that was there before, and not the one you chose. Selecting the Chicago font doesn't work at all (a mystery). Another font anomoly... PROBLEM: [A user with] Mac Kermit 0.99(188), display is using 24 point Palatino. I used ResEdit and looked inside your FONT resource and found that the 9 point VT100 font has an ID of 16393. As it turns out, her 24 point Palatino has the same id. I gave the 24 point Palatino a different ID and restarted her Mac but the problem persists. She has a Mac IIfx running System 7.0.1. This wasn't a problem until recently when someone "turned on" the password feature of her After Dark and didn't tell her the password. I had to crash the Mac and reboot with extensions off and reinstalled After Dark. Upon restarting after the reinstall of After Dark, the Mac crashed and refused to startup again. I resinstalled System 7.01 and the Mac boots fine but now we've got this font problem. SUGGESTED SOLUTION: 0. Recheck Palatino to make sure the change stuck. 1. Drag the Palatino fonts out of the System. 2. Copy the vt100 font from Kermit into the System. 3. Drag Palatino back into the System. This should assign new id's to Palatino RESOLUTION: Oddly, that didn't work. The Palatino did change (to ID 1777). I trashed the Palatino fonts, copied the VT100 font and reinstalled the Palatino fonts. The Palatino fonts now have id's in the 5000 range. I still got 24 point Palatino on the display. I then changed the VT100 font to ID 16666 and that did the trick. KERMIT displays fine now. USING CYRILLIC CHARACTER SETS IN TERMINAL EMULATION [Note: The following user submission only addresses how to display Cyrillic characters, not how to enter them on the keyboard.] Date: Thu, 12 May 1994 15:24:44 -0400 (EDT) From: Steven Lee Solnick Several months ago we corresponded on how to read KOI-8 encoded text (from the Relcom bulletin boards on Usenet) on a Mac with MacKermit. Turns out the missing link is a file (koi7-koi8.hqx, or something like that) available in the Font directory on the Info-Mac archives. It contains the necessary font suitcase for KOI-7 and KOI-8 text. With that in the system, relcom text can be read with the following steps: - Terminal Set to "Accept 8-bit characters" - Character Set to ISO Latin 1 (won't work on the DEC setting) - Change font to KOI8-Russian, 9 pt. This displays both English and Cyrillic characters. This procedure works for both rn (through UNIX) AND on the Usenet menus. APPENDIX I: Excerpts from Info-Kermit Digest V16 #4 Date: Sun, 18 Oct 1992 23:19:55 -0700 (PDT) From: Les Ferch Subject: MacKermit on Mac Plus I noticed a couple of minor problems with MacKermit on a Mac Plus. 1. Using "Set modifiers..." I set Option to act as Ctrl. However, it does not work. To get a Ctrl key, I have to set Command to act as Ctrl and turn off Menu Keys. It would be nice to be able to keep Menu Keys and use Option as Ctrl. [Ed. - To use the Option key as a Ctrl key, you have to check the Opt box on the left side of the Set Modifiers dialog, and you also have to check both Unmodify and Ctrl on the right side, in the same row. See ckmker.bwr.] 2. The File menu is longer than the 9" screen. This confuses beginners looking for Quit. If Load Settings and Save Settings were moved to the Settings menu, the problem would be solved. [Ed. - A well-known problem. The menus need a lot of work.] ------------------------------ Date: Tue, 20 Oct 92 10:29:40 EST From: Howie Richburg Organization: State University of New York - Central Administration Subject: Re: MacKermit? Maybe I am doing something wrong. Under settings I choose key settings. The scan codes I define such as {27}3, when executed are passed through to the terminal screen as #27'3 for example and not transmitted. Any ideas? [Ed. - Presently, the backslash notation in Mac Kermit's key definitions only accepts octal (base 8) numbers, and no provision is made for grouping. Suppose you want to define a key to send ESC followed by the letter A. In MS-DOS Kermit or C-Kermit, you would express this as \27A, \o33A, or \x1BA. In Mac Kermit, it must be \33A. Now suppose you want to send ESC followed by the digit 3. You can't write \273, because there would be no way to tell where the backslash code ended and the literal text began. In MS-DOS or C-Kermit, you can write \{27}3, to separate the 27 from the 3. Mac Kermit doesn't support this type of notation, so you have to write \33\63 (where 63 is the octal value of the ASCII code for the character "3"), and so on until you reach the first non-numeric character or the end of the definition. Hopefully, a future release of Mac Kermit will support the same types of notation as MS-DOS Kermit and C-Kermit.] Do you think MacKermit is stable enough to use for a Mac Powerbook running System 7? [Ed. - We have received mixed reviews. The main difficulty with Mac Kermit under System 7 actually has nothing to do with System 7 per se, but rather with the fact that Macs that have System 7 also tend to be loaded with lots of INITs. Macs with all their INITs are becoming even more dangerous for communication software than PCs loaded with TSRs! We have discovered that most INITs that have anything to do with font management -- Adobe Type Manager, SuitCase, TrueType, etc -- can interfere with Mac Kermit to various degrees, ranging from fractured screens to Mac Kermit or even system bombs. This probably happens because Mac Kermit uses its own internal font for terminal emulation. We know the solution to this problem -- remove the internal font and make an external font suitable for VT320 emulation -- but it is taking a long time to accomplish it.] [Ed again - About the Powerbook. Mac Kermit works as well on the Powerbook as it works on any other Mac, except for one obvious limitation (bug). The Powerbook does not normally come with a modem port, only a printer port. Thus you have to choose the printer port in the Communications Settings menu, which works. So far so good. But the port selection is not saved when you Save Settings. So you always have to open the communications menu and select the printer port every time you run Kermit on the Powerbook. This should be fixed soon.] In addition the Powerbook will be used to dial into a 3270 protocol converter to access our IBM host. It will therefore require that certain key combinations submit specific codes to emulate PF keys. The reason I ask is because I have no luck transmitting codes to emulate the PF keys. [Ed. - This is an extremely common question, but it does not have a general answer. Here's the story: an IBM mainframe 3270 terminal has row upon row of "PF" keys that ordinary terminals don't have. The operation of these keys is internal to the IBM 3270 protocol -- they don't send characters, they send signals or messages, or perform certain local functions, etc. A 3270 protocol converter -- such as an IBM 7171 -- lets ordinary ASCII terminals (or programs, like Kermit, that emulate them) interact with mainframe 3270 applications. Data sent from the mainframe to the terminal is converted into (for example) ASCII text intermixed with VT100 escape sequences, so your screen looks right. So far so good. In the other direction, certain control characters or escape sequences coming from your keyboard are interpreted as PF keys. The problem is, no two protocol converters, no two protocol-converter terminal-type configurations, no two sites, have the same idea of exactly which control characters or escape sequences should correspond to which PF keys. WE CAN'T ANSWER THAT QUESTION. You have to go to your IBM mainframe or IBM networking administrator and find out: for a particular terminal type (say VT100), what characters or sequences must the terminal or emulator send to simulate EACH of: the PF1 through PF24 keys; the PA1 through PA3 keys; the newline key, the cursor keys, backtab, the editing keys, the Attention key, etc etc. Once you have the table of 30 keys and their values, you can decide which keys on your Mac should correspond to which 3270 terminal keys, and then assign the corresponding character or escape sequence to each one in a Set Key Macros dialog -- a long and tedious exercise, which is best done once at each site centrally. A Mac Kermit 3270 settings file is created, put on a file server, or copied onto diskette or and passed around. In a future release, we hope to support plain-text key settings files like MS-DOS Kermit or C-Kermit.] ------------------------------ Date: Tue, 20 Oct 92 16:57:53 +0100 From: johnen@GEI-Aachen.de (Uwe Johnen) Subject: Kermit on Mac I was very amused that I can use my Apple Powerbook as a terminal (vt100) over the V24 modem port. But using Word Perfect on our VAX I was searching for the function keys, which I have to use while working with WP. If you have any idea where they are please let me know. I thing I tried everything. Which one tried I not ? [Ed. - Here is another case where you must go through the long and laborious process of making many, many key assignments. VAX WordPerfect assignments have already been done for MS-DOS Kermit in the file kermit/a/msiwp3.ini, which contains 126 SET KEY commands! Unfortunately: (a) the keyboard scan codes of the Macintosh are different from those of the PC, and (b) there is not yet a way to import textual SET KEY commands into Mac Kermit. As noted above, hopefully there will be a textual SET KEY command in a forthcoming release.] ------------------------------ Date: Thu, 29 Oct 92 08:47:23 PST From: John Holland Subject: Re: 0.99(97) Bug Report I reported some problems with Mac Kermit 0.99(97). Since then I have obtained 183, and later 184, from watsun.cc.columbia.edu. I now use Mac Kermit as my terminal emulator of choice in my daily work, connected to a mainframe at 9600 baud, using a Mac Plus. Commercial products, like Microphone and White Knight, seem to be assuming a slower connection and do not refresh the screen as quickly as I would like. Kermit refreshes the screen quickly, and allows me to copy and paste and to move the cursor around with the mouse (and type without having to wait for the cursor to arrive at its destination). One of the problems I noted before is no longer a problem. I couldn't save settings without a system bomb. No problem now. However, if I set Mouse -> Arrow Keys in Terminal... under Settings, I still can't turn it off. [Ed. - Sure enough, it's a bug. The X disappears from the check box, but the feature is not turned off. If you bring back the Terminal Settings screen, the box is checked again.] A new problem is related to fonts. I use Courier 10 point. When the text I am working on is bolded and I delete characters from the middle of the line, pulling the rest of the line in, a trail of dots is sometimes left. I demonstrated this to myself by typing a row of bold WWWWWWs, then deleting the leftmost one a few times. The rightmost pixel in the righmost character remains on the screen. This is a cosmetic bug which I am happily living with, given the other benefits of Kermit. [Ed. - Coexistence with fonts and font managers, and other font related problems (of which the one you list is a very minor example), are perhaps Mac Kermit's biggest problem at present. It is described -- and a solution proposed -- in the files kermit/sw/ckmker.bwr and kermit/sw/ckmker.fon.] ------------------------------ OTHER USER REPORTS From: JJSTEP00@ukcc.uky.edu (Jason Stephenson) Newsgroups: comp.protocols.kermit.misc Subject: Re: Hangup on receive Date: Mon, 06 Nov 95 13:12:59 EST Organization: The University of Kentucky Answering my question (about file transfer failures)... In article <47de00$q7a@gateway.dircsa.org.au> arthur@gateway.dircsa.org.au (Arthur Marsh) writes: > >Have you tried getting your modem to ignore DTR (&D0), and consulted with Mac >modem experts on settings, hardware-handshaking cables and the like? I solved this problem over the weekend. It involves turning off the "Teleport" INIT that came with my modem. Seems it does some strange things when the serial port opens. I still have other problems with downloading but have narrowed that down to bad phone lines and crappy modems on the other end of the connection. Seems the University has some 9600 baud modems on the verge of expiration. Z-Modem doesn't like downloading from other servers when I dial in to the same modem pool. Kermit doesn't work, either, for file transfers if I get a bad modem. Works great in terminal emulation, though. [Ed. That's strange. Could it be a transparency problem with the terminal server or modem? Are you using any control-character unprefixing? If so, do Kermit transfers work when you tell the file sender to "set control prefix all"?] I do have one other comment to add concerning the internals of Mac-Kermit: I was downloading a 4 Meg file the other day (actually got a decent connection) and when I had about ten minutes of transfer left, my machine locked up. I diagnosed the problem to be memory related (stack running into the heap). This kind of thing happens when to many static variables collide with too many calls to malloc. The short term solution is to give MacKermit a huge (over 1 Meg) partition when you plan to download large files. The long term soution is to change the memory allocation scheme in the ckc*.c file[s] (don't remember which one) to work with the idiosyncracies of Macintosh memory management. But that would mean "more #ifdefs galore," to borrow a line from our fearless leader, FDC. [Ed. - Wheee. Aren't malloc's supposed to safe with respect to stack and heap? Or at least guaranteed to fail if they can't get the expected memory? Any idea what to put in the #ifdef's?] ------------------------------ APPENDIX II: MENU DESIGN (DRAFT!) Top-level menu: ------------------------------------------------------------ File Edit Settings Special Transfer Window ------------------------------------------------------------ File ------------------------------ New Open... Close Save Save As... ------------------------------ Take Command File... Take Commands from Window ------------------------------ Page Setup... Print Screen... Print Selection... Log Session to Printer... Cancel Printing (Printer buffer status?) ------------------------------ Chain to Application... Quit ------------------------------ The Page Setup dialog should include a section that tells what to do with host-initiated printing (transparent print or autoprint): ------------------------------ (x) Send to printer ( ) Save in Printer window ( ) Save in file... ( ) Discard ------------------------------ Edit ------------------------------ Undo ------------------------------ Cut Copy Paste Clear Select All ------------------------------ Settings ------------------------------ Load Settings... Save Settings... ------------------------------ Communications... Kermit Protocol... File Transfer Defaults... File Transfer Character Sets... Terminal Characteristics... Terminal Character Set... ------------------------------ *-Shift-1..*-Shift-9 Active Menu *-Keys Active Key Macros... Key Modifiers... ------------------------------ Here is the terminal character sets dialog. It's sort of an ISO 2022 tutorial. The first section "designates" character sets to graphics areas G0..G3. Only one radio button can be pushed in each column, but multiple buttons can be pushed in a row. A 96-byte character set (Latin-1 and DEC MCS are the only ones) may not be designated to G0 (ISO rule). If Latin-1 or DEC MCS are chosen, G0 is automatically forced to ASCII. The second section "invokes" the selected graphics areas to GL and GR. Only one button can pushed in a row. ------------------------------------------------------------------- Terminal Character Sets G0 G1 G2 G3 US ASCII (x) ( ) ( ) ( ) ISO 8859-1 Latin-1 (x) ( ) ( ) <-- Note: No G0 here (dim) DEC Special Graphics ( ) ( ) (x) ( ) DEC Technical ( ) ( ) ( ) (x) DEC Multinational ( ) ( ) ( ) <-- Note: No G0 here (dim) British/UK ( ) ( ) ( ) ( ) Canadian French ( ) ( ) ( ) ( ) Dutch ( ) ( ) ( ) ( ) Finnish ( ) ( ) ( ) ( ) French ( ) ( ) ( ) ( ) German ( ) ( ) ( ) ( ) Italian ( ) ( ) ( ) ( ) Norwegian/Danish ( ) ( ) ( ) ( ) Portuguese ( ) ( ) ( ) ( ) Spanish ( ) ( ) ( ) ( ) Swedish ( ) ( ) ( ) ( ) Swiss ( ) ( ) ( ) ( ) ------------------------------------------------------------------- Graphics Left (GL): (x) ( ) ( ) ( ) Graphics Right (GR): ( ) (x) ( ) ( ) ------------------------------------------------------------------- For file transfer character sets, the "Language rules" apply only if ASCII is checked in one (not zero or two) of the first two columns), otherwise the language rules buttons should be dim. ------------------------------------------------------------------- File Transfer Character Sets File Character Set Transfer Character Set Language rules (x) Apple Quickdraw (x) Transparent (x) None ( ) ASCII ( ) ASCII ( ) Dutch ( ) ISO Latin-1 ( ) ISO Latin-1 ( ) French ( ) German ( ) Icelandic ( ) Scandinavian ------------------------------------------------------------------- THE COMMUNICATIONS SETTINGS DIALOG Here we need a couple changes in terminology: 1. "Baud Rate" is "incorrect". It should say "Transmission speed" or "Transmission Rate", or (if that's too long), simply "Speed". 2. "Drop DTR on Quit" is obscure. It should say "Hangup on Quit". FILE SETTINGS DIALOG: ------------------------------------------------------------------- ( ) Attended: dialog on each file received (x) Unattended: with the following defaults: File Names: (x) Converted ( ) Literal Filename Collisions: (x) Backup ( ) Append ( ) Discard ( ) Overwrite ( ) Rename ( ) Update [ ] Keep partially received files Transfer Mode: (x) Text Fork: (x) Data ( ) Binary ( ) Resource ( ) MacBinary ------------------------------------------------------------------- THE TERMINAL SETTINGS DIALOG Change "[ ] Accept 8 Bit Characters" to: Character size: (x) 7 bits ( ) 8 bits THE PROTOCOL SETTINGS DIALOG (OK) THE SPECIAL MENU: Special ------------------------------ Hangup Send Break Send Long Break Send XON Reset Terminal ------------------------------ Log Session... Dump Screen... Log Transactions... Log Packets... Log Debugging... Call Debugger... (dim if no debugger loaded) ------------------------------ THE TRANSFER (File Transfer) MENU: Transfer ------------------------------ Send file... Receive file... Get file from server... ------------------------------ Show statistics ------------------------------ Change directory ------------------------------ Change remote directory Delete remote file... List remote files... Remote help Remote host command... Remote Kermit command... Remote space... Remote type... Remote who... Send file to server for printing... ------------------------------ Finish server Logout server ------------------------------ Enter server mode ------------------------------ THE WINDOW MENU Lists the names of the windows. It should be modified to check or highlight the currently active window. Assuming that font changes can be made to work in all windows, we should move the Font item to here, and have it invoke a submenu, applying to the current (checked) window (the whole window? A selection within a window?) (We have to move the Font menu because there isn't enough room for 7 menu items in the top-level menu.) For example: Window ------------------------------ X Terminal Window (X = checked) Command Window Response Window Untitled-1 ------------------------------ Font -> ------------------------------ ------------------------------ 9-point 10-point 12-point 14-point 18-point ------------------------------ Avant Garde Bartholemew Bookman Chicago (etc) ------------------------------ APPENDIX III: SOURCE CODE Macintosh Kermit is written in C. The modules whose names start with "ckm" are specific to the Macintosh. These can be C source code (.c), header files for #include (.h), or resource files (.r). The makefile is ckmker.mak, which you should rename to kermit.make for use in MPW. The modules whose names start with "ckc" or "cku" are shared with other C-Kermit implementations: UNIX, VMS, OS/2, Amiga, OS-9, etc. This version of Mac Kermit can be built using only MPW C 3.2 Final (NOT 3.0 or 3.1, and not any Beta version of 3.2) on the Macintosh. MPW 3.2 is required because Mac Kermit needs more than 32K of uninitialized global data space, and the limit in MPW 3.1 and earlier is 32K. It is probably not possible to reduce the size of the uninitialized global data area by more than about 3-4 more K (by converting array declarations to pointers and then mallocing the space at runtime), so we can't get below 32K, so therefore we must use the new MPW C 3.2 "32-bit everything" model ("-model far"). NOTE TO DEVELOPERS: References to the Pattern data type have to be changed to fit MPW 3.2's new redefinition (which, they say, was done to eliminate crashes on 68000-based CPUs). See quickdraw.h and Appendix J of the 3.2 Release Notes. When this is done, remove "-d dangerousPattern" from the C command line in the makefile. As of edit 190, Mac Kermit should also be buildable under Think C 5.0; see the ckmmak.hlp file for details. However, there are still a few kinks to be worked out. Many of the source files contain 8-bit characters. Make sure you have transferred them to your Mac correctly. Use text mode, but make sure character translation is turned off. Also, many of the ckm*.* files have lines longer than 80, which can prevent them from being transferred via certain kinds of e-mail (such as BITNET). NOTE TO DEVELOPERS: These source files need to be edited to ensure that all lines are less than 80 characters wide (after tab expansion), and 8-bit characters are all converted to "\ooo" ASCII octal notation (I tried using the \266 (delta) line continuation character in the kermit.make file to break up long lines, but it didn't seem to work.) The final release source code should contain only 7-bit ASCII characters, and no lines longer than 80. Btw, there is something in the MPW 3.2 release notes that says how signal(SIGINT,xxx) can be used to catch "Command-.". (End of CKMKER.BWR)