FILE CKMKER.BWR MACINTOSH KERMIT "BEWARE" FILE May 1996
Mac Kermit version: 0.993(192) / C-Kermit 6.0.192 Beta.029
This last file updated: Thu Aug 22 19:20:19 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.
BUT... There have been persistent reports that this version does not
work on the printer port. Cause and cure unknown.
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 ( <ident> Designates 94-byte character set <ident> to G0
ESC ) <ident> Designates 94-byte character set <ident> to G1
ESC * <ident> Designates 94-byte character set <ident> to G2
ESC + <ident> Designates 94-byte character set <ident> to G3
ESC - <ident> Designates 96-byte character set <ident> to G1
ESC . <ident> Designates 96-byte character set <ident> to G2
ESC / <ident> Designates 96-byte character set <ident> to G3
where the <idents> are:
<ident> 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 <sls27@columbia.edu>
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 <ferch@ucs.ubc.ca>
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 <RICHBUHJ%SNYCENVM@CUVMB.CC.COLUMBIA.EDU>
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 <ZZHOLAND@UVVM.UVic.CA>
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)