Date: 2 JAN 86 21:02-MST From: JRD@USU Subject: Quick note vis MS Kermit. One small comment on this version of Kermit is that in the confusion of sending stuff hither and yon I apparently did both Kermit> Log Prn (OK by itself), and Control-PrtSc (ditto) while within VMS Mail. My printer went into grahpics mode and slept hence forth. Seems like both VMS and double printing is not a good combination. Mail does bad things by itself due to the escape sequences emitted, but double printing certainly is bad news for unknown reasons. Joe Doupnik JRD on Bitnet node USU ------------------------------ Date: Fri 3 Jan 86 11:39:18-EST From: Frank da Cruz Subject: jrd/2 I've been playing with it all morning (on a Rainbow) and have found nothing wrong of any consequence. But there are a few minor things perhaps worth mentioning: . As long as you let C stand for Connect, how about S for Send and R for Receive? . I finally got around to digging up the right cables to try out server mode. Nice! But, as you warn, also dangerous. A surprising number of functions will hang the server -- REMOTE SPACE, for instance, wouldn't work for the longest time, until I finally realized I should try it interactively -- turns out it was asking a question ("Repair your disk for you (Y/N)?")... Even something innocent like REMOTE HOST DATE (I forgot that DOS DATE always asks, unlike Unix date)... . The server's screen gets stuff written on it occasionally, obviously by whatever DOS program is being invoked. CHKDSK makes the cursor go down a couple lines... REMOTE DIRECTORY FOO makes the message "File not found" appear on the screen if FOO does not exist. Obviously the programs' fault, but potentially annoying to someone who's running TopView or some similar shell, and expects the server to remain silent. Nothing much to do about this besides fixing the offending programs or DOS itself, I guess. . When conversing with DOS through the back port (CTTY COM1 or whatever), Kermit works mostly just fine (after you give the "SET REMOTE ON" command, of course), but with a couple minor glitches -- if you give the SERVER command, it tries to clear the screen, which of course it can't possibly know how to do since it's talking to a unknown kind of terminal. Also, for some reason, ^U behaves strangely -- seems to move the left margin one space to the right until the next carriage return is typed, so the prompt looks like "KKermit-MS>". . Speaking of running Kermit in "remote mode" -- I thought I'd try something cute, and gave the CONNECT command. Of course, the line that it's connecting on is the same line as its controlling terminal -- I expected the first character I typed would go bouncing back and forth forever. I don't know what actually happened; the system hung. It might be a good idea to disallow strictly local-mode commands like GET, CONNECT, BYE, FINISH, etc, if the remote flag is on. All minor things. I guess the worst is the frequency and unpredicability with which DOS commands ask the user for input, which really makes the REMOTE HOST and REMOTE SPACE commands almost too dangerous to use. I don't suppose there's any way for Kermit to trap when this happens (is there such a thing as a keyboard input request interrupt? Or maybe set a timer interrupt when invoking DOS commands, if there is such a thing?)... - Frank ------------------------------ Date: Wed 8 Jan 86 10:58:39-EST From: Frank da Cruz Subject: ^L Control-L at Kermit-MS> command leverl doesn't clear the screen and enter the command any more -- just echoes a space. ------------------------------ Date: Wed 8 Jan 86 15:58:39-EST From: Frank da Cruz Subject: Bad bug??? Somebody called with the strangest report -- I asked them to get more details and call back. But while you're digging through the code, you might want to be on the lookout for it. It happens with basic pre-jrd 2.28 (and later?). The user gives a send command to the mainframe Kermit, escapes back, gives a receive command to MS-Kermit (in this case on a PC/XT). The S and F packets are done successfully and then poof! all files in the XT's current directory are deleted. Now, this has never happened to me or anyone else I ever heard of and it doesn't happen to the person who called, EXCEPT when the remote system is a Perkin-Elmer mini. This seems to suggest that P-E Kermit puts something really strange in its F (or maybe D) packets that exercises some really obscure bug in MS-Kermit, probably in the MSSFIL module. The guy says he can reproduce it at will -- it happens every time. Wierd... - Frank ------------------------------ Date: Wed 8 Jan 86 16:59:55-EST From: Frank da Cruz Subject: Another bad bug I just tried jrd/2 on an original, old-motherboard IBM PC running DOS 2.00. It works fine, except -- as the guy with the custom ROM reported -- it simply does not transmit characters, either in connect mode, or if you try to send a file. This version was assembled from your stuff on an AT running DOS 3.10, MASM 1.27 (no switches) and LINK 2.30 (no switches). The .EXE file runs perfectly on the AT. On the PC, it starts up fine, but it just won't communicate (verified from watching modem lights). Exiting from jrd/2 and running an old Kermit works fine, running jrd/2 again gives the same symptom. The PC in question is totally vanilla, no add-on boards. It was, however, running a VDISK driver. Also, I verified the complaint about how the file transfer display mode line is blank except for a ^ in the leftmost position, and a lowercase "s" appears in the upper left corner of the screen. If it happens on this PC, it probably also happens on the Compaq, which apes the original PC to the last detail. Any ideas??? Do you have any original PCs to try it on? Sigh... - Frank (Later -- turns out this is probably a false alarm. A few days later, the same program worked fine on the same PC. If anybody else notices the same thing, please report it!) ------------------------------ Date: 8 JAN 86 16:47-MST From: JRD@USU Subject: Replies on serious bugs dept. Other bugs will be looked at this evening. Joe Doupnik Frank, Zapped directories. I have a clue! If the user were in a sub directory and the incoming filename were not accepted at all, the code could use a file name of just '.' (dot). This of course is the current directory file, overwriting of which would give the noted symptoms. "jrd/2" should survive this part because it expects wild cards to be present and thus first asks the o/s "is this filename in use?". If the o/s says yes (and it's a directory) then "jrd/2" should (quotes here) object. pre-jrd would go and recreate the file. ------------------------------ From: Frank da Cruz Subject: jrd/2 To: jrd@USU I've been playing with it all morning (on a Rainbow) and have found nothing wrong of any consequence. But there are a few minor things perhaps worth mentioning: . As long as you let C stand for Connect, how about S for Send and R for Receive? . I finally got around to digging up the right cables to try out server mode. Nice! But, as you warn, also dangerous. A surprising number of functions will hang the server -- REMOTE SPACE, for instance, wouldn't work for the longest time, until I finally realized I should try it interactively -- turns out it was asking a question ("Repair your disk for you (Y/N)?")... Even something innocent like REMOTE HOST DATE (I forgot that DOS DATE always asks, unlike Unix date)... . The server's screen gets stuff written on it occasionally, obviously by whatever DOS program is being invoked. CHKDSK makes the cursor go down a couple lines... REMOTE DIRECTORY FOO makes the message "File not found" appear on the screen if FOO does not exist. Obviously the programs' fault, but potentially annoying to someone who's running TopView or some similar shell, and expects the server to remain silent. Nothing much to do about this besides fixing the offending programs or DOS itself, I guess. . When conversing with DOS through the back port (CTTY COM1 or whatever), Kermit works mostly just fine (after you give the "SET REMOTE ON" command, of course), but with a couple minor glitches -- if you give the SERVER command, it tries to clear the screen, which of course it can't possibly know how to do since it's talking to a unknown kind of terminal. Also, for some reason, ^U behaves strangely -- seems to move the left margin one space to the right until the next carriage return is typed, so the prompt looks like "KKermit-MS>". . Speaking of running Kermit in "remote mode" -- I thought I'd try something cute, and gave the CONNECT command. Of course, the line that it's connecting on is the same line as its controlling terminal -- I expected the first character I typed would go bouncing back and forth forever. I don't know what actually happened; the system hung. It might be a good idea to disallow strictly local-mode commands like GET, CONNECT, BYE, FINISH, etc, if the remote flag is on. All minor things. I guess the worst is the frequency and unpredicability with which DOS commands ask the user for input, which really makes the REMOTE HOST and REMOTE SPACE commands almost too dangerous to use. I don't suppose there's any way for Kermit to trap when this happens (is there such a thing as a keyboard input request interrupt? Or maybe set a timer interrupt when invoking DOS commands, if there is such a thing?)... - Frank ------------------------------ Date: 8 JAN 86 22:39-MST From: JRD@USU Subject: Fragmentary reply to current messages. Frank, The *%*&(*^(&) local VAX just killed a long report to you on recent correspondence. Some bugs were fixed, some were speculated upon. A rewrite will have to wait until tomorrow evening. The lack of comms upon entering Connect mode is serious, and I'll try to find a vintage IBM PC around here for local testing too. A quick suggested mod is in file MSXIBM, in prodedure SERINT, move a line and add another like below: mov al,mdeoi ; [19b] ... out intcon1,al ; Send ... POP DS ; move this line from slightly above pop ax STI ; reintroduce this line intret: iret SERINT ENDP Two more quickies: File MSSDEF.H, near the top, has symbol FF misdefined. The affected line should read FF EQU 0CH Only file MSSCMD.ASM looks at this symbol and thus needs rebuilding. Losing all files in a subdirectory when strange filenames arrive is a simple one. The apparent file name was just ".". Thus a "Remote Delete ." command is interpreted by command.com as "delete \*.*". Yes, it's another DOS feature. At least now DOS asks (Are you sure) on the server's screen and waits for an answer; earlier Kermits may have done deletions regardless. Saying the same thing to DOS directly, no Kermit, produces the same mass deletion. I'll put in a filename check to both local and remote DEL commands to trap this sort of thing. Could you pass a message to Steve Devoto asking for a copy of his public domain Map memory program so I can peek at lost children, if any. His address is beyond the scope of my machine's understanding. Ref is mailgram to you dated 7 Jan 86 20:23 GMT. Got to quit now. Joe Doupnik ------------------------------ Date: Mon 13 Jan 86 13:54:27-EST From: Frank da Cruz Subject: Re: Copy. Kermit bug? To: JRD@USU Just found a real bug: Kermit-MS>send foo xxx (sends file "foo" as "xxx") Kermit-MS>send bar (it will now also send "bar" as "xxx" -- the send-as name was not cleared). - Frank ------------------------------ 1-Feb-86 14:47:23-EST,1454;000000000011 Return-Path: Received: from MIT-MULTICS.ARPA by CU20B.COLUMBIA.EDU with TCP; Sat 1 Feb 86 14:47:13-EST Date: Sat, 1 Feb 86 14:28 EST From: "John C. Klensin" Subject: Keyboard definition and MSKERMIT To: info-kermit@CU20B.COLUMBIA.EDU Message-ID: <860201192838.171232@MIT-MULTICS.ARPA> 1) When the file MSIVT1.INI is used to make MSKERMIT look like a VT52 to VMS systems, the scrolling normally associated with the PgUp and PgDown keys becomes unavailable (since those keys are bound to things that get transmitted). Is there any practical way, possibly involving Alt, to have one's cake and eat it too in this area? Same problem presumably applies to Home and End. If there is no other possibility, MSKERMIT maintainers should consider providing up, down, home, and end commands after the escape sequence, as well as under single-key control. 2) For those few internal commands that take two lines (SET KEY is the one of particular interest here), is there any practical way to incorporate the command into a macro definition ("DEFINE" command)?. We seem to switch back and forth a lot between backarrow as backspace hosts and backarrow as del hosts (as well as some other differences). Ideally, we want to have an INI file that has DEFINEs for each of the hosts, but the sticking point seems to be embedding the SET KEY commands in them. Any suggestions? 4-Feb-86 18:56:32-EST,4032;000000000001 Mail-From: SY.FDC created at 4-Feb-86 18:56:29 Date: Tue 4 Feb 86 18:56:29-EST From: Frank da Cruz Subject: [Peter DiCamillo : Forwarded mail] To: jrd@USU Message-ID: <12180782463.29.SY.FDC@CU20B.COLUMBIA.EDU> Something about the Compaq & original-motherboard-PC problem... --------------- Received: from CUVMA by CU20B with HASP; 4 Feb 86 18:11:38 EST Received: from BROWNVM(MAILER) by CUVMA (Mailer X1.23a) id 9170; Tue, 04 Feb 86 18:10:57 EST Received: by BROWNVM (Mailer X1.23) id 8193; Tue, 04 Feb 86 18:14:05 EST Date: Tue, 04 Feb 86 18:10:58 EST From: Peter DiCamillo To: INFO-KERMIT@CU20B Subject: Forwarded mail Les Wu asked me to forward the following mail to you, which he has been unable to send directly: ----- Forwarded message # 1: Date: Mon, 13 Jan 86 23:58:54 GMT From: Ljwu@UK.AC.Ucl.Cs To: info-kermit@EDU.COLUMBIA.CU20B, ljwu@UK.AC.Ucl.Cs cc: jrd@bitnet.usu Subject: MS-DOS v2.28 jrd/2 screen problems revisited The problems that have been noted with screen updates in Digests vol 3 #34 and #35 are the same ones that I had originally reported in digest v3 #18 of 12 Sep 85. There seem to have been some sort of BIOS incompatability between the different versions of PC's and compatibles. In fact, from correspondence with other users (generated by first bug report) this problem does not seem to appear across all models of compaq portibles. These problems appeared in the change from v2.27 to v2.28 in MSXIBM.ASM routine putmod. A backout to the code of v2.27 is a partial, though not complete fix for all IBM-like machines. Les J. Wu (ljwu@ucl-cs.arpa) P.S. Sorry for delay in response. Holidays etc. ----- End of forwarded messages (It's me (Frank) again... I unearthed his original message; here it is:) Date: Mon, 9 Sep 85 13:40:34 BST From: Ljwu@ucl-cs.arpa Subject: Behaviour of MS-Kermit 2.28 on a COMPAQ Portable I have encountered a slight bios incompatability between a real IBM PC/XT and a "Compatable" Compaq Portable. In short, MS-Kermit v2.28 with bug fixes as advertised in .BWR file work fine on the XT. The problem, however, is that when sending or receiving files, the Compaq displays a blank inverse video mode line with a single spurious character ('s') above the transfer status displays. The mode line displayed during connection appears normally. The information normally contained in this mode line is rather important in that it gives the user information on how to abort an active file transfer. After some digging, I traced the problem to the routine 'putmod' in MSXIBM.ASM. As I don't have documentation on the bios interfaces I did a simple backout to the putmod routine in version 2.27. Below are the affected lines: Original version 2.28 code: call poscur pop si ; get message back putmo1: lodsb ; get a byte cmp al,'$' ; end of string? je putmo2 mov ah,14 ; write to screen mov bx,07000h ; inverse video, page one int bios jmp putmo1 putmo2: ret ; and return putmod endp Version 2.27 backout: call poscur pop dx ; get message back mov ah,prstr int dos ret putmod endp This fix works fine for the COMPAQ. On a real PC, however, the information line is displayed in normal video. At least this backout provides the user with the necessary information in all cases. Has anybody else experienced this anomolous behaviour with a Compaq or have an explanation for the incompatability? -- Les J. Wu ------- 5-Feb-86 18:17:59-EST,2214;000000000001 Mail-From: SY.FDC created at 5-Feb-86 18:17:56 Date: Wed 5 Feb 86 18:17:55-EST From: Frank da Cruz Subject: [Robert C. Lehman : Kermit 2.29] To: jrd@USU Message-ID: <12181037588.20.SY.FDC@CU20B.COLUMBIA.EDU> Uh oh... Last minute problems, tho it's not totally clear they're Kermit problems or somebody else's. Rob is trying to narrow things down a bit. I asked him to be sure he had configured DESQ View (which I assume is equivalent to TopView in its program interface, but I may be wrong) to know about all Kermit's quirks, like dynamic memory allocation, screen writes, etc... If you can't duplicate this behavior under Windows, I'd say don't worry about it. - Frank --------------- Mail-From: US.RCL created at 5-Feb-86 18:05:06 Date: Wed 5 Feb 86 18:05:06-EST From: Robert C. Lehman Subject: Kermit 2.29 To: sy.fdc@CU20B.COLUMBIA.EDU Message-ID: <12181035254.56.US.RCL@CU20B.COLUMBIA.EDU> Hi Frank, I've played around with Kermit 2.29 under DESQ View with mixed results. I'm able to use KERMIT under DESQ View as long as I don't "kill" the KERMIT window and restart it. For example, once I start up DESQ View the first window I open up is a Kermit window (recommended since Kermit is non-swappable and by loading it first I won't fragment memory). From there I'm able to start up lots of other applications like 1-2-3, Sidekick, Epsilon, etc. and I can move between them without problems, including doing lots of terminal I/O and file transfer with Kermit. However, if I "close" the KERMIT window, it gets removed from memory. Then I'll start up KERMIT again as a terminal emulator. If I then try to pop into other windows, DESQ View seems to complain about most of the windows (windows that were swapped out seem ok but those resident in memory get blown away). It seems to act differently each time which leads me to believe there still might be some memory problems. We don't seem to have TopView so I couldn't try it under that program. I'll do some more experimenting to try to see if Kermit is in fact the culprit. -Rob ------- ------- 5-Feb-86 18:19:12-EST,610;000000000001 Mail-From: US.RCL created at 5-Feb-86 18:19:11 Date: Wed 5 Feb 86 18:19:10-EST From: Robert C. Lehman Subject: Re: Kermit 2.29 To: SY.FDC@CU20B.COLUMBIA.EDU In-Reply-To: <12181036382.20.SY.FDC@CU20B.COLUMBIA.EDU> Message-ID: <12181037814.56.US.RCL@CU20B.COLUMBIA.EDU> Yes, I saw that message so I did try those parameters. I also tried playing around with some of them to see if that worked (I tried giving KERMIT 200K initially) but none of them seemd to make much of a difference. I'll continue to play around and see if that makes a difference... Rob ------- 5-Feb-86 23:00:28-EST,816;000000000011 Mail-From: US.RCL created at 5-Feb-86 23:00:23 Date: Wed 5 Feb 86 23:00:22-EST From: Robert C. Lehman Subject: more on Kermit 2.29... To: sy.fdc@CU20B.COLUMBIA.EDU cc: howice@CUCCA.COLUMBIA.EDU Message-ID: <12181089006.56.US.RCL@CU20B.COLUMBIA.EDU> Hi Frank, Howie and I both took spent some time together on it and we came up with this: after killing the KERMIT window followed by starting up some other application and/or then starting another window with KERMIT in it, things are messed up by the time it gets to the "KERMIT-MS>" prompt. It's probably something in MSSKER.ASM, MSXIBM.ASM, or MSYIBM.ASM. I suspect something is weird in routines malloc, lclyini, or memini. I tried to narrow it down, but I haven't gotten any further than this... Rob ------- 6-Feb-86 12:44:27-EST,745;000000000001 Mail-From: US.RCL created at 6-Feb-86 12:44:24 Date: Thu 6 Feb 86 12:44:23-EST From: Robert C. Lehman Subject: More on 2.29 (Good news!) To: sy.fdc@CU20B.COLUMBIA.EDU cc: howie@CUCCA.COLUMBIA.EDU Message-ID: <12181239013.28.US.RCL@CU20B.COLUMBIA.EDU> Hi Frank, I continued debugging this morning and discovered that KERMIT would cause DESQ View to break upon KERMIT's second loading without executing (we just loaded it in with the debugger in another window). Howie then suggested that we try playing around without using KERMIT and see if we could break DESQ View. Guess what? It breaks! Obviously the problems are with DESQ View and not KERMIT. Sorry for the false alarm... Rob ------- 10-Feb-86 13:29:41-EST,1268;000000000001 Mail-From: SY.FDC created at 10-Feb-86 13:29:33 Date: Mon 10 Feb 86 13:29:33-EST From: Frank da Cruz Subject: Re: Ins&outs, Boo, Batch; responses To: JRD@USU cc: sy.vace@CU20B.COLUMBIA.EDU In-Reply-To: Message from "JRD@USU" of Mon 10 Feb 86 13:24:00-EST Message-ID: <12182295810.22.SY.FDC@CU20B.COLUMBIA.EDU> About netbios... I can't seem to find the original message that prompted all this brouhaha, and now that I give the program to some people here who are connected to PC net to see if the new code fixes the problem, they say "What problem?" -- according to them, there never was any problem with scan-code-reading coexisting with netbios, and since PC Network does not offer any kind of virtual terminal service (not that I know about, anyway), it's really only the disk i/o that has to be "well behaved"... We'll have to check into this further, but if you can unearth the original complaint, I'll see if I can get someone who knows more about netbios to find out exactly what the problem was supposed to have been. It would be bad to take away keyboard mapping from people who used to be able to use it... Sorry about this, but don't do anything yet, until we unscramble all of this... - Frank ------- 10-Feb-86 13:52:14-EST,871;000000000011 Received: from CUVMA by CU20B with HASP; 10 Feb 86 13:52:08 EST Received: by CUVMA (Mailer X1.23a) id 5744; Mon, 10 Feb 86 13:51:22 EST Date: Mon, 10 Feb 86 13:51 EST From: Vace Kundakci To: JRD@USU, SY.FDC@CU20B Subject: New Vt100 emulation One problem with VT10x emulation has come up... When the cursor is at column 80 and you type the last character of that line, the Vt10x cursor actually sits under (if it is an underscore, and atop if it is a block cursor) waiting for the next input. This feature allows for dumb programs which generate a cr/lf at the end of an 80 char line to not generate an empty line, and it is quite useful especially in half-duplex mode. The new Kermit vt100 emulation does not do this. I hope you can fix this problem before general distribution of your wonderful new MS-Kermit version. /Vace ------ 10-Feb-86 16:04:06-EST,472;000000000001 Received: from CUVMA by CU20B with HASP; 10 Feb 86 16:04:05 EST Received: by CUVMA (Mailer X1.23a) id 6077; Mon, 10 Feb 86 16:03:17 EST Date: Mon, 10 Feb 86 16:03 EST From: Vace Kundakci To: JRD@USU, SY.FDC@CU20B Subject: VT100 emulation Yet another problem... If you backspace (in half duplex) into the previous line as soon as the cursor jumps to the previous line it is positioned at column 79 and not 80. A boundary problem? /Vace ------ Actually, I'm not sure if the VT100 really backs the cursor up to the end of the last line upon backspace. At least, my VT102 doesn't. This might be a feature of the H19 that the VT10x doesn't have. - Frank 10-Feb-86 16:37:17-EST,408;000000000001 Received: from CUVMA by CU20B with HASP; 10 Feb 86 16:37:11 EST Received: by CUVMA (Mailer X1.23a) id 6143; Mon, 10 Feb 86 16:36:15 EST Date: Mon, 10 Feb 86 16:36 EST From: Vace Kundakci To: JRD@USU, SY.FDC@CU20B Subject: VT100 emulation One more thing - I think, the last one of the day... If Term WRAP is set OFF tabs stil wrap. Is this by design or an oversight? /Vace ------ 10-Feb-86 18:02:07-EST,1935;000000000001 Mail-From: SY.FDC created at 10-Feb-86 18:02:03 Date: Mon 10 Feb 86 18:02:03-EST From: Frank da Cruz Subject: A couple more... To: jrd@USU, us.travis@CU20B.COLUMBIA.EDU cc: us.cck@CU20B.COLUMBIA.EDU, sy.christine@CU20B.COLUMBIA.EDU Message-ID: <12182345419.18.SY.FDC@CU20B.COLUMBIA.EDU> Picked up when running jrd/4 on an AT with the EGA board and color monitor: 1. In VT10x emulation, when it receives ESC[4m (turn on underscore character attribute) it prints the ensuing characters in blue, rather than in the current color with underscore (a little disconcerting). 2. In H19 emulation, when it receives ESC p, it puts the whole screen in reverse video, rather than the ensuing characters. ESC q puts the whole screen in normal video, rather than the ensuing characters. When printing a short string of characters that are supposed to be in inverse video, this produces a flashing of the whole screen (also disconcerting). (Joe, these are from CCK -- Charlie C. Kim -- whose name you you were looking for to put in the credits, while running Unix 'rn' (readnews) -- which appears to rival VMS PHONE and EDT in its capacity to strain terminal emulators to their limits. He also had some color setting stuff for setting the foreground and background colors from Kermit-MS> command mode in the MSYIBM file I sent you, which some people might like...) About #2... I'm not sure what's right here; the H19 manual is ambiguous. It says: "Enter Reverse Video Mode -- ESC p -- The characters displayed on the screen can also be displayed in reverse video... Type ESC p to enter the Reverse Video Mode, and ESC q to exit the Reverse Video Mode." This doesn't really tell us whether the whole screen is affected, or just the characters that are displayed after the command. Travis, you have a real H19 -- can you try this and let us know? Thanks! - Frank ------- 12-Feb-86 10:58:40-EST,11628;000000000001 Mail-From: SY.FDC created at 12-Feb-86 10:58:25 Date: Wed 12 Feb 86 10:58:25-EST From: Frank da Cruz Subject: Some old loose ends To: jrd@USU Message-ID: <12182792585.17.SY.FDC@CU20B.COLUMBIA.EDU> Joe -- In cleaning out some very old stuff, I found a few messages that might still be of interest. Some of the suggestions may already have been taken care of. Most apply to 2.26 or 2.27. If they make sense, but have not been done, and you think they should be left for the next public-spirited volunteer, then we'll just add them to the to-do list. - Frank ------------------------------ From: Joe Smith, CSM Computing Center, Golden CO 80401 (303)273-3448 PROBLEM: Using SET LOCAL-ECHO ON does not work too well with 2 micros. There is no automatic linefeed when the RETURN key is pressed. CURE: When a CR is typed at the keyboard while LOCAL-ECHO is on, echo it as CR and LF, and set a flag signifying that an automatic LF was sent to the screen. If the host then sends a LF while this flag is set, ignore the 2nd LF (to avoid unwanted double spacing). [Frank -- this is the chat business we talked about before. The cure seems reasonable, if a little hairy.] ------------------------------ Date: 31 Jan 85 12:01 +0100 From: Pekka_Kyt|laakso_HYLK%QZCOM.MAILNET@MIT-MULTICS.ARPA Subject: Country specific characters in MSDOS Kermit (V2.26). Using MSDOS Kermit on the IBM PC there are problems in using the finnish and swedish characters and also the pound sign which should be '#'. I have here changes that translate input from keyboard to generate normal ascii characters and output to display change these characters back to IBM PC character. Here is a commented list of changes: subroutine trnout ----------msyibm.asm cmp ah,4eh ;*** plus key thing? je trnmod ; yes, go toggle mode line trnou1: test flags,havtt ; translate table given? ----------msypok.asm trnou1: test flags,havtt ; translate table given? ----------------------------------------------- ----------msyibm.asm call outprt ; send to port pop cx pop si loop trnou2 ; send all chars ret ; and return trnou3: cmp al,0 ; is it a special code? jne trnou4 ; no, don't do this ----------msypok.asm call transout ; translate from swedish/finish call outprt ; send to port pop cx pop si loop trnou2 ; send all chars ret ; and return trnou3: cmp ah,4eh ;*** plus key thing? je trnmod ; yes, go toggle mode line cmp al,0 ; is it a special code? jne trnou4 ; no, don't do this ----------------------------------------------- ----------msyibm.asm trnou4: call outprt ; just output single char ret ; and return ----------msypok.asm trnou4: call transout ; translate from swedish/finish call outprt ; just output single char ret ; and return --------------------------------------------- subroutine outtty ----------msyibm.asm mov dl,al ----------msypok.asm call transin ; translate to swe/fin mov dl,al ----------------------------------------------- ----------msyibm.asm cmp insmod,0 ; in insert mode? ----------msypok.asm call transin ; translate to swe/fin cmp insmod,0 ; in insert mode? ----------------------------------------------- and then subroutines that do the translating ----------msyibm.asm ----------msypok.asm ; ;Handle translation on displaying ; transin: cmp al,'[' jne dosf1 mov al,142 ret dosf1: cmp al,'\' jne dosf2 mov al,153 ret dosf2: cmp al,']' jne dosf3 mov al,143 ret dosf3: cmp al,'{' jne dosf4 mov al,132 ret dosf4: cmp al,'|' jne dosf5 mov al,148 ret dosf5: cmp al,'}' jne dosf6 mov al,134 dosf6: ret ret ; and return ; ;Handle translation on reading keyboard ; transout: cmp al,142 jne dobsf1 mov al,'[' ret dobsf1: cmp al,153 jne dobsf2 mov al,'\' ret dobsf2: cmp al,143 jne dobsf3 mov al,']' ret dobsf3: cmp al,132 jne dobsf4 mov al,'{' ret dobsf4: cmp al,148 jne dobsf5 mov al,'|' ret dobsf5: cmp al,134 jne dobsf6 mov al,'}' ret dobsf6: cmp al,156 ;pound sign jne dobsf7 mov al,'#' dobsf7: ret There sould also be a SET TRANSLATE ON/OFF or a SET LANGUAGE command and calling the translation routines should be conditional. There should also be similar routines for other languages. (If you wonder what POK is, its a abreviation of Pekka O. Kyt|laakso). [Frank -- This is very specific to Swedish & Finnish, but it raises the question of whether there should be some special translate tables for screen output (I think SET KEY is sufficient to handle keyboard input).] ------------------------------ (note to Jeff--) Now here's a small thing for 2.28, but I think it's worth doing, since we have the Series-1 ourselves and it will be seeing increasing use from PC's. I'm surprised none of our users ever reported it. By the way, the terminal emulator should swallow unsupported escape sequences rather than displaying them on the screen. - Frank (note to jrd--don't know whether Jeff actually did this or not...) --------------- Date: Tue, 12 Mar 85 20:20 EST From: Alan H. Holland Subject: Kermit-MS Terminal Emulation and the IBM Series/1 Frontend I have been trying to use the H19 terminal emulation in Kermit-MS version 2.27 to connect an IBM PC to a Series/1 frontend on an IBM VM/CMS system. It doesn't quite work. The Series/1, when told that it is dealing with an H19, sends some ESC sequences that Kermit-MS doesn't deal with. As near as I can tell, there are only two such ESC sequences that are really important: ESC x 4 set cursor to block ESC y 4 set cursor to underscore The Series/1 uses an underscore cursor to signal insert mode and a block cursor to signal normal/replace mode. Under current circumstances, entering and leaving insert mode causes "y4" and "x4" blemishes to appear on the screen. These blemishes can be removed by sending the Series/1 a cntl V, which requests a screen refresh, but that can become tedious. If Kermit-MS would parse and throw these sequences away, that would be a big improvement. Obviously, it would be nicer yet if these sequences were implemented. All other ESC sequences sent by the Series/1 to an H19 are implemented in Kermit-MS or appear only in an initialization string. The ESC sequences in the initialization string apparently do not cause any trouble, but I will list them for completeness: ESC LEFTBRACKET ? 2 h a VT100 sequence to set VT52 mode on (!?) ESC t enter keypad shifted mode ESC = enter alternate keypad mode ESC x 1 enable 25th line ESC x 4 set cursor to block I hope that this is of some help in the general effort to get Kermit to work through and with the Series/1. --Alan Holland FEAHH at VPIVM1 on BITNET ------------------------------ Date: Sat 9 Mar 85 02:07:57-EST From: Ed Shaw Subject: Customizing Kermit Well, I finally got kermit to show some life on my MPX-16 using an expansion card for the COM port. On this machine, the location of the interrupt controllers is moved (to 140 from 20), so that wasn't too hard once I figured out which was the master and which the slave. I was able to do file transfers with send/receive to a Dec-20, but it bombed out (with a message that flashed too quickly for me to see) when I tried to use the server mode on the -20. Is this problem related to the following? A very extensive problem is the fact that the code assumes the existence of a display board and/or a keyboard in far too many places. I would think that the generic MSDOS version would make no assumptions about either, and supply a module that works for a simple glass Teletype (i.e., an external terminal). Another guy here has had a similar problem, and he has been looking at re-organizing the code to make it easier to port. We have had difficulty understanding when which terminal emulation is used for what! Now let me try to sort out that statement. There seems to be several different places where terminal handling translation needs to be done: 1) From the command processor of the kermit on the local machine to the local user. 2) From remote machine programs (including Kermit) to the local Kermit terminal emulator; i.e., tell the remote machine that you have a VT100 or an H19. 3) To the terminal connected to the local machine. In my case, this is an ADM-3A; for an IBMPC, this is a graphics card-keyboard interface combo. Near as I can tell, MSYIBM tries to do 2) using the IBM cards directly, making no attempt to isolate the interfaces of 1) and 3). This isolation could be accomplished by using a "standard terminal" as an intermediary. Translations to/from the others should be table driven in much the same way that EMACS does its command interpretation. In a picture, the modules would look as follows: Remote machine Local Kermit Local Display Local (terminal driver) (COM port Keyboard emulator) H19 H19 \ / ADM-3A ASCII Vt100 . \ (table) / CT-1024 ASCII VT52 ========= . > -------standard------ < TVI ASCII ANSI . / ANSI or \ IBM GRAPHICS IBM etc. etc./ H19 \ etc. etc. ^ | | local Kermit (command processor) Now kermit can supply a table driven H19 (or whatever) to standard translator. If the standard table is provided in a separate file, it would be a simple matter to substitute a table describing the local user's display device. In addition, Kermit could supply a simple display interface, e.g., a glass Teletype, which would be a model to build the user's display definition. Is anyone else working to clean up this part of the interface along these lines? Finally, I've just realized that I've been working with version 2.26, and that there is a version 2.27. What's the easiest way to find out what's been changed (I don't seem to be able to get a directory listing with the dates, etc.)? Is there a way to download Kermit directly to a pc similar to the FTP anonymous convention? ------------------------------ ------- 12-Feb-86 18:41:20-EST,1533;000000000001 Mail-From: SY.FDC created at 12-Feb-86 18:41:17 Date: Wed 12 Feb 86 18:41:17-EST From: Frank da Cruz Subject: Found on Info-IBMPC... To: jrd@USU Message-ID: <12182876848.16.SY.FDC@CU20B.COLUMBIA.EDU> ...in case it's of any interest... Date: Mon, 10 Feb 86 14:31:49 PST From: kegel%Romeo@Hamlet.Caltech.Edu Subject: DOS vs. Direct Screen Writes Minshall- DOS writes to the screen are slow for two reasons: 1. stdout is normally in 'cooked' mode, in which DOS makes one call to the device driver for each character output. 2. ANSI.SYS stacks the registers for each char output, and makes one or two BIOS calls per character output, to boot! Both of these can be fixed. 1. Any handle can be set to 'raw' mode with dos function 44h. In raw mode, DOS passes all read and write requests directly to the device driver, cutting the per-character overhead to zero. 2. ANSI.SYS can be rewritten to write directly to screen memory, and to avoid stacking the registers. I'm not sure if anyone else has redone ANSI.SYS, but I took a shot at it, and would be happy to put my sources up. It is radically faster. One test program I wrote- a file viewer- redraws the screen in less than a tenth of a second. I think even the most hardcore advocate of direct machine access would be satisfied with the performance an efficient device driver gives DOS. - Daniel Kegel [Woof Woof Send it to us Daniel! -wab] ------------------------------ ------- 13-Feb-86 10:00:32-EST,1222;000000000005 Mail-From: SY.CHRISTINE created at 13-Feb-86 10:00:25 Date: Thu 13 Feb 86 10:00:25-EST From: Christine M Gianone Subject: [MSchwartz@DOCKMASTER.ARPA: Kermit hangup on Z100] To: sy.fdc@CU20B.COLUMBIA.EDU Message-ID: <12183044172.45.SY.CHRISTINE@CU20B.COLUMBIA.EDU> Return-Path: Received: from DOCKMASTER.ARPA by CU20B.COLUMBIA.EDU with TCP; Wed 12 Feb 86 00:24:36-EST Date: Tue, 11 Feb 86 23:06 EST From: MSchwartz@DOCKMASTER.ARPA Subject: Kermit hangup on Z100 To: SY.CHRISTINE@CU20B.COLUMBIA.EDU Message-ID: <860212040617.452870@DOCKMASTER.ARPA> To the Z100 experts familiar with KERMIT Has anyone found the fix to KERMIT version 2.27 or more recent to prevent the serial port from resetting (and therefore hanging up the phone) between connect and send/receive? I am looking for a solution which does not hamstring the serial port protocol by ignoring signals if possible. Please mail your solutions or comments to me directly, as I do not receive the Z100 mailings. I will sort the best solution out of the responses (if any) and post it both to HZ-100 and INFO-KERMIT. Thanks MSchwartz -at DOCKMASTER ------- 14-Feb-86 16:44:47-EST,1719;000000000011 Return-Path: Received: from LOCUS.UCLA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 14 Feb 86 16:44:30-EST Date: Fri, 14 Feb 86 09:49:09 PST From: Jim Carter To: info-kermit@cu20b.columbia.edu Subject: Bug in MS-Kermit remote-dir Message-ID: <508787349-15407-jimc@ATHENA.LOCUS.UCLA.EDU> Scenario was as follows: Logged drive+directory was c:\work. Kermit version is MS-Kermit v2.28. Other end was C-kermit v.? (new version as of Fall 85) in server mode (kermit -x) on UNIXoid. Locally I did: get m13c.msg d:m13c.msg <--that's supposed to be a local filename --Transmission failed, file not found <--WHAT??? remote dir ls -l -rw-------- etc. m13c.msg <--I thought it was there! Now Kermit reads local drive a: <--bug being reported I insert a floppy (formatted, empty). It seems satisfied. get m13c.msg <--Works. (1) What was it trying to find on a:? (2) I thought it could handle local drive names (directories in 2.28jrd). (3) The initial failure obviously was in creating the local file. A more informative error message would be helpful. (4) The above version number is from memory. A "show version" command or something like that would be helpful. (Do I remember a greeting message with the version? As my mskermit.ini auto-connects, I don't see it. I'll try hiding mskermit.ini and follow up if the version number is wrong.) James F. Carter (213) 206-1306 UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU 20-Feb-86 01:49:19-EST,3569;000000000001 Return-Path: Received: from LOCUS.UCLA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 20 Feb 86 01:49:12-EST Date: Wed, 19 Feb 86 17:41:44 PST From: Jim Carter To: sy.fdc@cu20b CC: kitch Subject: Kermit v2.28jrd/2 Message-ID: <509247704-15688-jimc@ATHENA.LOCUS.UCLA.EDU> I brought it in by FTP today. Setting it up was mostly straightforward. However: 0. Environment. PC-AT, PC-DOS v3.1, old Kermit v2.26. Mainframe was a VAX running UNIXoid, C-kermit v4C(057). FTP -- likely up to date but I don't know the rev level. 1. The .exe and .obj files arrived damaged. .exe was "Program too big to fit in memory", and the linker bitched about an undefined record type in the .obj files. The same thing happened when I tried to bring in MS- kermit v2.27. I did the following: FTP cu20b; binary [mode]. kermit -ix (C-kermit server in image mode). get msvibm.exe (on local Kermit). Can you see anything I did wrong? I have a feeling FTP is at fault, but no good evidence. 2. So I reassembled (didn't fiddle with mssdef.h) and relinked, with no trouble. By the way, for FTP debugging, the version of MSSFIN.OBJ that came from you ended up 99 bytes long, while the assembled version was 87 bytes long. Task image sizes were 48744 (yours) vs. 43328 (local link). ---Yup, the MSSFIN.OBJ on the VAX is also 99 bytes long. 3. Execution. Lots of nice new stuff e.g. shell-fork from a connected session. I had some trouble, though, with file transfer: works: send \bin\mskermit.ini works: get kermit/mssrcv.asm fails: get kermit/mssrcv.asm gorf <-that's supposed to be a local name fails: get kermit/mssrcv.asm ..\misc fails: get kermit/mssrcv.asm \work\misc fails: get kermit/mssrcv.asm c:\work\misc\mssrcv.asm i.e. I couldn't specify any local filename on get. The ? feature on the command line didn't know about the local filename. But the Help output did know. The error message was "File doesn't exist", which appears to pertain to the remote kermit. 4. I had some possible trouble with session logging. Locally I did "log prn". I found that I had to do ^]R to turn on logging (I expected it to be on by default if a file was given). After ^]Q, then later ^]R I couldn't get it to log again. I also tried ^PrtSc at various times and, at one point, local dialog (including "Command>" after ^]) was logged and remote dialog wasn't. It was rather confusing and I'm not sure exactly what interacted with what to do what, but it wasn't what I wanted. If I get any more clues, I'll report them to you. 5. By the way, I found myself doing ^]^? rather than ^]? and similarly on letter commands. This seems to be an easy error to make, also to ignore. 6. The most common error I make in Kermit is to start up a remote server, transfer a file, then connect. It would be nice, if local Kermit believes there is a remote server going, to refuse to connect. Or to refuse one time, so if the user is trying to fake out the remote kermit he can override the refusal. It's fortunate that a server Kermit is fairly immune to random user input. All in all, I like the new Kermit. I'm anxiously awaiting the version mentioned in msajrd.010 or thereabouts that has VT102 support. James F. Carter (213) 206-1306 UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024 UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc ARPA:jimc@locus.UCLA.EDU 28-Feb-86 05:34:59-EST,1722;000000000011 Return-Path: Received: from TB.CC.CMU.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 28 Feb 86 05:34:55-EST Date: Thu 27 Feb 86 08:01:00-EST From: TS1T@TB.CC.CMU.EDU Subject: keyscans To: sy.fdc@CU20B.COLUMBIA.EDU Message-ID: <12186692448.48.TS1T@TB.CC.CMU.EDU> Dear Mr. da Cruz, Thank you so much for your prompt reply. I didn't know who to inquire with at Columbia. I hope this will not be too much trouble. The message I sent was a portion of my macro. There are a set of problems there in the macro and I am afraid I didn't mark them very well. But each of the set keyscan...; commands has a problem. For example there is a problem with the C-downarrow and A-uparrow combinations which also donot have keyscans. Any help you can give me will be greatly appreciated. Thanks. ;set key scan ; A-[ to produce M-[ [backward paragraph] ;\033\133 ;set key scan ; A-\ to produce M-\ [delete horizontal space] ;\033\134 ;set key scan ; A-] to produce M-] [forward paragraph] ;\033\135 ;set key scan ; A-~ to produce M-~ [buffer not modified] ;\033\ ;set key scan ; A-8 to produce M-[ [backward paragraph] ;\033\133 ;set key scan ; A-4 to produce C-A [beginning of line] ;\001 ;set key scan ; A-6 to produce C-E [end of line] ;\005 ;set key scan ; A-2 to produce M-] [forward paragraph] ;\033\135 ;set key scan ??; 5 on keypad to produce C-U 10 C-L [center line at line 10] ;\025 10\114 ;There is a problem with KERMIT not having a functioning keyscan ;for keypad-5. ;set key scan ;C-n8 on keypad to produce A-A [backward-sentence] ;\033\101 ;set key scan ;C-n2 on keypad to produce A-E [forward-sentence] ;\033\105 -Terry Sullivan ------- I asked about this, and the answer was that the indeed the keys in question do not produce scan codes. Blame IBM. Most software makers use the F keys instead of the keypad for this stuff, for just this reason. There's really no way to find out these keys were pressed, and still get the scan code for the other keys. Too bad. 28-Feb-86 08:26:24-EST,1568;000000000001 Mail-From: SY.FDC created at 28-Feb-86 08:26:23 Date: Fri 28 Feb 86 08:26:23-EST From: Frank da Cruz Subject: [Roger Hartmuller : new kermit msjrd5b] To: jrd@USU Message-ID: <12186959215.26.SY.FDC@CU20B.COLUMBIA.EDU> Hmmm... Do you know anyone with a Hayes internal modem? Looks like they're causing trouble. --------------- Return-Path: Received: from DOCKMASTER.ARPA by CU20B.COLUMBIA.EDU with TCP; Fri 28 Feb 86 01:35:31-EST Date: Thu, 27 Feb 86 20:28 EST From: Roger Hartmuller Subject: new kermit msjrd5b To: info-kermit@CU20B.COLUMBIA.EDU cc: Hartmuller@DOCKMASTER.ARPA Message-ID: <860228012827.653441@DOCKMASTER.ARPA> This afternoon I told you that I couldn't do file transfers with the new kermit using a Hayes internal modem. Anyway, tonight I brought the program home to run on my Sperry IT with an internal Qubie 1200 baud modem. File transfer works fine. Any idea what the difference could be. I am using the same .ini file in both cases. -------------- (my reply was: Internal modems always pose problems. They never work quite the same way as a real serial port. There's no code in Kermit to deal with them, and there's no way you can fake the signals with jumpers, like you can when you have an RS-232 cable to an external modem. I'll ask around to see if anyone has figured out how to make the new version work with the Hayes internal modem. - Frank -------