|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T c
Length: 12373 (0x3055)
Types: TextFile
Names: »ckmker.bwr«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦3da672b63⟧ »EurOpenD3/misc/kermit.tar.Z«
└─⟦126dd3ca0⟧
└─⟦this⟧ »ckmker.bwr«
Date: Wed 8 Jun 88 21:43:05-EDT
From: Frank da Cruz <SY.FDC@CU20B.CC.COLUMBIA.EDU>
Subject: Mac Kermit
To: paul@TUT.CIS.OHIO-STATE.EDU
I got a report that it doesn't compile under MPW 2.0.2, which is the latest
release, and that a major reworking will be required for MPW 3.0, sigh...
What version of MPW are you using? I also heard that the file ckmkr2.r was
missing. Did you send it to me? - Frank
------------------------------
Date: Thu, 9 Jun 88 10:19:42 EDT
From: paul@morganucodon.cis.ohio-state.edu (Paul Placeway)
To: SY.FDC@CU20B.CC.COLUMBIA.EDU
Subject: Mac Kermit
Reply-To: paul@tut.cis.ohio-state.edu
D*mn. Maybe I'll port it to LightSpeed C and be done with it; LSC
doesn't seem to change radically with each rev. Mumble...
I'm using MPW 2.0d4 (developer pre-release), which probably explains
the incompatibility. We have been trying to get a real MPW for about
a year, with no real success (LSC is sounding better and better...)
I thought you picked up ckmkr2.r, but since it's short, here it is:
--P
[Ed. - Moved to its rightful place...]
------------------------------
Date: Thu, 9 Jun 88 10:49:46 EDT
From: Charlie C. Kim <cck@cunixc.cc.columbia.edu>
To: paul@tut.cis.ohio-state.edu
Subject: Re: Mac Kermit
APDA has MPW 2.0.2 C as an upgrade... I think it was 100 dollars.
The only thing that caused problems (as I remember) was the fact that
you had "environs.h" which isn't there anymore -- it's included in
systypes.h (i believe). I'll poke in the resource file and see if a
working copy comes out.
The main changes, supposed, will make mpw "more" compatible with other
Cs. Basically (re: a posting on comp.sys.mac.programmers), the trap
names will change so pascal mode is "mixed case" and c mode is all
lower case. There will be a set of Canon directives to help people
convert. I noticed you used the c mode, but if you watch out for the
int=2 bytes in lsc, and int=4 bytes in mpw (by using defines or always
using for short=2, long=4 bytes in both), then your LSC port should
work with MPW 3.0 without too much more work.
Just don't port it to megamax :-)
Charlie
------------------------------
Date: Thu, 9 Jun 88 11:00:52 EDT
From: Charlie C. Kim <cck@cunixc.cc.columbia.edu>
To: paul@morganucodon.cis.ohio-state.edu
Subject: macker
Two other problems.
First, link tries to link in glueenviron.a.o
Second, you used the special characters in ckmker.r (high order bits
on). They should changed to corresponding \ooo format so the files
can be xfered properly.
Seems to work (launches) other than that.
Charlie
------------------------------
Date: Thu, 9 Jun 88 11:11:49 EDT
From: paul@morganucodon.cis.ohio-state.edu (Paul Placeway)
To: cck@cunixc.cc.columbia.edu
Cc: sy.fdc@cu20b.cc.columbia.edu
Subject: macker
Reply-To: paul@tut.cis.ohio-state.edu
Thanks. I'll go and change things...
I've been waiting for OSU to send the $100 (a trivial amount) to APDA,
but at the rate things are going I might as well buy it myself. 8-(
If MPW 3.0 is supposed to be more compatible with everyone else, I may
very well take a stab at a port...
I don't know what real MPW links in to get the glueenviron.a.o stuff.
If it is allready in the normal library, fine. If not, the other
MacKermit hackers will need to know.
whatever...
--P
------------------------------
Date: Tue, 14 Jun 88 14:00:58 EDT
From: Dick Atlee <ATLEE%UMDC.BITNET@CUVMA.CC.COLUMBIA.EDU>
Subject: MacKermit
To: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
The mouse feature does not work on our system. After a go-round about Ted
Medin's Apple Kermit in VT100 mode, which worked on some machines and not on
others, we found a problem with the cursor keys. The VT100 has a set/reset
mode governing the cursor keys -- when Cursor Key Mode is RESET (default) the
sequence is ESC [ A/B/C/D, while when SET it is ESC O A/B/C/D. Our IBM 7171
here is programmed to RESET this mode as part of the initialization and then
expect the ESC-[ pattern from the cursor keys. Ted's Kermit was not responding
properly to the RESET command. If the mouse driver for MacKermit is not
sensitive to the RESET command, and sends the ESC-O pattern, it won't work on
a lot of machines. Any info on this?
------------------------------
Date: Sun, 19 Jun 88 21:53:42 +0100
From: Eamonn McManus <emcmanus@csvax1.tcd.ie>
Subject: Bug in Macintosh Kermit Version 0.9(40)
Keywords: MacKermit 0.9(40)
> This is to announce Macintosh Kermit 0.9(40), by Paul Placeway of Ohio State
> University and Matthias Aebi of ECOFIN Research and Consulting, Ltd, Zuerich.
> MacKermit 0.9(40) runs on all Macs except the 128K original.
There is a trivial but annoying bug in Mac Kermit 0.9(40), as released to
comp.binaries.mac on Usenet. (The version says it is Kermit version 0.9(40),
04/05/88 11:51.) The default settings for tab stops place the last one at
column 71 (zero-origin) rather than 72 as it should be. Most of the time
this doesn't show up (which is presumably why the bug hasn't been fixed so
far) but it is quite noticeable in editors like vi that attempt to optimise
cursor motion, frequently by using tabs.
Here is a patch that fixes the bug. The version of ckmcon.c is that from
0.9(36)b4 but I assume it hasn't changed.
*** ckmcon.c.orig Wed Jun 8 17:03:27 1988
--- ckmcon.c Sun Jun 19 20:56:06 1988
***************
*** 85,91
/* (UoR) do tapstops via an array: 0 means no tab, 1 means tab at that column
*/
short tabstops[MAXCOL+1] = {0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,
0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,
! 0,0,0,0,0,0,0,1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1};
#define USA_SET 0 /* (UoR) VT100 character set numbers
*/
#define UK_SET 1
--- 85,91 -----
/* (UoR) do tapstops via an array: 0 means no tab, 1 means tab at that column
*/
short tabstops[MAXCOL+1] = {0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,
0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,
! 0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1};
#define USA_SET 0 /* (UoR) VT100 character set numbers
*/
#define UK_SET 1
Since I don't have the 0.9(40) sources, I've had to patch the binary. This
involves editing block 132(dec) and changing byte 0x19c to a 0, and byte
0x19e to a 1.
Eamonn
------------------------------
(reported by many, and observed to be true...) MacKermit often reports the
block check type to be 0 when sending a file with block check type 1.
------------------------------
Date: Sat, 13 Aug 88 23:44:22 EDT
From: Dick Atlee <ATLEE%UMDC.BITNET@cuvmb.cc.columbia.edu>
Subject: MacKermit bugs
I wrote to Paul a while back about the fact that, while the cursor keys will
respond to a VT100 "reset" command to change their output from ESC-O-x to
ESC-[-x (necessary on our IBM CMS 7171 front end), the mouse will not, making
the mouse useless on our system. He said it was a relatively simple job to fix
it. I'm interested in getting it fixed in time for distribution to incoming
students this September.
While I was preparing settings files for this distribution, I stumbled on
another aspect of bizarre behavior, which, after playing around with a data
monitor, I sent him a copy of on Thursday. I'll pass it along to you, but it
still needs confirmation by someone else....
I have been having trouble using the Option key as an ESC-prefixer. In the
Modifiers setup I have Opt checked for Unmodify with a prefix string of \033.
However, the same problem occurs (ignoring references below to ESC) when the
setting is for Meta with no parity and no prefix.
The ESC prefixing works fine for the majority of the characters on the
keyboard. However, there are 5 exceptions (left column below):
e +
TABLE 1: i ^
Oddball Opt-chars n ~
and "replacements" u ,
` `
(NOTE: the problem I'm about to describe does not happen when the Shift key or
CapsLock key is down, although in both these and the non-shifted cases, the
character produced when the option key is held down is a lower-case character.)
Normally, when you hold down the Option key and type a character, an ESC is
generated, followed by the character. If you type the character twice, you get
ESC <char> ESC <char>, just as you'd expect (I have been checking this with
a data monitor hooked up to the Mac).
However, when you hold down the Option key and type one of the above five
characters, nothing is generated immediately. Subsequent repeats of this
process produce the normal ESC <char> sequence. The fascinating part of the
problem occurs when you press Option followed by anything other than those
five characters. You get a double output of the new character!. For instance,
the following hold:
1 Opt-e produces nothing
2* Opt-e Opt-e produces ESC e
3 Opt-e Opt-a produces ESC a ESC a
4 Opt-e Opt-e Opt-a produces ESC e ESC a ESC a
* In case 2, although only one sequence was produced, an instability
exists which affects the next keypress (as shown in #s 3 and 4)
However, the truly bizarre behavior happens when you use one of the five
oddball Opt-<char>s, followed by a non-Opt-<char>. In most cases, when you
press Option plus one of the characters in Table 1's left-hand column, followed
by a non-Opt character, you produce instead the corresponding right-hand column
character followed by the non-Opt character -- e.g.
Opt-e produces nothing (unstable)
Opt-e b produces +b
The accent grave produces itself as the prefix-character, but this is not
trivial. In all 5 cases, the two resulting characters only appear AFTER both
characters are typed.
Strange though it is, this odd situation begins to look "normal" compared to
what happens when the "second character" is one of a select group. For example:
Opt-e e produces a single ^N
Opt-e o produces a single ^W
Opt-i e produces a single ^p
A fairly exhaustive series of tests shows the following (these have been
arranged so as to show the pattern of increasing values of the resulting
character, although I haven't figured out how the mapping works.......):
Second | ----Initial Opt-char---
Char | e ` i u n
------ | --- --- --- --- ---
A | (K) ^@ (L)
E | ^C
TABLE 2 N | ^D
O | ^E (M)
Results of typing a | ^G ^H ^I ^J ^K
one of the oddball e | ^N ^O ^P ^Q
Opt-chars followed i | ^R ^S ^T ^U
by the indicated n | ^V
second character o | ^W ^X ^Y ^Z ^[
u | ^\ ^] ^^ ^_
` | (``) (``) (``) (``)
~ | (~~) (~~) (~~) (~~) (~~)
space | (+) (`) (^) (,) (~)
tab | ** ** ** ** **
del | ** ** ** ** **
ctl-chr| [^K] [^@] [^^] [^L] [^^]
an empty space indicates the "normal" behavior described above.
() enclose literal characters that appear after both chars have been typed
[] indicate a character which appears with the "second character" following
it after both the Opt and second characters have been typed.
** indicates the second character appears twice, after both the Opt and
second characters have been typed.
This behavior on the part of the oddball characters makes using the Option key
almost useless (ESC-e and ESC-i and ESC-` are all used in our IBM CMS ful-
screen environment). I have mapped these sequences to other keys, but there
are times when it would be nice to have access to them in this form. (By the
way, the keys with direct mapping show none of the above behavior.)
------------------------------