Date: Thu, 29 Oct 87 17:07:50 PST From: dplatt@teknowledge-vaxc.arpa (Dave Platt) X-Usnail: Teknowledge Inc., 1850 Embarcadero Road, Palo Alto CA 94303 X-Voice: (415) 424-0500 Subject: Initial impressions of the new Kermit Cc: K116430@CZHRZU1A.BITNET I've spent the last half-hour playing around with Kermit 0.9(36) on a Mac Plus running System 3.2, connected via a 9600 baud hardwired line to a TIP which opens TELNET connections to various local hosts in-house. I tested 0.9(36) against 4E(067) running on a Vax 8650 under Ultrix 1.2. Notes from my fiddle-about: 1) I was able to puzzle out the method for remapping some of the keys on the Mac Plus keyboard to do what I wanted. The big clue was that one persuades Kermit to send a control character by using the sequence "\nn", where "nn" is the decimal representation of the ASCII character desired. Unfortunately, it's difficult to confirm the setting of a key that has been mapped in this fashion; when you hit the same key to check the setting, you typically see a small empty box (the standard "Unassigned font code" character in the Mac font structure). It'd be nicer if Kermit reconverted unprintable characters to the \nn notation before displaying them. 2) I wasn't able to figure out how remap a key so that it would send a Break. This was possible under 0.8(34) and (35) using a _very_ obscure function mapping; I haven't discovered the equivalent under 0.9(36). 3) The send and receive packet-sizes, and perhaps some of the other protocol-related information, isn't being restored properly when you load a settings file; the packet size returns to the default of 90. Some of the protocol information (block-check type, for example) is being saved and restored properly, though. 4) The screen image is not restored properly after a dialog box is erased (e.g. after a download, or after changing the settings). The problem appears to be most acute if the screen was trying to scroll during the erase-and-refresh process; I suspect that the scroller and the screen-refresher are stepping on each other's feet. 5) The ability to receive 900-byte packets makes an _amazing_ different in the speed of a download in my 9600-baud TELNET environment. 6) If you save a settings file "on top of" an existing settings file of the same name, 0.9(36) does not copy the old version's window-placement information when it creates the new version. This is most noticable if the old version had been moved onto the Mac desktop; the new version is not visible on the desktop, but is instead found in the disk's (or folder's) window. 0.8(34) did this correctly, by copying the old version's window/position information. 7) I like the smooth scrolling, and the ability to use a thin-underline cursor rather than an eye-searing blinking-block. Conclusion: not at all bad for a beta version; it'll really be nice when the current set of glitches are tracked down and persuaded to move to Tumbolia. I'll try it tonight on my Mac II and see what happens... ------------------------------ Date: Fri, 30 Oct 87 10:28:23 EST From: Charlie C. Kim To: paul@ohio-state.arpa Cc: SY.FDC@cu20b.columbia.edu, MACMAN@CZHETH5A.BITNET, ZBEN@umd2.umd.edu, verber@ohio-state.arpa, mer@diamond.bbn.com, Lane@kestrel.arpa, dplatt@teknowledge-vaxc.arpa, sy.christine@cu20b.columbia.edu, placeway@ohio-state.arpa, stamr%unc@mcnc.org, DPVC@uordbv In-Reply-To: Paul W. Placeway's message of Thu, 29 Oct 87 15:50:45 EST <8710292050.AA17123@tut.cis.ohio-state.edu> Subject: Re: Another Volunteer / MacKermit 0.9(36) Rewriting to support background under Multifinder is a good idea, but may be ahead of its time. The problem with this is that IO runs sync. under a task at the present time - this will result in major degradation of any foreground tasks and/or will result in major problems with file transfers (depending on how often the foreground task gives up time). Some help would be allocation of "big" buffers via Mf temp allocation routines to keep the read/writes big (e.g. minimize # of switches). A project that might well be worth the trouble to pursue is replacing the terminal emulator with the NCSA Telnet one (when the source release goes out on Nov. 3). The NCSA terminal emulator is VT100 (with scroll back and multiple windows) and also has Tektronix emulation (optional). There are some problems with it (mainly speed and size (about 25-30K for vt100 & same for tek)), but the functionality is much better than Kermit's. A suggestion: use "byte", "sbyte", "word", "sword", "dword", "sdword" to represent a byte, signed byte, etc to maintain size compatibility between compilers. Don't depend on the fact that "short" is 16 bits and "long" is 32 bits in most if not all of the Mac compilers. Put constant strings in the resource file so they can be "countryized" (and so you bypass the problem of no "\p" in MPW). Charlie ------------------------------ Date: Fri, 30 Oct 87 13:13:38 PST From: dplatt@teknowledge-vaxc.arpa (Dave Platt) Subject: More notes on Kermit 0.9(36) Cc: K116430@CZHRZU1A.BITNET I tried the new version on my Mac II last night. Notes from that experiment: 1) I had noticed that some of the field labels in the protocol-setup box were either misplaced, or only partially present, when I ran 0.9(36) on a Mac Plus under System 3.2. These fields all appear to be OK when the same version of Kermit is run under System 4.1 on my Mac II. I'm not sure whether the difference is in the System itself, or in the fonts. 2) The scrolling/refresh conflict I noticed on 3.2/Plus is also present in the 4.1/Mac II environment. 3) I reported that some of the protocol-configuration information wasn't being saved and restored in the settings files. I found last night that the "send packet-length" information is saved and restored OK, but that the "receive packet-length" always reverts to 90. 4) Smooth scrolling on a Mac II in 8-bit-pixel mode is incredibly slow (much slower than smooth scrolling on a Plus). 5) Over a 1200-byte dialup line to a Tip which was telnet'ed into a Sun 3/110 running SunOS 3.4, 800-byte packets worked just fine for both "send file" and "receive file". ------------------------------ Date: Sat, 07 Nov 87 23:27:21 GMT From: K116430%CZHRZU1A.BITNET@CUVMA.COLUMBIA.EDU Subject: MacKermit 0.9(36) B2 and comments on reported bugs Thank you for the beta test comments. Here is my reply: > ... Unfortunately, it's difficult to confirm > the setting of a key that has been mapped in this fashion; when you > hit the same key to check the setting, you typically see a small > empty box (the standard "Unassigned font code" character in the Mac > font structure). It'd be nicer if Kermit reconverted unprintable > characters to the \nn notation before displaying them. The conversion back to \nn was already planned and most of the code included in the source. Version 0.9 B2 now uses it. > I wasn't able to figure out how remap a key so that it would send a > Break. This was possible under 0.8(34) and (35) using a _very_ > obscure function mapping; I haven't discovered the equivalent under > 0.9(36). The problem is, that I didn't have the time to write a documentation so far. Breaks are defined by using \bs for a short break and \bl for a long break. I hope you find this less obscure than the old way of doing it. To make Mac Kermit more self explanatory (being self explanatory is one of the most important criterions for a good Macintosh application) I added a short help dialog box to macro defining. > The send and receive packet-sizes, and perhaps some of the other > protocol-related information, isn't being restored properly when you > load a settings file; the packet size returns to the default of > 90. Some of the protocol information (block-check type, for > example) is being saved and restored properly, though. The receive packet-length wasn't saved and restored correctly indeed. The problem was the distinction that is made between the packet size and the user defined packet size under the new protocol. This problem is fixed now. > The screen image is not restored properly after a dialog box is > erased (e.g. after a download, or after changing the settings). The > problem appears to be most acute if the screen was trying to scroll > during the erase-and-refresh process; I suspect that the scroller > and the screen-refresher are stepping on each other's feet. There was the same problem with the last few versions too. It came in when writing to the screen was changed to XOR mode. After releasing a dialog box, handling the newly arrived characters comes first. With scrolling this moves up the white area. Now the update is done with the update rectangle where it was before. The cleared area is updated correctly but the scrolled up text is XORed away. Scrolling the update region together with the text fixed the problem. > If you save a settings file "on top of" an existing settings file > of the same name, 0.9(36) does not copy the old version's > window-placement information when it creates the new version. > This is most noticable if the old version had been moved onto the > Mac desktop; the new version is not visible on the desktop, but is > instead found in the disk's (or folder's) window. 0.8(34) did this > correctly, by copying the old version's window/position information. As you mention 0.8(34) left the settings file where it was (on the desk- top). But unfortunately it also added more and more resources of the same type and number, without releasing the old ones. This resulted in the pro- blem, that you could not change the values in an existing settings file. Even if the resources were written back correctly, Kermit always used the oldest set of resources. 0.9(36) B1 fixed this problem by deleting the old settings file first and adding the new resources to a newly created file with the same name. This in turn left the new file in the disk window instead of the desktop even if the finder folder information was set correctly to the desktop (which doesn't seem to work for HFS). Now 0.9(36) B2 uses another scheme to avoid both problems: It keeps the original file but deletes the old resources first. This is slower and uses more code, which was the reason why I didn't implement it this way right from the beginning. I didn't know that this could be important to Mac Kermit users. > I had noticed that some of the field labels in the protocol-setup > box were either misplaced, or only partially present, when I ran > 0.9(36) on a Mac Plus under System 3.2. These fields all appear to > be OK when the same version of Kermit is run under System 4.1 on > my Mac II. I'm not sure whether the difference is in the System > itself, or in the fonts. I have no explanation for this. All I can say is that I'm using standard resources and standard toolbox calls. Nothing extraordinary. To me it looks like a problem of the system you have been using. > Smooth scrolling on a Mac II in 8-bit-pixel mode is incredibly slow > (much slower than smooth scrolling on a Plus). Of course scrolling is slower on Mac II using 8 bit planes. There are eight times more bits to be moved. I don't see a way to change this. > There was one bug which I also fixed which was related to updating the remote command response which should work correctly now. So the following BinHex code contains the new beta version of MacKermit: 0.9(36) B2. Try it and let me know about other problems you find. Matthias Aebi K116430@CZHRZU1A.BITNET [Ed. - The new BinHex file is now replaces the previous KER:XKM936.HQX.] ------------------------------ Date: Mon, 09 Nov 87 22:13:11 GMT From: K116430%CZHRZU1A.BITNET@CUVMA.COLUMBIA.EDU Subject: Re: MacKermit 0.9(36) B2 and comments on reported bugs To: Frank da Cruz The last few lines of the BinHex seem to be ok. BinHex always starts and ends a file with ':'. So I think it's ok to redistribute it. The only reason not to distribute it is the fact, that I'm currently testing version B3 wich I started after reading the message form Jim Lewinson. He complained about the inability to define "controllify" for a whole keyboard for ex- ample. This finally convinced me to implement a new scheme for the modi- fiers. It is now more flexible and powerful than it was ever before (in- cluding earlier version of MacKermit). So if you want I could send you B3, otherwise I will hold it back for the moment and wait for the first Beta-Test comments on B2. Just let me know what you would prefer. Matthias ------------------------------ Date: Tue, 10 Nov 87 13:13:02 GMT From: K116430%CZHRZU1A.BITNET@CUVMA.COLUMBIA.EDU Subject: Mac Kermit 0.9(36) B3 HQX To: SY.FDC@CU20B.COLUMBIA.EDU What follows after the dotted line is the file that I sent to three other people willing to beta test the new version. Of course the note about redistribution does not hold for Columbia. I just don't want to spread the beta version too far resulting in a version chaos. The changes between B2 and B3 only concern the key modifier part of the program. In the earlier version it was possible to specify a modifier key combination for "controllify" and two combinations for a prefix string. The main problem was, that pressing a modifier like option for example not only selected an action like "do prefix-1" but also had the normal effect on the key pressed. With the option key defined as the "controllify" key there was the problem that the ASCII character returned by the Macintosh keyboard driver was not an ordinary ASCII character but one from the "options set". The same problem made it impossible to define to send the uppercase letter of the keypressed prefixed by ESC for the command key (pressing the command key you always get a lower case ASCII from the Mac keyboard). Now with the old way to handle the keyboard it was always simple to find out the ASCII character for the unmodified keystroke. It could be looked up in the unmodified table. With 0.9 there is no such table anymore. So what was necessary was to find a way to get the unmodified ASCII character for a keycode even if it was pressed along with modifier keys. This was complicated even more by the fact, that the newer machines use the Apple Desktop Bus (ADB) for the keyboard and with it a new scheme to translate keycodes to ASCII. But after all i think a found a solution which should work with all machines and versions of the system. For the user there isn't a big change. You can now define three key modifier combinations along with four actions that should be applied to the key/ASCII code: Unmod: undo all modifications that could be caused by the key modifiers pressed. This returns a lowercase ASCII character corresponding to the key pressed. Caps: Make an uppercase letter if it is lowercase Ctrl: Aplly a control-bit-mask to the ASCII you got so far Prefix-String: Send the prefix string before the character I finally established a contact to Paul Placeway and will turn the source over to him in the next few days (assuming there are no serious bugs found in my code till then. Otherwise I think I should fix them before sending off the code.) ........................................................................... This file contains version 0.9(36)B3 of MacKermit. It is a beta test version which should !not! be redistributed in any way. After unbin- hexing it must be unpacked with Unpit 0.3.1 or (if you payed the license fee) with PackIt III. There is currently no documentation for it so you have to discover the new features yourself. Let me know if you find bugs (especially those which haven't been there in Kermit 0.8(35)) or serious restrictions in using the program. Send your e-mail to K116430@CZHRZU1A. IMPORTANT NOTE: Do !not! try to use settings file written with earlier beta versions of 0.9(36). The key macros will swamp you with error messages. Matthias Aebi ------------------------------ 11-Dec-87 04:35:26-EST,2691;000000000001 Return-Path: Received: from GSB-WHY.Stanford.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 11 Dec 87 04:35:21-EST Date: Fri 11 Dec 87 01:34:20-PST From: Jim Lewinson Subject: Font Problem in MacKermit 0.9(36)B3 To: K116430%CZHRZU1A%Forsythe.Stanford.EDU@GSB-WHY.Stanford.EDU, sy.FDC@cu20b.columbia.edu Message-ID: <12357572714.15.A.JIML@GSB-WHY.Stanford.EDU> Problem: Someone testing MacKermit 0.9(36) B2/B3 at the GSB Computer Facility complains about how bad the font looks. I look at their machine. It really does look bad, but looks fine on my machine at home. Diagnosis: MacKermit has two FONT resources internally, "VT100", ID=128 and "VT100 Bold", ID=129. This person turned out to have the Princeton Font installed in their System, FONT ID's 128 and 130. So far so good - Kermit will see the local resource first, and use VT100 {Bold}, and everyone is happy. However, there is a new resource to be found in Systems now, called a FOND, which describes the FONT in question. MacKermit has no FONDs, but the System did for the Princton Font. If the System doesn't find the FOND resources, it gets along without them, but it will use them if it finds them. Well, for the VT100 Font, the system sees the VT100 Font, but used the Princeton FOND from the System! The result is really unreadable screens. Solution: Add FOND resources to the MacKermit VT100 and VT100 Bold fonts. Easier said than done? True. The Trick is to use FONT/DA Mover. (I used 3.6; 3.5 probably also works.) I did the following long winded procedure. Something simpler based on the same concept may also work, but I didn't try it. 1) Copy the Princton Fonts from the System File to another file. 2) REMOVE the Princeton Fonts from the System. (Important!). 3) Hold down the OPTION Key before clicking the Open Button and Open up MacKermit. 4) Copy the VT100 and VT100 Bold Fonts to the System File. 5) REMOVE the VT100 Fonts from MacKermit. (Important!) 6) Copy the VT100 Fonts back into MacKermit. 7) Remove the VT100 Fonts from the System File. 8) Reinstall Princeton Fonts into the System File. Explanation: Font/DA Mover knows how to create FOND resources for FONTs that don't have them, and created them when the fonts moved into the System File. It moves them back too, so MacKermit now contains both the FONT and FOND resources INSIDE MacKermit that the System is looking for, so it never sees the ones in the System File! I can BinHex and Upload our updated version of MacKermit if you like and send it to you or give you a pointer to it. Jim -------