—Frank da Cruz, 26 December 2014
Last update: Wed Oct 21 07:57:19 2015 (at bottom)
26 December 2014, ANONYMOUSCODER said:
Date: Sun, 20 Oct 2013 00:42:04 +1300 Subject: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: fdc@kermitproject.org Hi Frank, I've been having a go at getting Kermit 95 to build recently and I've run into a few missing files in the open source release. I was wondering if you might still have access to the original source code and might be able to organise the release of these additional files too. So far I've been documenting my current progress over here: http://www.ext.zx.net.nz/software/notes/kermit95/. My current focus is getting it to compile and run with all the original library versions just so I have something that builds and runs as a starting point. The console version is currently building and running (screenshot <http://www.ext.zx.net.nz/software/notes/kermit95/k95_screen.png>, source & binaries <http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-1/>) with SSH, Kerberos, DECnet, LAT and X/Y/Z modem support disabled. Kerberos and SSH support are next on my list of things to get building.The OpenSSH version string used by Kermit 95 v2.1 (OpenSSH_3.0.2p1+SRP+GSSAPI) looks like a customised version though. Does this code still exist in a form that could be released? I'd also like to get the graphical version (k95g.exe) going too. The object files listed below are all required to build it but the source code that they're produced from looks to be missing. Its all referred to as KUI stuff so there may be other headers, etc that are needed too. If there is no Zinc involved then getting it to build might not be too difficult. If it does use Zinc then just having any bits that don't directly contain 3rd-party code would make rewriting or porting to something like Qt somewhat easier. - kregedit.obj - ksplash.obj - ikterm.obj - karray.obj - kszpopup.obj - kmenu.obj - kscroll.obj - kcmdprot.obj - kcmdup.obj - kcmdcom.obj - kfontdlg.obj - kflname.obj - kuikey.obj - kcliserv.obj - kcommand.obj - ksysmets.obj - ikui.obj - ikcmd.obj - khwndset.obj - kflstat.obj - kstatus.obj - kcmdproc.obj - kcmdmous.obj - kcmddown.obj - kprop.obj - kcolor.obj - kdwnload.obj - kclient.obj - kappwin.obj - ktermin.obj - kprogres.obj - kuidef.obj - kwin.obj - kcustdlg.obj - ktoolbar.obj - kcmdterm.obj - kcmdscri.obj - kcmdlog.obj - kfont.obj - kabout.obj - kupload.obj - kcserver.obj - kui.obj Additionally, I've run into a few other missing files so far which are a bit less important but still might be useful to have: - cknker.def - kui\ikui.h - cknker.rc - cknker.ico - wrlogin.def - getopt.c - getopt.h - ssh\ckosslc.c creating empty versions of cknker.def, wrlogin.def, ikui.h and cknker.rc are enough to get it to build and run but I don't know what effect this may have on the programs operation. The getopt stuff and ssh\ckosslc.c are needed by the srp tools (srp-keygen, etc). I'm not sure if the ckossl.c version included in the source release is the same as the one that lived in the ssh directory - the makefile suggests that the file existed in both locations. Regards, David Goodwin
Date: Sat, 19 Oct 2013 9:46:11 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Cc: Jeffrey Altman <jaltman@your-file-system.com> > I've been having a go at getting Kermit 95 to build recently and I've > run into a few missing files in the open source release. I was wondering > if you might still have access to the original source code and might be > able to organise the release of these additional files too. > I'm very glad to hear that somebody is working on this! I'm responsible for the parts of K95 that are common with C-Kermit and can do something about them. Jeff Altman did all the Windows-specific parts, all the encryption and security parts, much of the networking, and pretty much everything else that is not from C-Kermit. After our initial release of the console version, we wanted to release a true GUI version, where all the controls were graphical dialogs. There is a ton of code, many many modules, in support of this project, which was never completed. Most or all of the modules whose names start with K probably fall into this category. You can just forget about them if you want to produce a new K95 that is command driven, comparable with K95G.EXE 2.1.3. You can also forget about the Dialer. In fact, you'll have to because as noted on the website, it's built using a package that no longer exists, whose source code had to be modifed, but which we have no right to release. Personally, I use K95 all day every day and would be very happy to see a new release that has all the fixes and new features of the last 10 years. I'm cc'ing Jeff on this so he can offer any guidance. Meanwhile, at some point I hope you'll try to integrate the latest C-Kermit source code: http://www.kermitproject.org/ckdaily.html since I'm working on it (off and on) can easily make any required changes. And as soon as you're comfortble with the idea, I'd like to announce what you're doing and host development builds on the new Kermit Project website. This way, hopefully, others will pop up and lend a hand. For me, the most important item is SSH, since it's next to useless for network connections without it. > So far I've been documenting my current progress over here: > http://www.ext.zx.net.nz/software/notes/kermit95/k95_screen.png > > source & binaries > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-1/ > > with SSH, Kerberos, DECnet, LAT and X/Y/Z modem support disabled. > > Kerberos and SSH support are next on my list of things to get building.The > OpenSSH version string used by Kermit 95 v2.1 (OpenSSH_3.0.2p1+SRP+GSSAPI) > looks like a customised version though. Does this code still exist in a > form that could be released? > Jeff will comment on that. > I'd also like to get the graphical version (k95g.exe) going too. The object > files listed below are all required to build it but the source code that > they're produced from looks to be missing. Its all referred to as KUI stuff > so there may be other headers, etc that are needed too. If there is no Zinc > involved then getting it to build might not be too difficult. > Not worth it. There are a bunch of half-finished dialogs and/or dialogs that are not connected to actions. Anyway, personally, now that it no longer needs to be a revenue generator, I'd just as soon keep it alive as a monument to the power and charm of the text-mode user interface. It is, however, important to get K95G working because, according to Jeff, the console version won't work at all in newer Windows releases. But as you know K95G is text-mode program in a GUI window, not a GUI program. > If it does use Zinc... > It does not. Zinc is only for the Dialer, which can't exist any more. Well, this is the most exciting thing that has happened since I was laid off :-) If nothing else, it'll motivate me to spend more time on Kermit, and the secret to a successful retirement is to keep busy with something you enjoy. - Frank
Date: Sat, 19 Oct 2013 10:14:00 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Oops, I just noticed that COPYING.TXT is missing the copyright notice. Here's the fixed version: ftp://ftp.kermitproject.org/kermit/kermit95/COPYING.TXT - Frank
Date: Sat, 19 Oct 2013 10:52:54 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz> CC: Frank da Cruz <fdc@columbia.edu> Subject: Re: Building Kermit95 David, Answering the questions from your website: ckreg.exe is the Zinc based tool which is used to generate registration keys. You should remove this from the code base. ftp.exe, http.exe, ssh.exe: were similar to the telnet.exe and rlogin.exe wrapper commands. They spawn k95.exe under an alternative name. k95dial.exe is Zinc based. Remove it openssl.exe comes from the OpenSSL distribution srp-*.exe come from the SRP distribution ssh*.exe come from the OpenSSH distribution Kerberos for Windows versions after 2.2 are not backward compatible. MIT's current version is 4.01. However, at this point I would prefer that Heimdal Kerberos 1.6 (not yet released) be used if any Kerberos work is going to be added. KFW 2.2 should not be used because of the vast number of security vulnerabilities. OpenSSL 0.9.7 should not be used because it too has a large number of security vulnerabilities. The current version is 1.0.1 but OpenSSL 1.x is not backward compatible with 0.9.7 so there will need to be careful examination of how the OpenSSL APIs are used to ensure that the behavior required by Kermit is still performed by the calls that are made into OpenSSL. SRP has not been supported since Kermit 95 because I was one of the two individuals to write code for it. There are probably security issues there that need to be addressed. It absolutely needs to be ported to a newer OpenSSL. OpenSSH does not ship as a library. What I did was refactor the entire distribution to be a library that could be loaded dynamically into k95.exe in the countries we were permitted to ship it to. The modified code is covered under the export restrictions imposed on the Kermit 95 product and cannot be released. In any case, OpenSSH has changed so much since 3.0.2p1 that the library I built in 2002 would no longer be useful. That work will need to be performed from scratch. At this point it might be worthwhile trying to use the PuTTY ssh engine instead of OpenSSH. PuTTY has a crappy terminal emulator but it is a better Windows application and Marcus Sundberg's fork contains the GSS KeyEx support that K95 is lacking. I would probably drop the Kerberized Telnet support at this point anyway because it is so insecure. DES service tickets can be cracked in under 24 hours for a cost of US$20 so there really is not point to it. P is a proprietary XYZmodem library. We couldn't use the Omen Technologies or GPL versions. Pathworks and SuperLAT. Commercial products. Zinc. The Zinc sources were extremely buggy and not cross platform. We built K95 for Alpha, MIPS, PowerPC and X86. Zinc required heavy modification to work properly. Can't redistribute the sources. The KUI directory is absolutely required for K95G to be built. Frank will have the find the sources from my Columbia home directory if it is still present. The ckosslc.c is Kermit's OpenSSL crypto library engine that wraps around OpenSSL. The OpenSSH library also requires the OpenSSL crypto engine but because of export restrictions on K95 we had to prevent the ability to modify the crypto. The ssh\ckosslc.c is not the same as the version that provides SSL support. I don't remember what the changes were but they were fairly significant. Again, can't export the ssh\ckosslc.c version because of the export restrictions. Jeffrey Altman
Date: Sat, 19 Oct 2013 11:05:51 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> To: David Goodwin <david@zx.net.nz> CC: Frank da Cruz <fdc@columbia.edu> Subject: Re: Building Kermit95 The KUI bits are also extremely 32-bit Windows specific. If I were starting this over today I would build a UI using Qt. I would also spend my efforts improving the terminal emulation in PuTTY because that program is already widely ported to multiple platforms. Another solution for the SSH problem in K95 is to initiate connections with PuTTY's plink.exe. There really is no reason why K95 needs to have SSH built into the K95 process. It just needs to be able to establish the connections. plink.exe is fine for that.
Date: Sun, 20 Oct 2013 17:07:59 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu> On Sun, Oct 20, 2013 at 3:52 AM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > Kerberos for Windows versions after 2.2 are not backward compatible. > MIT's current version is 4.01. However, at this point I would prefer > that Heimdal Kerberos 1.6 (not yet released) be used if any Kerberos > work is going to be added. KFW 2.2 should not be used because of the > vast number of security vulnerabilities. > > SRP has not bee supported since Kermit 95 because I was one of the two > individuals to write code for it. There are probably security issues > there that need to be addressed. It absolutely needs to be ported to a > newer OpenSSL. > I've been thinking I might just disable Kerberos and SRP support for now as I've no way of testing it. If anyone wants to have a go at it in the future all the old code is still there as a starting point. Plus having working SSH support right now will probably be somewhat more useful to more people. > OpenSSH does not ship as a library. What I did was refactored the > entire distribution to be a library that could be loaded dynamically > into k95.exe in the countries we were permitted to ship it. The > modified code is covered under the export restrictions imposed on the > Kermit 95 product and cannot be released. In any case, OpenSSH has > changed so much since 3.0.2p1 that the library I built in 2002 would no > longer be useful. That work will need to be performed from scratch. At > this point it might be worthwhile trying to use the PuTTY ssh engine > instead of OpenSSH. PuTTY has a crappy terminal emulator but it is a > better Windows application and Marcus Sundberg's fork contains the GSS > KeyEx support that K95 is lacking. > Using PuTTY's plink is an excellent idea - I was not looking forward to the possibility of having to rewrite all the SSH stuff. Probably a lot easier than trying to pull in something like libssh too. I guess much of the code needed to interact with plink could probably be re-used for other local applications as well (such as using Kermit95 as a terminal for cygwin instead of the PuTTY-based mintty application). I would probably drop the Kerberized Telnet support at this point anyway > because it is so insecure. DES service tickets can be cracked in under > 24 hours for a cost of US$20 so there really is not point to it. > That makes things easier - don't have to figure out what libdes is or what to do with it. > The OpenSSH library also requires the OpenSSL crypto > engine but because of export restrictions on K95 we had to prevent the > ability to modify the crypto. The ssh\ckosslc.c is not the same as the > version that provides SSL support. I don't remember what the changes > were but they were fairly significant. Again, can't export the > ssh\ckosslc.c version because of the export restrictions. > I guess if SSH support is going to be redone its not much use then. cknker.exe and k95g.exe don't seem to directly reference it - only the SRP stuff does (and I guess the OpenSSH library). > Jeffrey Altman > Thanks for the info! - David
Date: Sun, 20 Oct 2013 9:25:07 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 > > Meanwhile, at some point I hope you'll try to integrate the latest > > C-Kermit source code: > > > > http://www.kermitproject.org/ckdaily.html > > > > since I'm working on it (off and on) can easily make any required changes. > > It would certainly be nice to bring it up to date. I'm not sure how to go > about doing that though - the code base is quite massive. I was thinking > perhaps the easiest option (for someone like me who doesn't know the > codebase at all) would be to find the nearest vanilla C-Kermit release, do > a diff to try and figure out what exactly had changed for the Kermit95 > integration, then try to port those changes over to C-Kermit 9.0. > Obviously it's best to start with what you have. Once it's working maybe there can be a brief 2.2 release just to let the world know it's not dead. Then copy the whole mess to a fresh directory and put the new C-Kermit modules there (ck[cuw]*.[cwh]: ftp://ftp.kermitproject.org/kermit/test/tar/x.zip replacing the old ones (you can delete all the ckv*.* files, they're for VMS). The files have the same names. Since all the work I have done since 2003 is either platform independent (e.g. the command and scripting language) or specific to Unix or VMS, I would almost be surprised if it didn't "just work". Well maybe that's a tad optimistic, but I don't think it will be as bad as you think, and anyway I'll be here to work out any kinks in that area. Having done that, you can bump the version number to 3.0. > > And as soon as you're comfortble with the idea, I'd like to announce what > > you're doing and host development builds on the new Kermit Project website. > > This way, hopefully, others will pop up and lend a hand. > > Certainly - the more people who know about it the better. I've been hoping > once I've documented the overall build process and got some working > binaries others might join in and fill in some of the gaps left by the old > proprietary bits and obsolete security libraries. I guess we'd want a > release that includes k95g.exe and is slightly better tested than the build > I put together last night though. > Right, the console version is only used by a few diehards who liked the ability to run it fullscreen. > Getting it building with a more modern compiler should also probably be a > high priority as its a fairly big barrier to entry right now (its the > reason why I didn't start doing this work two years ago). Visual C++ 6.0 > and 7.0 both seem to be able to build it right now but they're probably a > little hard for most people to get hold of now. Visual C++ 7.0 is still > available to people with an MSDN subscription but 6.0 isn't (Microsoft > isn't allowed to distribute it because of the whole MS JVM thing). > I'm really an ignoramus about Windows so can't comment. Ideally of course it would be buildable with Open Source tools, but I don't even know if such things exist for Windows. Btw, in case you're wondering why the code is still Copyright Columbia University, that was the decision that was made when they dumped the Kermit Project. In order for the license to be valid there has to be some copyright holder, and Columbia agreed to leave it that way. CU lawyers approved the license and wrote the disclaimer section so if anything goes wrong in the future it's on them. - Frank
Date: Sun, 20 Oct 2013 10:49:49 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 David, I have the Zip file of Jeff's last complete K95 source code set. It's 238MB. Obviously much of it is not for use or publication, all the parts that we do not have rights to, that Jeff listed, so please be careful with those parts: ftp://ftp.kermitproject.org/kermit/tmp4/xx.zip Let me know when you've picked it up so I can remove it from the FTP site. - Frank
Date: Sun, 20 Oct 2013 10:59:14 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz> CC: Frank da Cruz <fdc@columbia.edu> Subject: Re: Building Kermit95 A few more comments on this process: 1. Drop the name K95. K95 is a commercial product with a very specific export license and remaining trademark/copyright issues associated with the publisher of the product. What you are producing is not K95. I suggest that the new name should simply be "C-Kermit". 2. The big difference between C-Kermit 9.0 and previous versions is the support for 64-bit I/O (aka large file support). Before you can modify the cko*.c modules to use the new 64-bit I/O prototypes from CK9 you will need to use a compiler capable of 64-bit builds. VC6 cannot be used for that. 3. I recommend using the free cl.exe version 14.x compilers that shipped with the Windows 7 SDK as a lowest supported version. 4. Create a Git repository on github for this work. github's patchset review is not as good as a Gerrit instance but it is good enough. I won't work on any projects these days that are not stored in Git.
Date: Sun, 20 Oct 2013 11:37:30 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 > A few more comments on this process: > > 1. Drop the name K95. K95 is a commercial product with a very specific > export license and remaining trademark/copyright issues associated with > the publisher of the product. What you are producing is not K95. I > suggest that the new name should simply be "C-Kermit". > Good idea, I agree. Or maybe "C-Kermit for Windows". > 2. The big difference between C-Kermit 9.0 and previous versions is the > support for 64-bit I/O (aka large file support). Before you can modify > the cko*.c modules to use the new 64-bit I/O prototypes from CK9 you > will need to use a compiler capable of 64-bit builds. VC6 cannot be > used for that. > Of course you can also build it without 64-bit support. This will happen by default; you would have to change the makefile (or the ckcdeb.h header file) to make it include 64-bit support for Windows. Then the 64-bit file i/o code can be added later to cko*.[ch] if you (or anybody else) is up for it. More info on this: http://www.kermitproject.org/ckermit90.html#LargeFiles Also see the entry for 29 Dec 2005 here: http://www.kermitproject.org/ckdaily.html plus tons of notes in the current C-Kermit update notes file: ftp://ftp.kermitproject.org/kermit/ckermit/NOTES.TXT starting around 15 Dec 2005. - Frank
Date: Sun, 20 Oct 2013 14:54:38 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Cc: Jeffrey Altman <jaltman@your-file-system.com> Btw, you might want to use the little graphic in the upper left of the Kermit Project page as the new C-Kermit-for-Windows icon, since the previous ones are no longer appropriate: http://www.kermitproject.org/ Here's a full-size version: http://www.kermitproject.org/icon.jpg Which reminds me, I suppose there also has to be some sort of installation procedure. Nothing fancy, need not be graphical, just something sufficient so when Kermit is started it can find its libs, etc. (I'm no expert on Windows installers, but Jeff might have some comments.) I suppose we can't call the executable K95 any more either, which is a good thing. Maybe the new ones can be CKW.EXE and CKWG.EXE? (Jeff would say that a console version shouldn't even be released, which is fine with me, in which case the GUI version could be simply CKW.EXE). In that case, the new version can reside in the same directory as the current K95 installation (if any), which might have some benefits, as you pointed out, and still not require deleting the old version. I guess another consideration for the installer would be to check if there is a KSC file association (which would mean that a version of K95 is already installed) and if so, to ask whether it should be transferred to CKW. - Frank
Date: Sun, 20 Oct 2013 17:36:27 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 > Got it. You can delete it from the FTP server now. > OK, thanks. > I'll keep the entire contents of the zip confidential and send you a list > of any files I need to be publicly available for building k95g.exe (with > the same non-crypto feature set as the current k95.exe test build). For any > further publicly available releases I'll only use the stuff you're able to > put up on kermitproject.org under the BSD license. That should prevent > anything from being used or released that isn't allowed to be. > That selection was mine, but I'm not the expert. For example, I probably could have put the k*.* (KUI) files but didn't think I had to. Anyway when you've got your distribution together it can replace the one I have here. > Hopefully I'll be able to figure out exactly what's needed for k95g.exe > later today after work. > Great. Oh right, you're in Monday already. It's still Sunday here, with the sun shining. Almost impossible to be farther away, right? There's a famous story, you probably heard it, about an American guy who thought he was flying to Oakland and wound up in Aukland. He started to get wise when plane gave no sign of landing after 5, 6, 7, 8.... hours. - Frank
Date: Mon, 21 Oct 2013 12:20:48 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> On Mon, Oct 21, 2013 at 10:36 AM, Frank da Cruz <fdc@columbia.edu> wrote: > > Got it. You can delete it from the FTP server now. > > > OK, thanks. > > > I'll keep the entire contents of the zip confidential and send you a list > > of any files I need to be publicly available for building k95g.exe (with > > the same non-crypto feature set as the current k95.exe test build). For any > > further publicly available releases I'll only use the stuff you're able to > > put up on kermitproject.org under the BSD license. That should prevent > > anything from being used or released that isn't allowed to be. > > > That selection was mine, but I'm not the expert. For example, I probably > could have put the k*.* (KUI) files but didn't think I had to. Anyway when > you've got your distribution together it can replace the one I have here. > Ok, so as long as I stay away from the crypto stuff and proprietary bits (pathworks, p, zinc, superlat) it should be fine. > > Hopefully I'll be able to figure out exactly what's needed for k95g.exe > > later today after work. > > > Great. Oh right, you're in Monday already. It's still Sunday here, with > the sun shining. Almost impossible to be farther away, right? > > There's a famous story, you probably heard it, about an American guy who > thought he was flying to Oakland and wound up in Aukland. He started to get > wise when plane gave no sign of landing after 5, 6, 7, 8.... hours. > Yeah, a long way from anywhere here. Makes network latency quite noticeable - my ISP uses NAT now so if I want to get into my home network a few km away from where I work I have to go via my server in Fremont, CA (which has a VPN connection back to my home network). I can type about 4-5 characters before the first one appears.
Date: Mon, 21 Oct 2013 21:43:37 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 > Sounds good. I might look into how the dialer interacts with the rest of > the program while I wait then - perhaps have a go at putting together a > prototype dialer that can start a new telnet connection or something > against the final v2.1.3 retail binaries. Something very basic like the > PuTTY UI would probably be useful to have for a first open source release > and perhaps not too difficult to build. > The way the Dialer works is, it writes a script for K95 to execute. I'm not real enthusiastic about the Dialer. The only reason we did it was to make K95 commercially viable. "Kermit for dummies". But it's ugly, clunky, annoying, labor intensive (largely because it had be portable to OS/2 and also work within the severe space limitations of Windows 95). Maybe some people actually liked the Dialer but I don't recall anyone saying so. Anyway, I think the most important order of business is to get an up-to-date version of K55G (but called CKW) out. UI, and especially GUI, additions will prove to be rather more complicated than you might expect because of threading issues. Like if you click on some button while Kermit is in the middle of doing something else. Btw, do you have a copy of K95 2.1.3? If so, you can set up and make connections in the Dialer yourself and you can see the script files that are generated. - Frank
Date: Mon, 21 Oct 2013 22:04:19 EDT From: Frank da Cruz <fdc@columbia.edu> To: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Your files > If the files are not readable by you then they are not appropriate for > David. > > You have already given David more than you should have since by giving > him the zip file of the 2.1.3 build tree you have given him the P > modules, the SSH modules, and the Zinc sources. > I gave him the nondisclosure lecture first, I trust him, he won't use or disclose anything he shouldn't. > If David has the 2.2.0 sources which he must since he has said that he > has them, then you have already given him some of the sources I gave you. > There are the sources which you put on my PC in December 2002, and then there are the sources in your .src directory. Some of the files there are as recent as 2007. You fixed a lot of bugs since 2002. I'm just trying to get him a consistent source set he can build from, and preferably the latest such set. The files I was concerned about were in the .src directory. If they are not needed, that's fine. Here are some examples: tar cvf ~/p/tmp/src2007.tar . tar: ./191/ck_old.ico: Cannot open: Permission denied tar: ./191/ckcasc.h: Cannot open: Permission denied tar: ./191/ckcdeb.h: Cannot open: Permission denied (everything in the OS/2 C-Kermit directory, no big deal) tar: ./bebox/ckcfn2.c: Cannot open: Permission denied tar: ./bebox/ckcfn3.c: Cannot open: Permission denied (everything in the Bebox directory, OK...) tar: ./p/dllsrc: Cannot open: Permission denied tar: ./p/exesrc: Cannot open: Permission denied (these are not needed, it's XYZmodem, right?) tar: ./pty/.Sanitize: Cannot open: Permission denied tar: ./oldipf/cker01.ipf: Cannot open: Permission denied ... tar: ./pdll/pdll_common.c: Cannot open: Permission denied ... (This is part of the XYZMODEM code, right?) tar: ./telnetd/ANSI.DEF: Cannot open: Permission denied (Telnetd, don't need that...) tar: ./zip/ck111.zip: Cannot open: Permission denied tar: ./zip/ck112.zip: Cannot open: Permission denied (I guess these are zipped K95 distributions? OK, not needed.) tar: ./zinc/k95dial.mak: Cannot open: Permission denied tar: ./zinc/ck_old.ico: Cannot open: Permission denied (And Zinc, not needed.) How about the following? They are not needed?... (Just showing one line for each subdirectory): tar: ./isdll/test.c: Cannot open: Permission denied tar: ./lib/os2: Cannot open: Permission denied tar: ./ftp/makefile: Cannot open: Permission denied tar: ./ssh/openbsd-compat: Cannot open: Permission denied tar: ./k95isdll/test.c: Cannot open: Permission denied tar: ./k95dll/k95dll.c: Cannot open: Permission denied I just happened to notice when I went zip the .src directory and it failed: tar: Exiting with failure status due to previous errors I don't know what everything is. If you're saying the things that are not protected from me are necessary and sufficient to do a build (without Xyzmodem, LAT, Kerberos, Zinc, etc), that's fine; I'll find a way to make an archive of the parts that are unprotected. Jeff, You can be as involved or uninvolved in this as you want. Just let me know. I know you have a new life now and lots of pressure. If you don't want to be involved or answer questions, just say so and I'll do best I can with David. In any case, do you want to see if I can get your Columbia login reinstated? I might be able to. - Frank
Date: Mon, 21 Oct 2013 10:04:55 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu> On Mon, Oct 21, 2013 at 3:59 AM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > A few more comments on this process: > > 1. Drop the name K95. K95 is a commercial product with a very specific > export license and remaining trademark/copyright issues associated with > the publisher of the product. What you are producing is not K95. I > suggest that the new name should simply be "C-Kermit". > > 2. The big difference between C-Kermit 9.0 and previous versions is the > support for 64-bit I/O (aka large file support). Before you can modify > the cko*.c modules to use the new 64-bit I/O prototypes from CK9 you > will need to use a compiler capable of 64-bit builds. VC6 cannot be > used for that. > > 3. I recommend using the free cl.exe version 14.x compilers that shipped > with the Windows 7 SDK as a lowest supported version. > Yeah, VC6 needs to go. Its a pain having to do work in a VM and its not widely available which will prevent others helping out on this project. cknker.exe at least seems to build fine on VC7 at the moment so newer compilers might not be too much work. > 4. Create a Git repository on github for this work. github's patchset > review is not as good as a Gerrit instance but it is good enough. I > won't work on any projects these days that are not stored in Git. > Yeah. As much as I like Mercurial I think Git is the correct choice for this. Can't argue with githubs market share.
Date: Mon, 21 Oct 2013 10:03:40 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> On Mon, Oct 21, 2013 at 2:25 AM, Frank da Cruz <fdc@columbia.edu> wrote: > > > Meanwhile, at some point I hope you'll try to integrate the latest > > > C-Kermit source code: > > > > > > http://www.kermitproject.org/ckdaily.html > > > > > > since I'm working on it (off and on) can easily make any required > > > changes. > > > > It would certainly be nice to bring it up to date. I'm not sure how to go > > about doing that though - the code base is quite massive. I was thinking > > perhaps the easiest option (for someone like me who doesn't know the > > codebase at all) would be to find the nearest vanilla C-Kermit release, do > > a diff to try and figure out what exactly had changed for the Kermit95 > > integration, then try to port those changes over to C-Kermit 9.0. > > Obviously it's best to start with what you have. Once it's working maybe > there can be a brief 2.2 release just to let the world know it's not dead. > > Then copy the whole mess to a fresh directory and put the new C-Kermit > modules there (ck[cuw]*.[cwh]: > > ftp://ftp.kermitproject.org/kermit/test/tar/x.zip > > replacing the old ones (you can delete all the ckv*.* files, they're for > VMS). The files have the same names. Since all the work I have done since > 2003 is either platform independent (e.g. the command and scripting > language) or specific to Unix or VMS, I would almost be surprised if it > didn't "just work". Well maybe that's a tad optimistic, but I don't think > it will be as bad as you think, and anyway I'll be here to work out any > kinks in that area. > > Having done that, you can bump the version number to 3.0. Sounds like a good plan. V3.0 can include the latest C-Kermit code, a brand new dialer and more modern compiler support. > > > And as soon as you're comfortble with the idea, I'd like to announce > > > what you're doing and host development builds on the new Kermit > > > Project website. This way, hopefully, others will pop up and lend a > > > hand. > > > > Certainly - the more people who know about it the better. I've been hoping > > once I've documented the overall build process and got some working > > binaries others might join in and fill in some of the gaps left by the old > > proprietary bits and obsolete security libraries. I guess we'd want a > > release that includes k95g.exe and is slightly better tested than the build > > I put together last night though. > > > Right, the console version is only used by a few diehards who liked the > ability to run it fullscreen. > I had noticed it misbehaves a bit on Windows XP. If you Ctrl+C it while its busy trying to connect it seems to take over the console window and make a bit of a mess. > > Getting it building with a more modern compiler should also probably be a > > high priority as its a fairly big barrier to entry right now (its the > > reason why I didn't start doing this work two years ago). Visual C++ 6.0 > > and 7.0 both seem to be able to build it right now but they're probably a > > little hard for most people to get hold of now. Visual C++ 7.0 is still > > available to people with an MSDN subscription but 6.0 isn't (Microsoft > > isn't allowed to distribute it because of the whole MS JVM thing). > > > I'm really an ignoramus about Windows so can't comment. Ideally of course > it would be buildable with Open Source tools, but I don't even know if > such things exist for Windows. > There is GCC for windows (MinGW) which I typically use. I guess all the C-Kermit bits will probably compile fine with this so it would just be the makefile and windows-specific bits that need to be dealt with. > Btw, in case you're wondering why the code is still Copyright Columbia > University, that was the decision that was made when they dumped the > Kermit Project. In order for the license to be valid there has to be some > copyright holder, and Columbia agreed to leave it that way. CU lawyers > approved the license and wrote the disclaimer section so if anything goes > wrong in the future it's on them. > Yeah, that's quite reasonable. Can't have a copyright license without copyright. I've updated the file on my ftp server so it should now be current.
Date: Mon, 21 Oct 2013 12:01:45 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 > Anyway, I've had a dig through that source code. The good news is I can see > how all the K95G stuff works at a very high level at least. And how it > should all be built. > > The bad news is that the source appears to be for Kermit 95 v2.1.3 (or > something fairly close to it). There were quite a few changes in v2.2 which > makes the v2.1 KUI code incompatible. Its version of C-Kermit looks to have > been slightly updated too - ckcdeb.h has macros for detecting IA-64 > OpenVMS and a bunch of stuff about long file support. The file is dated > 24-DEC-2005. > I forwarded your message to Jeff to see what he says. I have no idea. I would have thought that it was a consistent code set. > Are you able to track down the KUI directory from the v2.2 codebase? I > think if I can drop that into place then the v2.2 k95g.exe should build > first (or second) try. > The only other thing I have is a somewhat older source set, from December 2002, just when 2.1.3 was about to be released. It's on a VM that is a copy of my XP system from those days. It took me about an hour to get into the VM; it is extremely slow. I'm trying to Zip the source set, but it has been hours and has barely even started. VMware freezes all the time; about 10 files are zipped, then the thing sleeps for 20 minutes, wakes up, zips a few more files, goes back to sleep, etc. I'll let it run all day and see what happens. I'm not optimistic. Before trying to Zip the source tree I tried transferring it out of VMware to the host PC, but that was even worse -- VMware froze solid before we were even 1% into the transfer. - Frank
Date: Mon, 21 Oct 2013 12:26:06 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Well, after all that complaining I was able to Zip just the KUI directory (as you asked), and you can pick it up here: http://www.columbia.edu/~fdc/tmp/kui.zip I hope this does the trick. The whole source tree will be a much bigger production. - Frank
Date: Mon, 21 Oct 2013 16:38:45 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 > I had a quick go at building with that KUI stuff before work but it doesn't > get any further. Still lots of undefined stuff, missing functions, struct > _kui_init missing members (v2.2 has a couple of new ones at the end), etc. > Since I last wrote, I spent 5 or 6 hours trying to Zip the whole Kermit tree. The entire source tree looks like this: infozip 32MB kerberos 311MB kermit 158MB openssl 70MB pwsdk 5MB srp 49MB superlat 139MB zinc 33MB So I what I zipped this time is the Kermit subtree: http://www.columbia.edu/~fdc/tmp/kui.zip The zipfile is about 67MB. Omitting Info-Zip, Kerberos, etc, made a big difference, but it still took 5 or 6 tries and many reboots (it takes like 10 minutes to open a CMD window or start K95). I am pretty sure this source tree is exactly the one that was used to build 2.1.3. > If the KUI directory from the same place as the v2.2 code on the website > can't be found then I guess the first release of this Kermit95 descendant > will have to be based on v2.1.3. Probably some of the v2.2 fixes that were > present in the console version too could be back-ported at some point but > any upgrades specific to the GUI version will be lost. > Let's see if this new Zip file helps. If you think you need anything from the source tree I'll try to get it. Oops, wait, I think I just found something! But I have to go pick up the laundry, I'll get back to you later today (local time). Can you handle a tar.gz file instead of Zip?
Date: Mon, 21 Oct 2013 19:43:37 EDT From: Frank da Cruz <fdc@columbia.edu> To: Jeffrey Altman <jaltman@your-file-system.com> Subject: Your files Jeff, I discovered that your directory is still on Cunix after all, including the .src directory. Your login ID is gone but the files are still there. Three questions: . Would you guess that the files in the .src tree are consistent? . Many of the files and subdirectories are read-protected and I can't copy them. Do you consent that I request to get the permissions changed so I have read access? . Would any of your other directories possibly be of use or interest to David? Here they are: drwx------ 4096 1998-04-19 13:39:57 .Data drwxr-xr-x 4096 2001-07-24 11:50:46 .dt drwxrwx--- 4096 2003-10-03 14:53:08 .emacs.d drwx------ 4096 1998-04-19 13:40:15 .emacs.lib drwx------ 4096 1998-02-07 19:21:27 .iscreen drwxrwx--- 4096 2002-12-03 14:44:53 .java drwx------ 4096 2001-05-14 10:12:32 .ncftp drwxr-xr-x 28672 2005-08-28 09:36:41 .src drwx------ 4096 2001-12-22 10:31:25 .ssh drwxrwx--- 4096 2003-03-24 16:32:49 .timesheet.d drwx------ 4096 2004-03-12 21:45:34 .tin drwxrwxr-x 4096 2011-05-31 04:07:32 3270 drwxrwxr-x 4096 2011-05-31 04:08:52 ASP drwxrwx--- 4096 1999-07-22 12:13:20 BEBOX drwxrwx--- 4096 1999-07-22 12:13:23 CE drwxrwx--- 4096 1999-07-22 12:13:25 Crypto drwxrwx--- 4096 1998-04-19 13:40:13 DOCS drwxrwx--- 4096 1998-05-05 14:52:56 EMULEX drwxrwx--- 4096 1999-07-22 12:13:19 FIDONET drwxrwx--- 4096 1998-04-10 17:22:54 FTPSRC drwxr-xr-x 4096 1998-11-12 13:50:51 HAMILTON drwxrwx--- 4096 2000-02-10 15:41:30 HPUX drwxrwx--- 4096 1999-01-21 00:56:05 ICONS drwxrwx--- 4096 2001-05-14 10:12:26 INFERNO drwxrwxr-x 4096 2001-12-14 18:17:32 INFOZIP drwxrwx--- 4096 2002-02-06 16:45:15 JVM-Launch drwxrwx--- 4096 1998-04-10 17:22:50 LK450 drwxrwx--- 4096 1998-04-10 17:22:53 LOGS drwxrwxr-x 4096 1998-04-10 17:22:51 LWP_OS2 drwxrwx--- 4096 1996-10-20 19:16:58 MACINTOSH drwxr-xr-x 4096 1997-04-08 13:30:57 MDK drwxrwx--- 4096 1999-07-22 12:14:02 MERIDIAN drwxrwx--- 4096 1999-07-22 12:13:21 MM drwxr-xr-x 4096 1997-09-17 18:01:39 MODEMS drwxr-x--- 4096 2003-10-23 09:24:47 Mail drwxr-xr-x 4096 1998-04-19 13:40:14 NASI drwx---rwx 4096 1997-08-25 13:21:56 Network Trash Folder drwxrwxr-x 12288 2002-10-08 07:16:57 News drwxrwx--- 4096 1997-08-20 17:56:05 OOB_BUG drwxrwx--- 4096 2000-01-10 17:08:28 OS2 drwxrwxr-x 4096 1998-04-19 13:39:58 OS2STUFF drwxrwx--- 4096 1999-07-22 12:13:26 OS2TCPIP drwxrwx--- 4096 1997-09-23 23:18:08 PATCH40 drwxrwx--- 4096 1998-04-10 17:22:54 PGP drwxrwx--- 4096 1996-09-10 10:57:47 PHD drwxrwx--- 4096 1996-11-13 10:17:50 PKZIP drwxrwx--- 4096 1996-10-10 19:25:27 PLAN9 drwxrwx--- 4096 2001-05-14 10:12:16 RAS95 drwxrwxr-x 4096 1997-08-20 18:20:50 RSE drwxrwx--- 4096 1999-11-02 23:34:08 RTPATCH drwxrwx--- 4096 1999-07-22 12:13:25 SAMBA drwxrwxr-x 4096 2001-05-14 10:12:32 SOCKS drwxrwx--- 4096 1999-07-22 12:13:26 SPEECH drwxrwx--- 4096 1998-03-22 22:58:01 SRC drwxr-xr-x 4096 1999-07-22 12:13:06 STTNG drwxrwx--- 4096 2001-05-14 10:12:33 STUFFIT drwxrwx--- 4096 1996-12-09 09:45:58 TANENBAUM drwx------ 4096 1998-04-10 17:22:38 TAPI drwxrwx--- 4096 1999-07-22 12:13:25 THINKPAD drwxrwx--- 4096 1997-05-09 22:13:29 TURBOCOM drwxrwx--- 4096 1999-04-01 14:48:46 UIUC drwxrwx--- 4096 1998-04-10 17:22:49 VACPP drwxrwx--- 4096 2005-04-07 09:51:33 VTTEST drwx------ 4096 2001-05-14 10:12:19 WIN95 drwxrwx--- 4096 1997-05-17 14:30:18 WINNT drwxrwxr-x 4096 2000-03-24 14:14:50 XWINPRO drwxr-xr-x 4096 1998-04-19 13:40:17 ZAF5 drwxrwx--- 4096 1998-04-19 13:40:17 ZINC drwxrwx--- 4096 1997-11-23 16:48:26 ZIP drwx------ 4096 1998-04-10 17:22:53 aix drwxrwx--- 4096 1999-07-22 12:07:42 better_telnet drwxrwxr-x 4096 2000-08-29 12:08:10 bin drwxrwx--- 4096 1998-03-10 01:00:48 blowfish drwxr-xr-x 4096 2003-01-28 14:46:09 evarts drwxr-xr-x 8192 2003-12-31 01:33:32 fdc drwxrwx--- 4096 2002-02-06 16:45:43 foo drwxrwxrwx 16384 2003-12-17 11:45:10 fromfdc drwxrwxr-x 4096 1999-07-22 12:13:14 ftp drwxrwx--- 4096 1999-12-22 01:20:10 gkermit drwxrwx--- 4096 2002-12-03 14:44:45 iamDeveloping drwxrwxr-x 4096 1997-08-20 17:56:05 incoming drwxrwxr-x 4096 1997-08-25 13:22:45 invalidFATdirectory drwxrwxr-x 4096 1996-06-17 13:44:39 isv drwxrwx--- 4096 2003-10-31 02:09:01 lib drwx------ 4096 2005-12-01 23:11:37 mail drwxrwxr-x 4096 1997-08-20 17:56:06 novell drwxrwx--- 4096 2001-05-14 10:12:31 os2exe drwxrwx--- 4096 1999-07-09 10:04:12 pirated-copies-of-k95 drwxrwxr-x 8192 2007-01-25 20:37:20 public_html drwxrwxr-x 4096 1997-08-25 13:22:47 savant.com drwx------ 4096 1996-12-06 16:38:54 terminfo drwxrwxr-x 4096 2001-12-14 21:33:43 watsol drwxrwxr-x 28672 2003-11-21 12:24:31 wermit drwx------ 4096 2002-03-22 11:51:44 zinc Thanks, Frank
Date: Mon, 21 Oct 2013 19:50:05 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 It turns out that Jeff's login directory at Columbia was still online, though hidden. I don't have access to all the pieces we need, though I can see they are there. I need to get Jeff's permission and then I need to get the sysadmins at Columbia to give me access. This might take a day or two. (He can't log in to it either because he's no longer in the Columbia user database.) Anyway, I *think* that there might be a coherent source set from 2007 there, but we'll never know until we try. I'll get back to you as soon as I have news. - Frank
Date: Tue, 22 Oct 2013 13:06:39 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Sounds good. I might look into how the dialer interacts with the rest of the program while I wait then - perhaps have a go at putting together a prototype dialer that can start a new telnet connection or something against the final v2.1.3 retail binaries. Something very basic like the PuTTY UI would probably be useful to have for a first open source release and perhaps not too difficult to build.
Date: Mon, 21 Oct 2013 21:19:54 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: Frank da Cruz <fdc@columbia.edu> Subject: Re: Your files Frank, If the files are not readable by you then they are not appropriate for David. You have already given David more than you should have since by giving him the zip file of the 2.1.3 build tree you have given him the P modules, the SSH modules, and the Zinc sources. If David has the 2.2.0 sources which he must since he has said that he has them, then you have already given him some of the sources I gave you. Jeffrey Altman
Date: Thu, 21 Nov 2013 23:45:39 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: ANONYMOUSCODER Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> I've just completed a fresh build for testing if anyone is interested in having a look. Changes from the last one are: * The program now refers to itself as just "Kermit" (or "Kermit for Windows and OS/2" when mentioned in the context of other Kermit editions). - User agents are still "Kermit 95" - I don't see any point in changing them as that's what this program is compatible with (IE still has Mozilla in its user agent after all). - There are still K-95 references around (including the command prompt and title bar). The title bar one should probably change, I don't know about the command prompt. Anyone have any strong feelings about this? * Version number has been bumped to 3.0 * Fixed Jeffs organisation ("IAM Consulting" -> "Secure Endpoints Inc.") where ever it appeared * Removed border around buttons in GUI dialogs (aside from being smaller than usual they look normal now) * Bumped copyright date to 2013 where ever I noticed it * Rewrote the text in the NEWS screen. It now lists the features no longer available in addition to any new features (not many yet - I'll have to go through the v2.2 changes file sometime and pick anything interesting out of it) * Cleaned out the SUPPORT screen to indicate there is none now * Adjusted most (all?) URLs to point to the new kermitproject.org website * Ripped out a big chunk of old license enforcement (registration) code. While it wasn't really doing anything before (I had deleted the contents of the functions that checked the license and printed out its info) it was still a pile of dead code hanging around that didn't need to be there. Chances are I've missed some of it but most of it should be gone now. Anyway, the build is available below and source code is up on https://github.com/davidrg/ckwin as usual. As I don't have an installer yet to deal with CRT issues this build was just done with Visual C++ 6 to eliminate that little headache for now. You should just be able to run it directly on anything relatively modern without having to download some Visual C++ runtime installer. http://ftp2.zx.net.nz/pub/Kermit95/test_builds/3_0-21-nov-2013/winkermit-3.0-test-21-nov-2013-vc6.zip Still on my to-do list for an initial no-ssh alpha release: * Re-enable zlib * Build an installer * Testing * Release notes * Probably other stuff I've forgotten. Can anyone think of anything in particular that needs to be done make the next build suitable for a more public release? Any further changes to be made to the NEWS and SUPPORT screens? Any other similar screens I've missed? Also, does anyone think its worthwhile re-enabling SSL using the old 0.9.7 OpenSSL release? It could be a while before upgrading to a newer version happens - especially if I can't find any documentation that clearly describes any breaking changes between each release. I had a go at applying in ANONYMOUSCODER's GCC patches but ran into a few difficulties so I'll have to have a closer look at them later. In particular farproc.patch caused Visual C++ to generate a lot of warnings (according to http://support.microsoft.com/kb/117428 FARPROC can cause problems when compiling with a C++ compiler instead of straight C - perhaps that was what GCC was doing?) and git was unable to apply jwt.patch against ckotio.c and ckosslc.c for the revision in source control that should match what was originally released on the kermit website (I might have just modified those files at some point before importing everything into source control - will have to get out a diff tool and have a closer look). - David
Date: Tue, 22 Oct 2013 01:01:22 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: Frank da Cruz <fdc@columbia.edu> Subject: Re: Your files On 10/21/2013 10:04 PM, Frank da Cruz wrote: > I'm just trying to get him a consistent source set he can build from, > and preferably the latest such set. If there is such a set they would all be in one place not scattered across the globe. > The files I was concerned about were in the .src directory. If they > are not needed, that's fine. Here are some examples: > tar cvf ~/p/tmp/src2007.tar P xyzmodem -- cannot be shared. > tar: ./191/ck_old.ico: Cannot open: Permission denied > tar: ./191/ckcasc.h: Cannot open: Permission denied > tar: ./191/ckcdeb.h: Cannot open: Permission denied > (everything in the OS/2 C-Kermit directory, no big deal) C_Kermit OS/2 191 > tar: ./bebox/ckcfn2.c: Cannot open: Permission denied > tar: ./bebox/ckcfn3.c: Cannot open: Permission denied > (everything in the Bebox directory, OK...) Bebox irrelevant > tar: ./p/dllsrc: Cannot open: Permission denied > tar: ./p/exesrc: Cannot open: Permission denied >=20 > (these are not needed, it's XYZmodem, right?) xyzmodem > tar: ./pty/.Sanitize: Cannot open: Permission denied > tar: ./oldipf/cker01.ipf: Cannot open: Permission denied > ... > tar: ./pdll/pdll_common.c: Cannot open: Permission denied > ... > (This is part of the XYZMODEM code, right?) xyzmodem > tar: ./telnetd/ANSI.DEF: Cannot open: Permission denied > (Telnetd, don't need that...) nope > tar: ./zip/ck111.zip: Cannot open: Permission denied > tar: ./zip/ck112.zip: Cannot open: Permission denied > (I guess these are zipped K95 distributions? OK, not needed.) > tar: ./zinc/k95dial.mak: Cannot open: Permission denied > tar: ./zinc/ck_old.ico: Cannot open: Permission denied > (And Zinc, not needed.) correct > How about the following? They are not needed?... > (Just showing one line for each subdirectory): > tar: ./isdll/test.c: Cannot open: Permission denied install shield -- useless > tar: ./lib/os2: Cannot open: Permission denied os2 -- most likely the os2 kerberos port > tar: ./ftp/makefile: Cannot open: Permission denied don't care > tar: ./ssh/openbsd-compat: Cannot open: Permission denied don't care > tar: ./k95isdll/test.c: Cannot open: Permission denied install shield > tar: ./k95dll/k95dll.c: Cannot open: Permission denied plugin dll for k95d > I just happened to notice when I went zip the .src directory > and it failed: > > tar: Exiting with failure status due to previous errors > > I don't know what everything is. If you're saying the things > that are not protected from me are necessary and sufficient to > do a build (without Xyzmodem, LAT, Kerberos, Zinc, etc), that's > fine; I'll find a way to make an archive of the parts that are > unprotected. What I'm saying is that if the files weren't shared with you then they weren't meant to be. So please don't go around the permissions that were set. > Jeff, You can be as involved or uninvolved in this as you want. > Just let me know. I know you have a new life now and lots of > pressure. If you don't want to be involved or answer questions, > just say so and I'll do best I can with David. David was doing just fine. My opinion is that your efforts to throw random things at him is just going to confuse him and make it more difficult to move forward. He has at least six months of effort necessary just to get a build that can be built from modern tools. There is no point discussing the merge of the C-Kermit 9.0 sources, or installers, or new GUIs. As you are aware I am extremely busy with my companies and my customers. I am happy to answer questions and assist David. I've already told him what steps he needs to follow to make progress. How about just letting him do so. When he has a git repository that is accessible from elsewhere additional source files can be merged in as they are found. > In any case, do you want to see if I can get your Columbia login > reinstated? I might be able to. No thank you. There is nothing at Columbia that I require. At the point formatting the disk would be the best thing to do. Thanks. Jeff
Date: Tue, 22 Oct 2013 01:13:04 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> Subject: Re: Building Kermit95 As opposed to throwing zip and tar files around, David please setup the git repository and then as new file versions are found they can be committed to the repository on a branch so that the file differences are not lost. There is no point trying to replicate the Kermit development processes of the 1980s. You can obtain the Windows Git tools from http://git-scm.com/download/win You should install a version of PuTTY first and use that for SSH with Git. I recommend Marcus Sundberg's port https://marcussundberg.com/putty/ because it works with Heimdal Kerberos and has 64-bit support and all of my fixes. The Windows 7 SDK with compilers can be obtained from http://www.microsoft.com/en-us/download/details.aspx?id=3138 You should be able to build the C-Kermit sources with that. The Kerberos support should be ported to the Heimdal SDK but that is going to be a lot of effort so it should wait until after the ssh functionality is replaced by a pipe to PuTTY's plink.exe as a child process. Back in 2003 there were no application manifests and no side-by-side assemblies so none of that is supported in the cknker.mak file. That support will need to be added. I also recommend adding support for a Microsoft Symbol Server and Code Signing Certs. See the Heimdal repository on github.com/heimdal/heimdal for examples of how that should be done. Jeffrey Altman
Date: Tue, 22 Oct 2013 23:41:10 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> On Tue, Oct 22, 2013 at 2:43 PM, Frank da Cruz <fdc@columbia.edu> wrote: > > Sounds good. I might look into how the dialer interacts with the rest of > > the program while I wait then - perhaps have a go at putting together a > > prototype dialer that can start a new telnet connection or something > > against the final v2.1.3 retail binaries. Something very basic like the > > PuTTY UI would probably be useful to have for a first open source release > > and perhaps not too difficult to build. > > > The way the Dialer works is, it writes a script for K95 to execute. > > I'm not real enthusiastic about the Dialer. The only reason we did > it was to make K95 commercially viable. "Kermit for dummies". But it's > ugly, clunky, annoying, labor intensive (largely because it had be > portable to OS/2 and also work within the severe space limitations of > Windows 95). Maybe some people actually liked the Dialer but I don't > recall anyone saying so. > I like what the dialer lets me do - setup details for whatever I'm connecting to without having to consult the manual. I don't like the way it makes me do it though - the way everything is spread over 12 separate windows is irritating. I don't use it as much as I used to but its still useful sometimes. It would be more useful if it could be pinned to the taskbar and supported the jump list feature in Windows 7 like PuTTY does. > Anyway, I think the most important order of business is to get an > up-to-date > version of K55G (but called CKW) out. > > UI, and especially GUI, additions will prove to be rather more complicated > than you might expect because of threading issues. Like if you click on > some button while Kermit is in the middle of doing something else. > > Btw, do you have a copy of K95 2.1.3? If so, you can set up and make > connections in the Dialer yourself and you can see the script files that > are generated. > Yeah - picked up a copy around 2010 I suppose. Prior to that I was using a mix of PuTTY and TerraTerm. IIRC TerraTerm was something to do with needing to send massive license scripts to a VMS box slowly (to not trigger errors) over a serial line because networking needs a license. Every year because don't use the system often enough to remember to do it before the old licenses expire.
Date: Tue, 22 Oct 2013 9:08:06 EDT From: Frank da Cruz <fdc@columbia.edu> To: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Your files > P xyzmodem -- cannot be shared. > Right, David knows that, he won't use it. > > tar: ./isdll/test.c: Cannot open: Permission denied > > tar: ./k95isdll/test.c: Cannot open: Permission denied > > install shield -- useless > Aha. > David was doing just fine. My opinion is that your efforts to throw > random things at him is just going to confuse him and make it more > difficult to move forward. > I'm doing my best. I don't know a lot of things that only you know. The first set of sources I put together was evidently inconsistent. Plus I didn't realize the kui modules were actually used in the real build. And then when I sent them to him they didn't match the other source he had. You could do a better job than I could, but I know you can't devote the time. Plus the files were never intended for open distribution, so forbidden things are mixed in with things that can be open. I did my best to document this on the new website: http://www.kermitproject.org/k95source.html I've found several different source sets, and I'm not equipped to evaluate them myself for consistency. Then yesterday I stumbled on the "last" one, your .src directory, which, in the best case, could turn out to be the best one. I remember you were still making builds for Vace and a few of the bulk licensees several years after 2.1.3 was released and hopefully those sources were used with your last build. > He has at least six months of effort necessary just to get a build that > can be built from modern tools. There is no point discussing the merge > of the C-Kermit 9.0 sources, or installers, or new GUIs. > I'm trying to discourage him from doing too much at once but I'm not so pessimistic about integrating C-Kermit 9.0. Most of the work I've done since 2002 is either platform-independent or well isolated. > As you are aware I am extremely busy with my companies and my customers. > I am happy to answer questions and assist David. I've already told him > what steps he needs to follow to make progress. How about just letting > him do so. > > When he has a git repository that is accessible from elsewhere > additional source files can be merged in as they are found. > > > In any case, do you want to see if I can get your Columbia login=20 > > reinstated? I might be able to. > > No thank you. There is nothing at Columbia that I require. At the > point formatting the disk would be the best thing to do. > OK, sorry to piss you off. Thanks for helping. You will always be known as a major author of this software, and to me it's an enormous accomplishment. It was never going to be mass market, but I think it will fill an important niche for many years to come, especially if the open version can be released. Thanks again, - Frank
Date: Tue, 22 Oct 2013 9:56:25 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Cc: Jeffrey Altman <jaltman@your-file-system.com> > I like what the dialer lets me do - setup details for whatever I'm > connecting to without having to consult the manual. I don't like the way > it makes me do it though - the way everything is spread over 12 separate > windows is irritating. > There's a history to that. At first the Dialer was a notebook with tabs, as you would expect. But there was some limitation in Windows 95 that was exceeded when we added new pages to the notebook, e.g. for security options. The non-notebook version of the Dialer was extremely unsatisfying. > I don't use it as much as I used to but its still useful sometimes. It > would be more useful if it could be pinned to the taskbar and supported > the jump list feature in Windows 7 like PuTTY does. > Except I don't think we want to make it require Windows 7, right? Most sites probably haven't even "upgraded" from XP. Here's a page you might not have seen that might be useful: http://www.kermitproject.org/k95beta.html Despite the enormous response to this page and thousands of people who filled in the survey, Columbia blocked us from producing a new release. It's a long, sad story. I don't know if you remember when universities were hotbeds of software development, the golden age from about the mid-1970s to the mid 1990s. But as universities became more corporate, they put a stop to all this for reasons that can be inferred: liability, the "brand" and corporate image of the university, and (I'd venture) the intrinsic anti-corporate stance of many of the software development projects. > > Btw, do you have a copy of K95 2.1.3? If so, you can set up and make > > connections in the Dialer yourself and you can see the script files that > > are generated. > > Yeah - picked up a copy around 2010 I suppose. Prior to that I was using a > mix of PuTTY and TerraTerm. IIRC TerraTerm was something to do with needing > to send massive license scripts to a VMS box slowly (to not trigger errors) > over a serial line because networking needs a license. Every year because > don't use the system often enough to remember to do it before the old > licenses expire. > Kermit 95 is pretty nice, I have to admit. My main interest in this is to get a new version out, and that it be up to date with respect to C-Kermit, and can be easily updated as C-Kermit evolves. All the rest is up to you and Jeff. Just be aware that Jeff's time is extremely limited, whereas I have unlimited amounts of spare time and am ready to help in any way I can. I did succeed yesterday in finding a 2007-vintage source archive which I have hopes of being consistent. It includes all of the fixes that Jeff made after the 2.1.3 release. Jeff doesn't want me to send it now it but at some point you'll need that code so let me know when you're ready. As he says, the first step is for you to set up the Git repository (whatever that is, I'm not real big on source control systems), so I'll just wait to hear from you what you need, or what questions you have. By the way, welcome to the Kermit Project! - Frank
Date: Tue, 22 Oct 2013 10:08:40 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Btw, I think I put the wrong URL for the 2002 source archive I sent you yesterday. It should have been: http://www.columbia.edu/~fdc/tmp/kermit.zip 61.7MB. - Frank
Date: Tue, 22 Oct 2013 17:29:43 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 > It is certainly still too soon to drop XP support entirely. Google > is still supporting it for Chrome for another two years IIRC. > Good. I have a feeling XP is going be around for a very long time, even though MS has EOL'd it. It's monstrous enough, but Vista, 7, and 8 make it look like an early version of Unix in comparison. > > My main interest in this is to get a new version out, and that it be up > > to date with respect to C-Kermit, and can be easily updated as C-Kermit > > evolves. All the rest is up to you and Jeff. Just be aware that Jeff's > > time is extremely limited, whereas I have unlimited amounts of spare > > time and am ready to help in any way I can. > > Yeah - my spare time can be a bit limited too. I'm hoping to get it all > compiling with a modern and free-er compiler like the one Jeff mentioned > sometime soonish, then it should be a lot easier for more people to get > involved. There is a public holiday coming up so I might get a day or so to > work on it then. Once that's done you could probably work on the C-Kermit > bits of C-Kermit for Windows without too much difficulty if you feel like > it. For any Win32 stuff you encounter, the Win32 API is documented over on http://msdn.microsoft.com/en-us/library/windows/desktop/hh447209(v=vs.85).aspx > but finding things can be a bit difficult at times. I usually try to avoid > Win32 development where possible (Qt provides a much nicer API and its not > tied to windows) so I still find myself looking up a lot of stuff on MSDN. > I have actually written Windows programs... well, one, the original K95 pre-Installshield text-mode setup.exe. The APIs are not that hard to deal with but I don't have any Windows tools on my computer. If we start working together I can order whatever is needed. > > ...the first step is for you to set up the Git repository (whatever > > that is, I'm not real big on source control systems), so I'll just wait > > to hear from you what you need, or what questions you have. > > The git repo with the v2.2 code is all setup and ready to go. All I need > now is the 2007-vintage KUI directory which I'm ready for any time (the > rest of the v2.2 code looks ok and the console version builds fine). > I think for now I'll just put the newer KUI files where you can find them. My aversion to source control systems is that so many programmers become fixated on them and use up so much time learning and dealing with them, and then they vanish, and a new one comes along and the process repeats, endlessly. I think I must have watched 50 generations of them come and go and I think of all time I would have wasted if I had tried to keep up with them. I'm a geezer, I know. But OK, if we start working together I'll deal with it. Anyway it turns out the newest files in the kui directory are from April 2005. Later changes were in other areas. For some reason the zip file for the 2005 kui directory is only 1/10 the size of the previous one: http://www.columbia.edu/~fdc/tmp/kui2005.zip The archive contains a mixture of text and binary files, but each file should be in appropriate format for Windows (becaused I transferred them from Unix to Windows with Kermit, which does the conversions automatically). The old icons are included; we'll need to replace before going public. I also have the C-Kermit sources that go with these kui files, in case you need them. Let me know. Thanks, - Frank
Date: Tue, 22 Oct 2013 19:12:33 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 > I think ultimately it should be possible to build everything with > freely-available stuff. The Windows SDK that Jeff linked to has the > compiler and everything else required. Might be worth adding support for > GCC sometime too. > What I find appalling is how tools, including certain compilers, keep changing and breaking programs in languages that should be well-defined. Well, I'll grant that C is anything but well-defined, but still... At least in Unix, gcc is pretty good about stability. > > Anyway it turns out the newest files in the kui directory are from > > April 2005. Later changes were in other areas. For some reason the zip > > file for the 2005 kui directory is only 1/10 the size of the previous one: > > > > http://www.columbia.edu/~fdc/tmp/kui2005.zip > > That looks to be what I need. struct _kui_init in ikui.h has the extra 6 > members which is what the rest of the 2.2 code expects. Should just slot > into place and if all goes well we might have the graphical version later > tonight. > That would be terrific. I'm glad you popped up! - Frank
Date: Wed, 23 Oct 2013 09:48:21 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> On Wed, Oct 23, 2013 at 2:56 AM, Frank da Cruz <fdc@columbia.edu> wrote: > Except I don't think we want to make it require Windows 7, right? Most > sites probably haven't even "upgraded" from XP. > I *think* it has some sort of fall-back for older systems. At least the jumplist-enabled version of PuTTY seems to work fine in my XP virtual machine. It is certainly still too soon to drop XP support entirely. Google is still supporting it for Chrome for another two years IIRC. Here's a page you might not have seen that might be useful: > > http://www.kermitproject.org/k95beta.html > When I was in university (not that long ago) there was some software development going on - mostly as open source projects. Things like machine learning software, etc. No operating systems or other big things. > My main interest in this is to get a new version out, and that it be up to > date with respect to C-Kermit, and can be easily updated as C-Kermit > evolves. All the rest is up to you and Jeff. Just be aware that Jeff's > time is extremely limited, whereas I have unlimited amounts of spare time > and am ready to help in any way I can. > Yeah - my spare time can be a bit limited too. I'm hoping to get it all compiling with a modern and free-er compiler like the one Jeff mentioned sometime soonish, then it should be a lot easier for more people to get involved. There is a public holiday coming up so I might get a day or so to work on it then. Once that's done you could probably work on the C-Kermit bits of C-Kermit for Windows without too much difficulty if you feel like it. For any Win32 stuff you encounter, the Win32 API is documented over on http://msdn.microsoft.com/en-us/library/windows/desktop/hh447209(v=vs.85).aspx but finding things can be a bit difficult at times. I usually try to avoid Win32 development where possible (Qt provides a much nicer API and its not tied to windows) so I still find myself looking up a lot of stuff on MSDN. > As he says, the first step is for you to set up the Git repository > (whatever that is, I'm not real big on source control systems), so I'll > just wait to hear from you what you need, or what questions you have. > The git repo with the v2.2 code is all setup and ready to go. All I need now is the 2007-vintage KUI directory which I'm ready for any time (the rest of the v2.2 code looks ok and the console version builds fine). If you want you can have a go at putting the KUI stuff straight into git. Its all up on github right now - https://github.com/davidrg/ckwin. It's all 100% public though so you'll want to strip out anything that shouldn't be released (eg, crown icon) before committing it. Github has some good documentation on how to use it and git over at https://help.github.com/. I guess for now you'd probably just want to Fork my repository, add the kui stuff to your fork and then send me a pull request. I've not used github much at all so Jeff might have some better ideas on how this should all be setup more officially later. > By the way, welcome to the Kermit Project! Thanks!
Date: Wed, 23 Oct 2013 23:16:46 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> On Wed, Oct 23, 2013 at 12:12 PM, Frank da Cruz <fdc@columbia.edu> wrote: That 2005 KUI directory did the trick: screenshot: http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-2/22_test2.png binaries: http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-2/k95_2_2_lite-test2.zip source: https://github.com/davidrg/ckwin Still not a very useful app for people who need SSH but the GUI does work. Registration code has also been partially removed from the GUI now. While I was in there I did a little light re-branding and replaced a few "Kermit 95" strings with "C-Kermit for Windows" - there is still lots of K95 references around the UI though. I didn't quite get to replacing the icons. Also, the dialer button, menu item and "dialer" command all now disable when k95dial.exe is missing instead of displaying an empty console window and an error message box. Compiler compatibility is still limited to Visual C++ 6.0 and 7.0 (2002) for the moment - the GUI relies on some compiler options which were removed in 7.1 (2003). I'll probably have a go at fixing that on the weekend as its probably going to be a somewhat larger job than I can achieve in an evening.
Date: Wed, 23 Oct 2013 00:06:44 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu> On Tue, Oct 22, 2013 at 6:13 PM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > As opposed to throwing zip and tar files around, David please setup the > git repository and then as new file versions are found they can be > committed to the repository on a branch so that the file differences are > not lost. > > There is no point trying to replicate the Kermit development processes > of the 1980s. > > You can obtain the Windows Git tools from > > http://git-scm.com/download/win > > You should install a version of PuTTY first and use that for SSH with > Git. I recommend Marcus Sundberg's port > > https://marcussundberg.com/putty/ > > because it works with Heimdal Kerberos and has 64-bit support and all of > my fixes. > Don't worry - I was sold on DVCS a few years ago. It made living with Visual Source Safe at my last job and Team Foundation Server at my current one very difficult :) Thankfully TFS is on its way out - after nearly two years of pushing for it we started switching over to git about two weeks ago. Still very new to it though - Mercurial is what I typically use in my spare time (had better windows support back when I was choosing which one to use). Anyway: https://github.com/davidrg/ckwin Its just the 2.2 code at the moment with adjustments to make it build and no KUI stuff. It should build with Visual C++ 6 and 7. I had a go with 2010 but it doesn't get very far at all and I've not had time to figure out why. It still needs KfW and OpenSSL in their original places for header files only - it doesn't link against them. I must not have disabled some features correctly.
Date: Wed, 23 Oct 2013 9:33:49 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 Amazing. IT LIVES! ("Young Frankenstein"...) Some very obvious cosmetic and branding things... All copyright notices should be adjusted to say "1985, 2013". This will happen automatically for most of them when you build with the current ck[cuw]*.[cwh] modules but needs to done separately in the Windows modules. When you start using the newer C-Kermit modules, 'extern char * ck_cryear' has the second (i.e. current) copyright year. The first one (1985) won't change. The About popup should say whatever Jeff wants about himself, "Frank da Cruz, The Kermit Project", and you might want to add yourself. Jeff, what about Thomas Wu? How much of his code is actually used in the modern build? And maybe some words like this after the credits (if this is appropriate for an About popup): This is the free Open Source version of the program formerly known as Kermit 95, a commercial product of Columbia University from 1994 to 2011. Version 3.0 has been released under the 3-clause Modified Berkeley License, and does not include any proprietary code, resulting in the loss of certain capabilities, such as PATHWORKS and SuperLAT networking and XYZMODEM file transfer. Certain other features may be missing for various reasons. Type SHOW FEATURES at the prompt to see what features are present and which ones are missing. Or I'll put them somewhere else. The prompt string ends in "K-95>". This comes from from ckuus5.c. I'll need to do something about this. Also the "K-95" and "K95" strings are woven throughout the C-Kermit code. They are even part of the scripting language ("if c-kermit", "if k-95"). I'll need to handle this in a backwards-compatible way. Also the herald says "for 32-bit Windows". But it won't run in 95, 98, or ME, right? What should it say now? "for Windows XP and later"? (MS's naming scheme for its operating systems is really scatterbrained.) Anyway... Congratulations! - Frank
Date: Tue, 29 Oct 2013 08:13:50 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> Subject: Re: Building Kermit95 I don't know where the "IAM Consulting" reference came from. That company declared bankruptcy shortly after I left Columbia University. All of my contributions are Copyright "Secure Endpoints Inc.". > K95 is now building happily on Visual C++ 6.0, 2002, 2003, 2005, 2010 > and 2012. I've not tried 2008 (its a big download and my internet is > $10/GB) but it should work. 2013 is probably fine too. So really it > should build fine on any recentish Microsoft compiler now including the > free one in the Windows SDK. Congrats. > Its possible that versions built with newer compilers may not behave > exactly the same due to C library changes though. Versions built with > Visual C++ 2005 were originally crashing on startup because apparently > you're not allowed to read from invalid file handles anymore (it looks > like in 2003 and earlier the read just failed silently). I've no idea > what other similar issues may pop up. The important thing to know about the runtime library (if you do not know this already) is that runtime library file descriptors are not HANDLEs. They are runtime library fabrication that is just sufficient to permit POSIX-like applications to run on Windows. It was never intended to be a mature, stable interface. For this reason many projects have developed portability libraries that make up for the runtime deficiencies. The one I contribute to is Heimdal's libroken. https://github.com/heimdal/heimdal/tree/master/lib/roken The licensing is compatible so feel free to borrow code as needed. > I had a brief attempt at getting it building on OpenWatcom too (it can > target Win32 and OS/2). The good news is OpenWatcom provides wrappers to > make itself look like Visual C++ 2002 (no major build system changes > required). It produces a lot of errors about the way things are being > #defined though. Apparently defining something twice is only allowed if > both definitions are identical. C-Kermit defines something once, a > header later on tries to define it again in a different way and you get > an error. > This is an error. Can you provide a list of the collisions? > The icons are now finally replaced too. Some more copyright dates were > updated and the about dialog in k95g.exe has been redone (it turns out > the dialog editor in Visual C++ 2012 is still awful). > I always write dialogs by hand. > Getting SSH going is probably the next thing to do (and final big thing > for a v2.2 release). I see C-Kermit on unix systems just launches the > regular ssh client. Whats required to just enable this on Windows? Just > changing the default command to plink.exe and defining SSHCMD doesn't > seem to be quite enough (I get a "Can't open connection to plink.exe" > error when I run the SSH command). > You are going to need to use the Win32 api to setup pipes to redirect stdout, stdin, and stderr for the plink.exe child process. > Today's build is available in two versions: > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc6.zip > - built with Visual C++ 6. Should run on Windows 95 and up, probably NT > 3.5 and up too. I can't remember if older windows versions will run > Visual C++ 6 applications directly - they might need a few dlls. > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc2010.zip > - identical features but will only work on Windows XP SP2 and up. Will > need the Visual C++ 2010 runtime to be installed. Drop VC6 support entirely. The compiler I pointed you at supports Windows 2000 and above. An installer will need to be developed using WIX or equivalent to install the appropriate runtime merge modules. See https://github.com/heimdal/heimdal/tree/master/packages/windows/installer=
Date: Tue, 29 Oct 2013 9:50:14 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 Cc: Jeffrey Altman <jaltman@your-file-system.com> > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/k95-2010.png > It is really nice to see that! A couple nits on the About the screen: It should be Copyright 1985-2013 (not 1995) because of the C-Kermit code. "open source" should be "Open Source" (capitalized) according to: http://opensource.org/trademark-guidelines (Sec.2, 2nd bullet item) I'd call it 3.00 when it is first released to the public, not 2.2, because the transition to Open Source is big enough to warrent a new major version, even if it doesn't have the C-Kermit 9.0 updates yet. Here's a slightly more "legal" version of the second About paragraph: "This version has been released under the Revised 3-Clause BSD License, an Open Source Initiative(TM) Approved License, and therefore does not include any proprietary components of Kermit 95 such as PATHWORKS or SuperLAT networking or XYZMODEM file transfer. Certain other features (such as Kerberos security) might be omitted for technical reasons, perhaps to be added later. Type SHOW FEATURES at the command prompt for a complete list of present and missing features." You can use "(TM)" or put the Unicode TM symbol 0x2122. After the authors list you might want to put the new Kermit Project URL and the Github one. > The icons are now finally replaced too. Some more copyright dates were > updated... > It's amazing how a little thing like that gives it a whole new look. > Todays build is available in two versions ...they might need a few dlls. > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc2010.zip > Will need the Visual C++ 2010 runtime to be installed. > Right, can't run it here because MSVCR100.DLL not found. Obviously needs to be runnable by people who don't have developer tools. As for the "short name" of the program... I can't think of anything better than CKW or maybe C-KW (which is awkward but has the same format and length as K-95). Jeff, what do you think? Should we change it, or just keep K-95? Everything else: what Jeff said. Way to go! - Frank
Date: Wed, 30 Oct 2013 00:26:12 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> Time for an update! http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/k95-2010.png K95 is now building happily on Visual C++ 6.0, 2002, 2003, 2005, 2010 and 2012. I've not tried 2008 (its a big download and my internet is $10/GB) but it should work. 2013 is probably fine too. So really it should build fine on any recentish Microsoft compiler now including the free one in the Windows SDK. Its possible that versions built with newer compilers may not behave exactly the same due to C library changes though. Versions built with Visual C++ 2005 were originally crashing on startup because apparently you're not allowed to read from invalid file handles anymore (it looks like in 2003 and earlier the read just failed silently). I've no idea what other similar issues may pop up. I had a brief attempt at getting it building on OpenWatcom too (it can target Win32 and OS/2). The good news is OpenWatcom provides wrappers to make itself look like Visual C++ 2002 (no major build system changes required). It produces a lot of errors about the way things are being #defined though. Apparently defining something twice is only allowed if both definitions are identical. C-Kermit defines something once, a header later on tries to define it again in a different way and you get an error. The icons are now finally replaced too. Some more copyright dates were updated and the about dialog in k95g.exe has been redone (it turns out the dialog editor in Visual C++ 2012 is still awful). Getting SSH going is probably the next thing to do (and final big thing for a v2.2 release). I see C-Kermit on unix systems just launches the regular ssh client. Whats required to just enable this on Windows? Just changing the default command to plink.exe and defining SSHCMD doesn't seem to be quite enough (I get a "Can't open connection to plink.exe" error when I run the SSH command). Todays build is available in two versions: http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc6.zip - built with Visual C++ 6. Should run on Windows 95 and up, probably NT 3.5 and up too. I can't remember if older windows versions will run Visual C++ 6 applications directly - they might need a few dlls. http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc2010.zip identical features but will only work on Windows XP SP2 and up. Will need the Visual C++ 2010 runtime to be installed.
Date: Wed, 30 Oct 2013 11:51:34 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> To: Frank da Cruz <fdc@columbia.edu>, David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 On 10/29/2013 9:50 AM, Frank da Cruz wrote: > As for the "short name" of the program... I can't think of anything better > than CKW or maybe C-KW (which is awkward but has the same format and length > as K-95). Jeff, what do you think? Should we change it, or just keep K-95? > I would just call it "kermit.exe" and "kermitc.exe" for the console version. I would not include "for Windows" in the name. The installer only runs on Windows. Of course it is "for Windows". Its not like you can run the OS/2 or DOS kermit on Windows any longer.
Date: Thu, 31 Oct 2013 9:47:30 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 > I just noticed I failed to switch to Reply All on two emails in a row. Its > clearly much too late at night (12:30am) to be sending emails. Sorry! I > always do this eventually - I'm surprised I managed this long without > messing it up actually. > > GMail needs some sort of "It looks like you've been using Reply All for the > last 20 emails - are you sure you really want to just reply and leave all > these people out?" prompt. > I use MM: http://www.columbia.edu/~fdc/mm/ Solid 1985 technology :-) > > * ckcdeb.h > > - Don't include direct.h (Defines a few structs with names that are > > used elsewhere in C-Kermit) > > - Don't define SIGUSR1 (a signal.h tries to define it later) > OK, this is in an #ifdef OS2..#endif section so can be changed however you need to, but (as you say) it's probably compiler-specific so needs an #ifdef. > > * ckctel.c > > - Don't define isascii (Visual C++ defines isascii as _isascii. Watcom > > defines the two separately) > Ditto. > > * ckuus3.c > > - Cast switch parameters to int if they aren't already (there are > > three places using CK_OFF_T, a long) > Probably ditto. Can you send me the code changes for these three files? > >> You are going to need to use the Win32 api to setup pipes to redirect > >> stdout, stdin, and stderr for the plink.exe child process. > > > > I was hoping that whatever is currently launching the external ssh client > > is generic enough that turning on the command and changing the executable > > to run would be sufficient. Plan B was to make it generic enough. That is > > if I can actually find the code responsible - last time I went looking I > > got lost in some massive function that appeared to be setting up > > connections or something. > > > > While trying to find the appropriate bit of code I did run into at least > > one (I seem to remember a second) function that does launch a child process > > and redirect its stdout, etc. os2_netopen seems to contain a chunk of code > > for starting a shell (cmd.exe, sh.exe, bash.exe or ash.exe specifically). > > Not what I was looking for but still interesting. > The Unix code is in ckutio.c, function ttruncmd(). - Frank
Date: Fri, 1 Nov 2013 11:08:35 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> On Fri, Nov 1, 2013 at 2:47 AM, Frank da Cruz <fdc@columbia.edu> wrote: > I use MM: > > http://www.columbia.edu/~fdc/mm/ > > Solid 1985 technology :-) > I've not seen that one before. I've used Pine at times with gmail (it plays nicely enough with its IMAP interface). Need a terminal emulator with SSH support so I can get into my linux box and run it though :) > > > * ckcdeb.h > > > - Don't include direct.h (Defines a few structs with names that are > > > used elsewhere in C-Kermit) > > > - Don't define SIGUSR1 (a signal.h tries to define it later) > > > OK, this is in an #ifdef OS2..#endif section so can be changed however you > need to, but (as you say) it's probably compiler-specific so needs an > #ifdef. > Yeah. Some of them could actually just be wrapped as #ifndef thing #define thing #endif as its a header file that defines it first. In this case, with SIGUSR1, ckcdeb.h is defining it first so you get a compile error in the header. > > > * ckctel.c > > > - Don't define isascii (Visual C++ defines isascii as _isascii. > Watcom > > > defines the two separately) > > > Ditto. I think the Watcom headers are a bit weird. This particular type of difference causes problems in a few places. And missing things like O_SEQUENTIAL seems like a bug. None of it is surprising though - the compiler originally used the headers from the Windows SDK (same ones that Visual C++ uses). When it was open sourced they had to dump all the proprietary bits which included the original headers. So they've all been redone from scratch relatively recently and wont have seen nearly as much use as the ones MinGW uses. Probably worth me reporting some of the missing things to them so they can be fixed. > > > * ckuus3.c > > > - Cast switch parameters to int if they aren't already (there are > > > three places using CK_OFF_T, a long) > > > Probably ditto. Can you send me the code changes for these three files? I've put copies of all the files I changed for Watcom support in ftp://ftp2.zx.net.nz/pub/Kermit95/misc/watcom_support_changes/. It includes the two public domain header files from mingw (tapi.h and setjmpex.h) that OpenWatcom was missing. Some of the changes are a bit messy as it was only an experiment to see if it would work (I think I renamed that end variable to endd or something similar). > The Unix code is in ckutio.c, function ttruncmd(). I thought I saw more win32 code setting up pipes somewhere! ckotio.c has NT and OS/2 versions of ttruncmd(). If ttruncmd() really is the function used to start up the ssh client then the unix versions ssh command really might work on windows if it was enabled.
Date: Fri, 1 Nov 2013 00:33:01 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com>, Frank da Cruz <fdc@columbia.edu> I just noticed I failed to switch to Reply All on two emails in a row. Its clearly much too late at night (12:30am) to be sending emails. Sorry! I always do this eventually - I'm surprised I managed this long without messing it up actually. GMail needs some sort of "It looks like you've been using Reply All for the last 20 emails - are you sure you really want to just reply and leave all these people out?" prompt. Below are both of them for anyone who is interested. First one: On Fri, Nov 1, 2013 at 12:05 AM, David Goodwin <david@zx.net.nz> wrote: > On Wed, Oct 30, 2013 at 1:13 AM, > Jeffrey Altman <> jaltman@your-file-system.com> wrote: > >> On 10/29/2013 7:26 AM, David Goodwin wrote: >> > Time for an update! >> > >> http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/k95-2010.png >> >> I don't know where the "IAM Consulting" reference came from. That >> company declared bankruptcy shortly after I left Columbia University. >> All of my contributions are Copyright "Secure Endpoints Inc.". > > It/s just names in the v2.1 about dialog so I guess it was put in there > sometime later. I've changed it over to "Secure Endpoints Inc." > >> > K95 is now building happily on Visual C++ 6.0, 2002, 2003, 2005, 2010 >> > and 2012. I've not tried 2008 (its a big download and my internet is >> > $10/GB) but it should work. 2013 is probably fine too. So really it >> > should build fine on any recentish Microsoft compiler now including the >> > free one in the Windows SDK. >> >> Congrats. >> >> > Its possible that versions built with newer compilers may not behave >> > exactly the same due to C library changes though. Versions built with >> > Visual C++ 2005 were originally crashing on startup because apparently >> > you're not allowed to read from invalid file handles anymore (it looks >> > like in 2003 and earlier the read just failed silently). I've no idea >> > what other similar issues may pop up. >> >> The important thing to know about the runtime library (if you do not >> know this already) is that runtime library file descriptors are not >> HANDLEs. They are runtime library fabrication that is just sufficient >> to permit POSIX-like applications to run on Windows. It was never >> intended to be a mature, stable interface. For this reason many >> projects have developed portability libraries that make up for the >> runtime deficiencies. The one I contribute to is Heimdal's libroken. >> >> https://github.com/heimdal/heimdal/tree/master/lib/roken >> >> The licensing is compatible so feel free to borrow code as needed. >> >> > I had a brief attempt at getting it building on OpenWatcom too (it can >> > target Win32 and OS/2). The good news is OpenWatcom provides wrappers to >> > make itself look like Visual C++ 2002 (no major build system changes >> > required). It produces a lot of errors about the way things are being >> > #defined though. Apparently defining something twice is only allowed if >> > both definitions are identical. C-Kermit defines something once, a >> > header later on tries to define it again in a different way and you get >> > an error. >> >> This is an error. Can you provide a list of the collisions? > > I decided to have a proper go at figuring out what is standing in the way > of building with OpenWatcom (and a possible return of OS/2 support). The > following changes were required to get it to complete a build at all: > * Makefile > - Attempting to work out the compiler being used seems to crash wmake. > Check to see if __VERSION__ is defined (nmake doesn't define it) before > checking the compiler. > - Don't define __STDC__ (I think its defined by the compiler) > * telnet.c > - Need to define _P_WAIT (headers only define P_WAIT) > * wrlogin.def > - Need to create it > * ckcdeb.h > - Don't include direct.h (Defines a few structs with names that are > used elsewhere in C-Kermit) > - Don't define SIGUSR1 (a signal.h tries to define it later) > * ckctel.c > - Don't define isascii (Visual C++ defines isascii as _isascii. Watcom > defines the two separately) > * ckodir.h > - Don't typedef ino_t (its defined elsewhere) > * ckofio.c > - Don't define timezone (a header has already defined it) > - Don't define fileno (a header has already defined it) > - Define _O_SEQUENTIAL (headers don't define it or O_SEQUENTIAL) > - Use utimbuf instead of _utimbuf (headers don't have _utimbuf) > * ckoker.h > - Don't define stat (conflicts with later definition in stat.h) > - Don't define fileno (conflicts with later definition in stdio.h) > - Don't define fstat as _fstat (The definition itself is fine, it just > breaks everything using fstat. The headers define the fstat and _fstat > separately as taking struct stat and struct _stat respectively.) > - Don't define getpid as _getpid (clib doesn't have _getpid) > - Don't define ftime as _ftime (breaks timeb.h which has separate > prototypes for ftime and _ftime which use struct timeb and struct _timeb > respectively) > - Don't define isascii > * ckuus3.c > - Cast switch parameters to int if they aren't already (there are > three places using CK_OFF_T, a long) > * textps.c > - use stdin->_handle instead of stdin->_file > * <setjmpex.h> > - Create this file. Grab it from mingw (public domain) and change > include guards to _SETJMPEX_H_INCLUDED_ > * <tapi.h> > - Create this file. Grab it from mingw if possible (public domain). > Else the header from Visual C++ works. > * ckokey.c > - Don't create global variables called 'end' (the linker won't allow > it). int end[VNUM]={0,0,0} must be renamed to something else. > * ckotcp.h, ckuus4.c, ckuusx.c > - Don't define getpid as _getpid (clib doesn't have _getpid) > And for the GUI: > * ckocon.h > - Don't typedef int as bool > * kui/ikterm.cxx > - cast wbuf to wchar_t* instead of WORD* > * kui/kappwin.cxx > - include direct.h > * kui/kclient.cxx > - cast to wchar_t* instead of ushort* > * kui/kupload.cxx > - cast buf to wchar* > - don't use 'not' as a variable name > * kui/makefile > - Set KERMITDIR (wmake doesn't support the nmake /E option) > * ckoker.mak > - Don't link against vmdbg.lib (OpenWatcom doesn't provide it and it > doesn't appear to be necessary) > > With all those adjustments it seems to build ok with the OpenWatcom 1.9 > compiler. And it turns out the OpenWatcom people don't drop platform > support (http://ftp2.zx.net.nz/pub/Kermit95/ckwin351.png). > > The changes will require a bit more of a thoughtful approach than what > I've done now (sprinkle #ifndef __WATCOMC__ everywhere). If I can get it > building for OS/2 in some form someday I might tidy it all up and commit it. > > > >> > The icons are now finally replaced too. Some more copyright dates were >> > updated and the about dialog in k95g.exe has been redone (it turns out >> > the dialog editor in Visual C++ 2012 is still awful). >> >> I always write dialogs by hand. >> >> > Getting SSH going is probably the next thing to do (and final big thing >> > for a v2.2 release). I see C-Kermit on unix systems just launches the >> > regular ssh client. Whats required to just enable this on Windows? Just >> > changing the default command to plink.exe and defining SSHCMD doesn't >> > seem to be quite enough (I get a "Can't open connection to plink.exe" >> > error when I run the SSH command). >> >> You are going to need to use the Win32 api to setup pipes to redirect >> stdout, stdin, and stderr for the plink.exe child process. > > I was hoping that whatever is currently launching the external ssh client > is generic enough that turning on the command and changing the executable > to run would be sufficient. Plan B was to make it generic enough. That is > if I can actually find the code responsible - last time I went looking I > got lost in some massive function that appeared to be setting up > connections or something. > > While trying to find the appropriate bit of code I did run into at least > one (I seem to remember a second) function that does launch a child process > and redirect its stdout, etc. os2_netopen seems to contain a chunk of code > for starting a shell (cmd.exe, sh.exe, bash.exe or ash.exe specifically). > Not what I was looking for but still interesting. > >> > Todays build is available in two versions: >> > >> http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc6.zip >> > - built with Visual C++ 6. Should run on Windows 95 and up, probably NT >> > 3.5 and up too. I can't remember if older windows versions will run >> > Visual C++ 6 applications directly - they might need a few dlls. >> > >> http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc2010.zip >> > - identical features but will only work on Windows XP SP2 and up. Will >> > need the Visual C++ 2010 runtime to be installed. >> >> Drop VC6 support entirely. >> >> The compiler I pointed you at supports Windows 2000 and above. >> >> An installer will need to be developed using WIX or equivalent to >> install the appropriate runtime merge modules. See >> >> https://github.com/heimdal/heimdal/tree/master/packages/windows/installer > > At the moment I'm only retaining VC6 support because it doesn't require > any real effort to do so. It doesn't have any unique abilities (aside from > the RISC edition but that's not on MSDN and second hand retail copies are > well outside my price range) so support for it (along with VC 2002) will > probably disappear when my build scripts fail those two compilers and none > of the others. Not something that's likely to happen for this first release. > > As for the installer, my plan is to deal with that once SSH support is out > of the way. > And the second one: On Fri, Nov 1, 2013 at 12:23 AM, David Goodwin <david@zx.net.nz> wrote: > On Wed, Oct 30, 2013 at 2:50 AM, Frank da Cruz <fdc@columbia.edu> wrote: > >> > >> http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/k95-2010.png >> > >> It is really nice to see that! >> >> A couple nits on the About screen: >> >> It should be Copyright 1985-2013 (not 1995) because of the C-Kermit code. >> >> "open source" should be "Open Source" (capitalized) according to: >> >> http://opensource.org/trademark-guidelines (Sec.2, 2nd bullet item) >> >> I'd call it 3.00 when it is first released to the public, not 2.2, because >> the transition to Open Source is big enough to warrent a new major >> version, >> even if it doesn't have the C-Kermit 9.0 updates yet. >> >> Here's a slightly more "legal" version of the second About paragraph: >> >> "This version has been released under the Revised 3-Clause BSD License, an >> Open Source Initiative(TM) Approved License, and therefore does not >> include >> any proprietary components of Kermit 95 such as PATHWORKS or SuperLAT >> networking or XYZMODEM file transfer. Certain other features (such as >> Kerberos security) might be omitted for technical reasons, perhaps to be >> added later. Type SHOW FEATURES at the command prompt for a complete list >> of present and missing features." >> >> You can use "(TM)" or put the Unicode TM symbol 0x2122. >> >> After the authors list you might want to put the new Kermit Project URL >> and the Github one. > > I'll get these changes into the next test version. > >> > The icons are now finally replaced too. Some more copyright dates were >> > updated... >> >> It's amazing how a little thing like that gives it a whole new look. > > I had a brief go at switching it over to the 'modern' widget styles too > but there was a bit of weirdness in a few places so I switched it off > again. I must remember to have another look into it sometime. > >> > Todays build is available in two versions ...they might need a few dlls. >> >> http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc2010.zip >> >> > Will need the Visual C++ 2010 runtime to be installed. >> > >> Right, can't run it here because MSVCR100.DLL not found. Obviously needs >> to be runnable by people who don't have developer tools. > > Yeah, that's something the installer will take care of automatically (once > I get around to building one). In the meantime the appropriate Microsoft > Visual C++ Redistributable Package needs to be installed for the program to > run (the 2010 version in this case).
Date: Fri, 1 Nov 2013 00:23:35 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> On Wed, Oct 30, 2013 at 2:50 AM, Frank da Cruz <fdc@columbia.edu> wrote: > You can use "(TM)" or put the Unicode TM symbol 0x2122. > > After the authors list you might want to put the new Kermit Project URL > and the Github one. > I'll get these changes into the next test version. > > The icons are now finally replaced too. Some more copyright dates were > > updated... > > > It's amazing how a little thing like that gives it a whole new look. > I had a brief go at switching it over to the 'modern' widget styles too but there was a bit of weirdness in a few places so I switched it off again. I must remember to have another look into it sometime. > > Todays build is available in two versions ...they might need a few dlls. > > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/2_2-lite_test-3/dist-vc2010.zip > > > Will need the Visual C++ 2010 runtime to be installed. > > Right, can't run it here because MSVCR100.DLL not found. Obviously needs > to be runnable by people who don't have developer tools. > Yeah, that's something the installer will take care of automatically (once I get around to building one). In the meantime the appropriate Microsoft Visual C++ Redistributable Package needs to be installed for the program to run (the 2010 version in this case).
Date: Sun, 17 Nov 2013 19:17:58 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> > I thought I saw more win32 code setting up pipes somewhere! ckotio.c has > NT and OS/2 versions of ttruncmd(). If ttruncmd() really is the function > used to start up the ssh client then the unix versions ssh command really > might work on windows if it was enabled. > I finally found some time this weekend to have a look at all of this. I've managed to get plink running under the *console* version of K95 largely by re-using NET_CMD related code. And it does work at a very basic level (the terminal type is ignored, K95 doesn't notice when plink disconnects/exits, resizing probably doesn't work and who knows what else). However it doesn't work under the GUI version of K95. It ends up opening up its own console window and doing everything there rather than redirecting all its IO through K95. The console window appearing isn't too surprising (I remember seeing a comment mentioning this behaviour in the mintty sources). IO redirection failing is perhaps just a side effect of the console window appearing. The NET_CMD code does this too (so SET NETWORK TYPE COMMAND is broken in K95 v2.1.3). Probably not too hard to fix though - mintty works around it somehow so I just need to do what ever it does. A somewhat more serious problem is that plink doesn't really work interactively under K95 at all. The username/password prompt is completely broken. Looking through the plink source code I'm guessing the problems are being caused by all all the Win32 console window APIs its calling to hide your password when you type it in. None of that is going to work at all when it doesn't have a console window to control. I could of course create a custom build of plink that doesn't try to hide your password. And that would probably work fine except that your password is now on screen. So not really an acceptable option. I am starting to wonder if the original built-in-ssh approach is the best option. Refactor plink into a library and rewrite everything inside an #ifdef SSHBUILTIN to use that instead of the old openssh-refactored-into-a-library stuff. As an added bonus all the existing existing scripts (and the dialer for anyone who wants to keep using it) using SET SSH commands will still work. But it would be a lot of work and it makes updating the SSH client bits a bit more difficult (PuTTY doesn't update often so that part at least isn't too bad). Anyone have any ideas/suggestions?
Date: Sun, 17 Nov 2013 07:58:44 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> Subject: Re: Building Kermit95 On 11/17/2013 1:17 AM, David Goodwin wrote: > I am starting to wonder if the original built-in-ssh approach is the > best option. Refactor plink into a library and rewrite everything inside > an #ifdef SSHBUILTIN to use that instead of the old > openssh-refactored-into-a-library stuff. As an added bonus all the > existing existing scripts (and the dialer for anyone who wants to keep > using it) using SET SSH commands will still work. But it would be a lot > of work and it makes updating the SSH client bits a bit more difficult > (PuTTY doesn't update often so that part at least isn't too bad). > > Anyone have any ideas/suggestions? > A built-in ssh is of course the preferred option because it permits full integration of connection status, execution of ssh command channels, control over authentication and key exchange modes, etc. Doing so is a lot of work. Hence the idea of just getting something to work with an external ssh application. There are methods to hide console windows and I'm sure that plink can be started in a manner that redirects i/o since that is what Tortoise and many other tool chains use for ssh. You might want to look at the Tortoise SVN and Git sources.
Date: Sun, 17 Nov 2013 9:17:41 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: Building Kermit95 Hi David, good to hear from you. > There are methods to hide console windows and I'm sure that plink can > be started in a manner that redirects i/o since that is what Tortoise > and many other tool chains use for ssh. You might want to look at the > Tortoise SVN and Git sources. > Given the lack of controls for Plink, I agree a built-in SSH would be best. I don't know how much work it would be, but turning Plink into a library would probably be useful to a lot of people independent of Kermit. If it could be done in such a way that it could be built either standalone or as a library from the same source, it might be a project that people would support and maybe you could get some help with it. Another idea for getting help would be to release an Alpha-test version of CKW/K95/Whatever 3.00 on the new Kermit website. The release notes would include a description of the known shortcomings and the big items left to be done. Maybe some people will jump in. Maybe you could hide Plink behind a Kermit macro, which prompts for the necessary info: def DOSSH { local host username password .host := \%1 .username := \%2 .password := \%3 if def host { (look up host in table, if any, and get username) } if not def host ask /gui host { Host: } # echos if not def username ask /gui username { Username: } # echos if not def password askq /gui password { Password: } # doesn't echo run start plink \m(host) -l \m(username) -pw \m(password) } So if there was a host table that had hostname:username pairs, and the user said "dossh hostname", they would only be prompted for the password (by a GUI dialog in which the password echoes as *'s). I don't know what would happen upon escaping back and reconnecting, but assuming the connection is lost, that would provide some incentive for someone to do it right. On the other hand, if you'd rather do everything yourself, there's certainly no hurry; it's already been nearly 11 years. - Frank
Date: Sun, 17 Nov 2013 11:23:33 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: Frank da Cruz <fdc@columbia.edu>, David Goodwin <david@zx.net.nz> Subject: Re: Building Kermit95 On 11/17/2013 9:17 AM, Frank da Cruz wrote: > Given the lack of controls for Plink, I agree a built-in SSH would be > best. I don't know how much work it would be, but turning Plink into > a library would probably be useful to a lot of people independent of > Kermit. If it could be done in such a way that it could be built either > standalone or as a library from the same source, it might be a project > that people would support and maybe you could get some help with it. plink is part of putty and the putty developer has not been receptive to architectural changes over the course of the project. that is why there are so many forks. the ssh in putty/plink is not a library but is already a common code base shared by the two executables. It is also cross platform which could give C-Kermit an internal ssh as well.
Date: Sun, 17 Nov 2013 21:39:44 -0500 Subject: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: kermit@kermitproject.org Hi Frank: I have built c-kermit using the new android.mk build file included in the latest development versions. It requires some changes to build with the latest SDK, and I sent those to Tim Sneddon last month, but I don't know if he will forward them to you automatically. Those are given in a patch at the end of this message. In addition, there appears to be a bug in zchko() that causes a segmentation fault when attempting to open a file for writing. In particular I have found it with FTP GET as well as LOG SESSION. When NOUUCP is defined (as is the case on Android) and a nonexistent file is tested for access, open(file,O_WRONLY) fails and thus ckufio.c line 2597 sets x=-1. Later on i=-1 also and when line 2646 is reached, s[i++]='.'; overwriting memory and causing the crash. Commenting line 2597 seems to fix this. Also, is there a reason that zchki refuses to open a character device or block device? This particular usage of kermit is to backup the device's flash memory, and kermit refuses to open those device nodes itself while shell redirection to kermit standard input works fine. Thanks, ANONYMOUSCODER --- kermit.old/android.mk 2012-07-19 11:02:40.000000000 -0400 +++ kermit.new/android.mk 2013-10-04 11:02:19.958740598 -0400 @@ -22,7 +22,8 @@ -DHAVE_PTMX -D_LARGEFILE_SOURCE -DNO_OPENPTY \ -D_FILE_OFFSET_BITS=64 -DPOSIX -DUSE_FILE_R\ -DKTARGET=\"android\" -DNO_DNS_SRV -DNOIKSD \ - -DNOTIMESTAMP -DNOZLOCALTIME -DNOUUCP + -DNOTIMESTAMP -DNOZLOCALTIME -DNOUUCP \ + -DNO_NL_LANGINFO -DNO_LOCALE LOCAL_MODULE := kermit LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES) LOCAL_MODULE_TAGS := eng diff -ruiw kermit.old/android.txt kermit.new/android.txt --- kermit.old/android.txt 2012-07-20 17:22:03.000000000 -0400 +++ kermit.new/android.txt 2013-10-04 11:23:12.657770448 -0400 @@ -16,7 +16,8 @@ $ ndk-build NDK_PROJECT_PATH=./ \ APP_BUILD_SCRIPT=./android.mk \ - APP_ABI=all + APP_ABI=all \ + LOCAL_DISABLE_FORMAT_STRING_CHECKS=true If you have any problems, flames, suggestions, praise, disbelief, etc. then please feel free to create an issue on the github page and I will diff -ruiw kermit.old/ckuusy.c kermit.new/ckuusy.c --- kermit.old/ckuusy.c 2013-07-24 17:37:40.000000000 -0400 +++ kermit.new/ckuusy.c 2013-10-04 11:07:08.500747474 -0400 @@ -1696,7 +1696,9 @@ { "noescape", XA_NOESCAPE, CM_PRE }, #endif /* OS2 */ { "nointerrupts",XA_NOIN, CM_PRE }, +#ifdef HAVE_LOCALE { "nolocale", XA_NOLOCALE, CM_PRE }, +#endif /* HAVE_LOCALE */ #ifdef KUI { "nomenubar", XA_NOMN, CM_PRE }, #endif /* KUI */ @@ -2895,11 +2897,13 @@ #endif /* NOSPL */ #endif /* NOLOCAL */ +#ifdef HAVE_LOCALE case XA_NOLOCALE: { /* Don't do locale */ extern int nolocale; nolocale = 1; break; } +#endif /* HAVE_LOCALE */ default: return(-1); }
Date: Mon, 18 Nov 2013 8:44:14 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Subject: Re: C-Kermit 9.0.304dev06 Android fixes > I have built c-kermit using the new android.mk build file included in the > latest development versions. It requires some changes to build with the > latest SDK, and I sent those to Tim Sneddon last month, but I don't know if > he will forward them to you automatically. Those are given in a patch at > the end of this message. > Thanks! No, I haven't heard from Tim in quite a while. Did he respond to you? > In addition, there appears to be a bug in zchko() that causes a > segmentation fault when attempting to open a file for writing. In > particular I have found it with FTP GET as well as LOG SESSION. When > NOUUCP is defined (as is the case on Android) and a nonexistent file is > tested for access, open(file,O_WRONLY) fails and thus ckufio.c line 2597 > sets x=-1. Later on i=-1 also and when line 2646 is reached, s[i++]='.'; > overwriting memory and causing the crash. Commenting line 2597 seems to > fix this. > I confess the -DNOUUCP path hasn't been tested much, at least not by me. It's mainly for the benefit of Mac OS X. > Also, is there a reason that zchki refuses to open a character device or > block device? > If there is, it goes back to the 1980s and I don't remember it. Can you think of any reason I might have done that? :-) > This particular usage of kermit is to backup the device's > flash memory, and kermit refuses to open those device nodes itself while > shell redirection to kermit standard input works fine. > Have your tried fixing this and testing the fix? > Thanks, ANONYMOUSCODER > > --- kermit.old/android.mk 2012-07-19 11:02:40.000000000 -0400 > +++ kermit.new/android.mk 2013-10-04 11:02:19.958740598 -0400 > @@ -22,7 +22,8 @@ > -DHAVE_PTMX -D_LARGEFILE_SOURCE -DNO_OPENPTY \ > -D_FILE_OFFSET_BITS=64 -DPOSIX -DUSE_FILE_R\ > -DKTARGET=\"android\" -DNO_DNS_SRV -DNOIKSD \ > - -DNOTIMESTAMP -DNOZLOCALTIME -DNOUUCP > + -DNOTIMESTAMP -DNOZLOCALTIME -DNOUUCP \ > + -DNO_NL_LANGINFO -DNO_LOCALE > Android doesn't support locales, or this is just a personal preference? > LOCAL_MODULE := kermit > LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES) > LOCAL_MODULE_TAGS := eng > diff -ruiw kermit.old/android.txt kermit.new/android.txt > --- kermit.old/android.txt 2012-07-20 17:22:03.000000000 -0400 > +++ kermit.new/android.txt 2013-10-04 11:23:12.657770448 -0400 > @@ -16,7 +16,8 @@ > > $ ndk-build NDK_PROJECT_PATH=./ \ > APP_BUILD_SCRIPT=./android.mk \ > - APP_ABI=all > + APP_ABI=all \ > + LOCAL_DISABLE_FORMAT_STRING_CHECKS=true > > If you have any problems, flames, suggestions, praise, disbelief, etc. > then please feel free to create an issue on the github page and I will > diff -ruiw kermit.old/ckuusy.c kermit.new/ckuusy.c > Would there be anything there that isn't in this message? > --- kermit.old/ckuusy.c 2013-07-24 17:37:40.000000000 -0400 > +++ kermit.new/ckuusy.c 2013-10-04 11:07:08.500747474 -0400 > @@ -1696,7 +1696,9 @@ > { "noescape", XA_NOESCAPE, CM_PRE }, > #endif /* OS2 */ > { "nointerrupts",XA_NOIN, CM_PRE }, > +#ifdef HAVE_LOCALE > { "nolocale", XA_NOLOCALE, CM_PRE }, > +#endif /* HAVE_LOCALE */ > #ifdef KUI > { "nomenubar", XA_NOMN, CM_PRE }, > #endif /* KUI */ > @@ -2895,11 +2897,13 @@ > #endif /* NOSPL */ > #endif /* NOLOCAL */ > > +#ifdef HAVE_LOCALE > case XA_NOLOCALE: { /* Don't do locale */ > extern int nolocale; > nolocale = 1; > break; > } > +#endif /* HAVE_LOCALE */ > default: > return(-1); > } > Thanks, always glad to get some help, especially now in my "reduced circumstances" where I don't have access to all kinds of platforms any more. - Frank
Date: Tue, 19 Nov 2013 01:17:29 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> I did hear back from him, but it doesn't look like the changes got integrated into his Git code base. I have also had some success building the console version of K-95 with SSL, but without Kerberos, without SSH and without XYZmodem. My approach is to scrap the existing build process entirely and build a new makefile from the ground up. I am also building using mingw32-gcc on a Linux machine rather than using the Microsoft compiler. It seems to be able to make an ssl connection successfully, whether to the "openssl" command line utility or to some real HTTPS servers. I haven't tested it any more thoroughly. It looks like there was once an "ssh" subdirectory containing the modified copy of OpenSSH to run on Windows. Would that code have been considered proprietary and therefore not released?
Date: Tue, 19 Nov 2013 01:26:29 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Also read your inline comments in the patch.... Android doesn't have locales. Without those defines it won't link. I don't think there are any additional changes on his github page. It doesn't look like it has been updated in months. And if it wasn't clear, I am building the Windows version of K-95 from a Linux machine... not somehow magically creating a linux version of it.
Date: Tue, 19 Nov 2013 23:37:48 +1300 Subject: Re: Building Kermit95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com> On 18 November 2013 03:17, Frank da Cruz <fdc@columbia.edu> wrote: > Given the lack of controls for Plink, I agree a built-in SSH would be > best. I don't know how much work it would be, but turning Plink into > a library would probably be useful to a lot of people independent of > Kermit. If it could be done in such a way that it could be built either > standalone or as a library from the same source, it might be a project > that people would support and maybe you could get some help with it. > The most basic approach might not be too difficult. Rewrite the code that prompts for user input (looked well enough abstracted already), rip out the argument parser and set everything up directly. Cleaning up any global state after a connection has been closed, threading and event loops will be the fun bits I guess. > Another idea for getting help would be to release an Alpha-test version > of CKW/K95/Whatever 3.00 on the new Kermit website. The release notes > would include a description of the known shortcomings and the big items > left to be done. Maybe some people will jump in. > A good idea. I probably won't have much time to work on the SSH stuff until January so it would be good to get a release out this month so that people can see things are happening. I'll put some work into tidying up the current version (finish rebranding, bump version numbers up to 3.0, etc) and build installer over the next week or two. It can be put out as an alpha version which should work fine for anyone who can get by without SSH support. Telnet works fine (as far as I am able to test at least). I should probably fire up a vax or something with a serial console and confirm that all still works too. I should probably get zlib included again too. And there is still a reasonable chunk of licensing code which, while its not doing anything anymore, really should go. > Maybe you could hide Plink behind a Kermit macro, which prompts for the > necessary info... > I did consider something like this. The main problem is that the username and password remain visible in a lot of other places when its passed on the command line. Anyone on the network with administrative access to your box would be able to see them. In the interim anyone who wants to do file transfers over ssh should still be able to drive plink under the console version of Kermit using set network type command && set host plink.exe foo.example.com -l user -pw password. > I don't know what would happen upon escaping back and reconnecting, but > assuming the connection is lost, that would provide some incentive for > someone to do it right. > > On the other hand, if you'd rather do everything yourself, there's > certainly no hurry; it's already been nearly 11 years. > Not too much of a hurry but the sooner SSH is out of the way the sooner it can get some other new features like being upgraded to C-Kermit 9. Jump lists on windows 7+ would be nice too. - David
Date: Tue, 19 Nov 2013 10:23:53 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER cc: Jeffrey Altman <jaltman@your-file-system.com>, David Goodwin <david@zx.net.nz> > I did hear back from him, but it doesn't look like the changes got > integrated into his Git code base. > Well let's see if we can get everything sorted out! > I have also had some success building the console version of K-95 with > SSL, but without Kerberos, without SSH and without XYZmodem. My > approach is to scrap the existing build process entirely and build a > new makefile from the ground up. I am also building using mingw32-gcc > on a Linux machine rather than using the Microsoft compiler. It seems > to be able to make an ssl connection successfully, whether to the > "openssl" command line utility or to some real HTTPS servers. I > haven't tested it any more thoroughly. > Good news! If you had mentioned this to me earlier I would have put you in touch with another guy who has made some progress on K95. Sounds like you and he have different parts working and are using different tools. David Goodwin, cc'd above. Also Jeffrey Altman, the author of the Windows and security parts (among others) of K95. Anyway it's going to be a multistep process. First get the 2003 code to build with modern (and preferably free) compilers, then adapt Plink to provide SSH support that meshes with the K95 command processor and terminal emulator, then integrate with current C-Kermit sources, then do whatever can be done about SSL, Kerberos, etc. With more people getting involved I guess the important thing right now is to settle on a common code base at Github. David? And once that's done maybe we should go public to shake out any others who might be silently working on K95. > It looks like there was once an "ssh" subdirectory containing the > modified copy of OpenSSH to run on Windows. Would that code have been > considered proprietary and therefore not released? > It was decided not to release it because it was just way too far behind the times and full of the 2002-era security loopholes. The current thinking is to adapt the PuTTY Plink program to do the SSH part. Unfortunately it can't be simply "plugged in" to K95. David and Jeff can comment on that. Welcome aboard! - Frank
Date: Tue, 19 Nov 2013 16:49:56 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> CC: ANONYMOUSCODER Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/19/2013 4:44 PM, David Goodwin wrote: > Yes, the SSH code is much too old now to put to any real long term use. > I guess it could be restored temporarily to produce a few alpha releases > while the replacement SSH code is developed. > The SSH code is governed by U.S. export restrictions which prevent its redistribution. No one from Columbia University is going to process the paperwork to reclassify it. The project will need to move on without it. Jeffrey Altman
Date: Tue, 19 Nov 2013 17:38:18 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz> CC: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/19/2013 5:34 PM, David Goodwin wrote: > Yeah, not worth the hassle getting it all approved if its just going to > be thrown away shortly anyway. > > On a related topic, I've often wondered how the crypto export > restrictions work in the US. OpenSSH is present in most (all?) Linux > distributions. Do the US based ones have to obtain export licenses for > this, are there special exceptions or do they just ignore the law? There is a standard exception for open source. The issue in this case is that Kermit 95 is not open source and the crypto code in Kermit 95 was granted an export license after an explicit classification review. To the best of my knowledge Columbia University never followed up with the U.S. Government and requested permission to open source the code derived from OpenSSH. You can use OpenSSH all you want. You simply cannot use the code that is wrapped up in the export classification. Jeffrey Altman
Date: Wed, 20 Nov 2013 11:52:43 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER On Wed, Nov 20, 2013 at 11:38 AM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > There is a standard exception for open source. The issue in this case > is that Kermit 95 is not open source and the crypto code in Kermit 95 > was granted an export license after an explicit classification review. > To the best of my knowledge Columbia University never followed up with > the U.S. Government and requested permission to open source the code > derived from OpenSSH. > > You can use OpenSSH all you want. You simply cannot use the code that > is wrapped up in the export classification. That makes things nice and easy for us. Thanks for the explanation.
Date: Wed, 20 Nov 2013 11:34:18 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER On Wed, Nov 20, 2013 at 10:49 AM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > On 11/19/2013 4:44 PM, David Goodwin wrote: > > Yes, the SSH code is much too old now to put to any real long term use. > > I guess it could be restored temporarily to produce a few alpha releases > > while the replacement SSH code is developed. > > The SSH code is governed by U.S. export restrictions which prevent its > redistribution. No one from Columbia University is going to process > the paperwork to reclassify it. The project will need to move on > without it. > Yeah, not worth the hassle getting it all approved if its just going to be thrown away shortly anyway. On a related topic, I've often wondered how the crypto export restrictions work in the US. OpenSSH is present in most (all?) Linux distributions. Do the US based ones have to obtain export licenses for this, are there special exceptions or do they just ignore the law? Will export restrictions affect the US-based Kermit Projects ability to distribute Kermit once we've integrated a new SSH client? And is GitHub who is hosting the code affected? And if I were to export the plink-enabled Kermit from my server in the US who is affected by what laws? New Zealand has effectively no cryptography export restrictions (for this sort of software at least) so while I can export PuTTY as much as I like the server I would be doing it from is based in the US. Who is doing the exporting and what laws to they fall under in this case? I guess that's effectively the same situation as with github - probably something in the hosing providers ToS that says not to do this without the proper paperwork.
Date: Wed, 20 Nov 2013 10:44:28 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> On Wed, Nov 20, 2013 at 4:23 AM, Frank da Cruz <fdc@columbia.edu> wrote: > Good news! If you had mentioned this to me earlier I would have put you in > touch with another guy who has made some progress on K95. Sounds like you > and he have different parts working and are using different tools. David > Goodwin, cc'd above. Also Jeffrey Altman, the author of the Windows and > security parts (among others) of K95. > I've been meaning to have a go at getting it building under GCC but rewriting the makefile didn't look very fun. Any work in this area is very useful. > Anyway it's going to be a multistep process. First get the 2003 code to > build with modern (and preferably free) compilers, then adapt Plink to > provide SSH support that meshes with the K95 command processor and > terminal emulator, then integrate with current C-Kermit sources, then do > whatever can be done about SSL, Kerberos, etc. With more people getting > involved I guess the important thing right now is to settle on a common > code base at Github. David? > As far as I know the codebase up on github (https://github.com/davidrg/ckwin) is the most complete publicly available copy of the K95 source and the only one that includes all the KUI bits required to build the GUI (k95g.exe) along with a few other less interesting bits that were missing from the original release. Continuing future development from that is probably easiest. At some point we should probably get a Kermit Project organisation setup on github to hold the official repositories. The code up on github currently builds the console & GUI fine and has all the obsolete/proprietary bits disabled (SSL, SSH, SRP, Kerberos, DECnet, LAT, X/Y/Z Modem, the dialer, the registration code, etc). Supported compilers are Visual C++ 6.0 SP6 and above. I've had a brief look at getting OpenWatcom support in but I've not had time to integrate the necessary changes in a sufficiently tidy way. I did manage to take a screenshot though: http://ftp2.zx.net.nz/pub/Kermit95/ckwin351.png. Getting proper GCC support in there as well would be great. I briefly investigated targeting OS/2 with OpenWatcom and had text2ps cross-compiling but that was about as far as I got - I don't really know enough about OS/2 or the compilers previously used to get it going properly at this time. If no one else does it I might have another go once other more important things (ssh) are out of the way. > And once that's done maybe we should go public to shake out any others > who might be silently working on K95. > > > It looks like there was once an "ssh" subdirectory containing the > > modified copy of OpenSSH to run on Windows. Would that code have been > > considered proprietary and therefore not released? > > > It was decided not to release it because it was just way too far behind > the times and full of the 2002-era security loopholes. The current > thinking is to adapt the PuTTY Plink program to do the SSH part. > Unfortunately it can't be simply "plugged in" to K95. David and Jeff can > comment on that. > Yes, the SSH code is much too old now to put to any real long term use. I guess it could be restored temporarily to produce a few alpha releases while the replacement SSH code is developed. Considering the amount of work done to integrate OpenSSH with K95 and include Kerberos & SRP support I expect actually bringing the old code up-to-date is probably as much work as replacing it altogether with something else. So the plan right now is to just rip the SSH client out of PuTTY's plink utility and, with as few changes as possible (to make future upgrades easier), integrate it into Kermit. This would probably mean replacing most of the code in #ifdef SSHBUILTIN blocks so it will still be quite a bit of work.
Date: Tue, 19 Nov 2013 23:37:51 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com>, Frank da Cruz <fdc@columbia.edu> I have zlib- and ssl-enabled k95 console building with gcc. For the time being it's using the obsolete OpenSSL 0.9.7. Currently, it should work out of the box on a Fedora 18 system with mingw32-gcc installed. It automatically builds zlib and OpenSSL, and then kermit. It may work on Windows using MSYS. The old makefiles were scrapped and replaced. Refer to patches/jwt.patch for the interesting changes. Source: http://www.kermitproject.org/newk95/k95-mingw32.tar.gz Binaries: http://www.kermitproject.org/newk95/k95bin.tar.gz
Date: Wed, 20 Nov 2013 8:22:31 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: C-Kermit 9.0.304dev06 Android fixes > I have zlib- and ssl-enabled k95 console building with gcc. > For the time being it's using the obsolete OpenSSL 0.9.7. > > Currently, it should work out of the box on a Fedora 18 system with > mingw32-gcc installed. It automatically builds zlib and OpenSSL, and > then kermit. It may work on Windows using MSYS. The old makefiles > were scrapped and replaced. > Wow. So... how can K95 run on Linux? Is it in some kind of Windows emulation box or as a regular Linux application? Can it see the Linux file system? Does it do terminal emulation? How is that possible? Can it run on the console? In a terminal window in a shell session? C-Kermit can't do terminal emulation because it can't "see" the physical keyboard or the screen (which is both a weakness and a strength), but K95 needs to do that, but how can it? For example, if I am coming into Linux on an SSH or Telnet connection? Or does it work only inside an X window? Sorry to seem so out of touch. - Frank
Date: Wed, 20 Nov 2013 13:39:43 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> It doesn't work on Linux, rather, mingw32 on Fedora provides a C compiler that runs on Linux, yet produces Windows object code and executables. So the output of this build process is still a Windows executable and DLLs. There are also Windows versions of mingw32 available. If one were to attempt to build a linux version of K-95, this would be a starting point: http://wiki.winehq.org/Winelib
Date: Thu, 21 Nov 2013 06:02:49 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, ANONYMOUSCODER CC: Frank da Cruz <fdc@columbia.edu> Subject: Re: C-Kermit 9.0.304dev06 Android fixes David, I'm sorry but the "Kermit 95" references really need to go. "Kermit 95" is a commercial product of its publisher which is still being sold on Amazon. http://www.amazon.com/Kermit-95-Communications-Software-Windows/dp/1930110057/ref=sr_sp-atf_title_1_1?ie=UTF8&qid=1385031596&sr=8-1&keywords=kermit+95 As a new open source product which is still in beta I would give this version 0.1. Thanks. Jeffrey Altman
Date: Thu, 21 Nov 2013 12:36:13 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz>, ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: C-Kermit 9.0.304dev06 Android fixes Hi all, Jeff said: > I'm sorry but the "Kermit 95" references really need to go. "Kermit > 95" is a commercial product of its publisher which is still being sold > on Amazon: > > http://www.amazon.com/dp/1930110057/ > Just to clarify, the Kermit 95 software is a product of Columbia University, which holds the copyright. The publisher, Manning Publications, held the copyright only on the manual, and has since relinquished its rights, allowing it to be published openly on the Internet; e.g. here: http://www.kermitproject.org/k95manual/ However, this document is more for the Dialer than anything else so it's not very relevant to what we're doing now. There will, of course, need to be some new documentation (note to myself). Meanwhile Manning continues to sell K95 shrinkwraps directly and through Amazon and other outlets at a very slow pace until the stock runs out. The software copyright is held by Columbia University and the license has been converted to the new BSD-style Open Source license with advice and consent of University counsel and all other relevant parties including the Director of IT and the Director of Columbia Technology Ventures (which itself continues to sell Kermit 95 2.1.3 bulk licenses). Thus I would say that we, or anybody else, would have the right to call it Kermit 95, K95, C-Kermit, or anything else we choose. I'm not taking a strong position on the matter, and we've discussed it before before ANONYMOUSCODER came along. I don't think this would be the first software that went from commercial to open source without changing its name. K95 1.x and 2.x were commercial; K95 3.x is Open Source; that's simple enough. There is something to be said for name recognition. On the other hand, I recognize that the new version is different from 2.1.3 in that it lacks some key features. Even assuming we get SSH working, it's still going to lack XYZMODEM, the Dialer, some propietary networking methods, and probably some security methods. Plus it's going to inherit all the new features of C-Kermit from the last 10 years. So it could also make some sense to give it a new name. Previously we had agreed on C-Kermit for Windows, which is accurate, but a short form (like "K95") is also needed, and CKW just isn't quite as catchy. I have two ideas that are in the spirit of K95: 1. K14 (naming it after 2014, as K95 was named after 1995); and 2. K64 in hopes that the 64-bit file i/o APIs will be implemented. But I like K95 better. Maybe think of it this way: Kermit 95 was the whole package, including Dialer, manual, etc. C-Kermit for Windows is basically the K95*.EXE executable. K95 is the short name the K95*.EXE executable, regardless of version. > As a new open source product which is still in beta I would give this > version 0.1. > We should stick with the current version numbering sequence so scripts can dosimple version tests, as they have always been able to do, e.g.: IF ( K-95 && > \v(xversion) 2103 ) { command, command, ... } So the first Alpha version would be Alpha.01. Or even Dev.01 if it is to be considered pre-Alpha. David said: > I've just completed a fresh build for testing if anyone is interested in > having a look. Changes from the last one are: > * The program now refers to itself as just "Kermit" (or "Kermit for > Windows and OS/2" when mentioned in the context of other Kermit editions). > - User agents are still "Kermit 95" - I don't see any point in changing > them as that's what this program is compatible with (IE still has Mozilla > in its user agent after all). > - There are still K-95 references around (including the command prompt > and title bar). The title bar one should probably change, I don't know > about the command prompt. Anyone have any strong feelings about this? > "Kermit for Windows" is too general. There have been other programs with that name (there was one for Windows 3.1, for example). It should be C-Kermit for Windows, with a nickname to be decided later. Maybe the best thing is to keep it as K95 for now, but say in the release notes that this is subject to change. Also keep in mind there are lots of Kermit programs, so we can't say "Kermit 3.0.0" or even "C-Kermit 3.0.0" because there is also a "C-Kermit 9.0.304". So either we call it "C-Kermit for Windows 3.0.0" or we agree that it's OK to keep calling in Kermit 95, in which "Kermit 95 3.0.0" looks pretty natural. > * Version number has been bumped to 3.0 > * Fixed Jeffs organisation ("IAM Consulting" -> "Secure Endpoints Inc.") > where ever it appeared > * Removed border around buttons in GUI dialogs (aside from being smaller > than usual they look normal now) > * Bumped copyright date to 2013 where ever I noticed it > There are some glitches, e.g. in the HELP screen, the LICENSE screen, the COPYRIGHT screen, etc. A lot of this stuff will fix itself when you integrate the current C-Kermit modules. I can take care of most of this kind of thing myself once we have a common set of sources. > * Rewrote the text in the NEWS screen. It now lists the features no longer > available in addition to any new features (not many yet - I'll have to go > through the v2.2 changes file sometime and pick anything interesting out of > it) > * Cleaned out the SUPPORT screen to indicate there is none now > Also see the current ckuus2.c: ftp://ftp.kermitproject.org/kermit/ckermit/ > * Adjusted most (all?) URLs to point to the new kermitproject.org website > I need to do some more of this on my end too. > * Ripped out a big chunk of old license enforcement (registration) code. > While it wasn't really doing anything before (I had deleted the contents of > the functions that checked the license and printed out its info) it was > still a pile of dead code hanging around that didn't need to be there. > Chances are I've missed some of it but most of it should be gone now. > > Anyway, the build is available below and source code is up on > https://github.com/davidrg/ckwin as usual. As I don't have an installer yet > to deal with CRT issues this build was just done with Visual C++ 6 to > eliminate that little headache for now. You should just be able to run it > directly on anything relatively modern without having to download some > Visual C++ runtime installer. > > http://ftp2.zx.net.nz/pub/Kermit95/test_builds/3_0-21-nov-2013/winkermit-3.0-test-21-nov-2013-vc6.zip > > Still on my to-do list for an initial no-ssh alpha release: > * Re-enable zlib > * Build an installer > * Testing > * Release notes > * Probably other stuff I've forgotten. Can anyone think of anything in > particular that needs to be done make the next build suitable for a more > public release? Any further changes to be made to the NEWS and SUPPORT > screens? Any other similar screens I've missed? > I'm sure there must be; just put a caveat in the release notes that some of the messages might be outdated, this is a prerelease for testing purposes only, etc. > Also, does anyone think its worthwhile re-enabling SSL using the old 0.9.7 > OpenSSL release? It could be a while before upgrading to a newer version > happens - especially if I can't find any documentation that clearly > describes any breaking changes between each release. > It would be nice if anybody on earth were running SSL Telnet or FTP servers, but I'm not aware of any, or if anybody uses Kermit's HTTP command suite for anything real. Or if anybody uses IKSD. Actually, I use Kermit SSL every day to fetch my mail from a POP3 server, so you never know. Again, the latest C-Kermit has better (if not perfect) support for OpenSSL 1.0. I honestly don't think it will be that hard to slip in the current C-Kermit sources (for SSL you'll also need to take some code from the Unix C-Kermit makefile; see the linux+ssl target). In the ck[cu]* modules, I haven't done much that could affect K95, I don't think. Have you tried building with them? The sooner we get all the forks together, the less work we'll have down the road. If you try this and you get errors, let me know and I'll probably be able to fix them pretty fast. - Frank
Date: Fri, 22 Nov 2013 00:19:49 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> I looked into the possibility of merging the current C-Kermit sources with Kermit 95. This looks to be trivial, in fact, much easier than I expected. As a bonus, and as Frank expected, we get OpenSSL 1.0 support for free. I agree that it would be better to try and merge my work on the original k95source.zip with David's git repository. This won't be worthwhile until I get a copy of Visual Studio (I have one, somewhere) and set it up so that I can get a single code base compiling with both VC++ and mingw32. I probably won't get to this until over Thanksgiving. I would like to document what each -D compiler command line option is actually doing as part of this. As there are a number of discussion items, I will try to address them individually. Version number ============== Any reason it can't be called C-Kermit 9.0.304dev06, 21 Nov 2013, for 32-bit Windows, or "Kermit" for short in the prompt and window title? Or if keeping the Kermit 95 name, just bump the version to stay in lockstep with C-Kermit? Especially if the eventual goal is to merge the sources with C-Kermit into a single ckuNNN.tar file. GCC changes that may break VC++ =============================== As David alluded to, the construction (FARPROC) xxxx = yyyy is used often. This helps in VC++, but gcc does not allow type casts on the left side of an assignment operator. I dealt with this by stripping out all instances of (FARPROC). If this only causes VC++ to generate a warning, we should just disable the warning. If it truly causes an error, we should make a compiler dependent macro so that FARPROC_CAST and HANDLE_CAST can be used to generate (FARPROC) and (HANDLE) with VC++ and empty strings on gcc, respectively. GCC changes that shouldn't break VC++ ===================================== Both the VC++ and gcc builds are passing flags to cause the compiler to treat all "char" as unsigned. However, there are places where the headers declare a prototype with CHAR and the .c file uses char, or vice versa. VC++ must treat these as equivalent, but gcc generates an error even with -funsigned-char. There are several places where a function is declared as static and then implemented as non-static, or vice versa. GCC won't allow this, but VC++ must handle it. There are a handful of inline functions (IsUnicode being one example) that are implemented in header files. GCC requires these be defined as "static" to avoid link time duplicate function errors. SSH support =========== I think several of you have mentioned an interim solution of allowing K-95 to start a subprocess, such as Plink, with its stdin, stdout, and stderr redirected to the terminal emulator. I agree, this would allow similar functionality to the "set net type pty" on Unix, and would also allow Android "adb" to be run inside Kermit, as is possible on Unix. In the long term, as far as built in support, having OpenSSL 1.0 available certainly can't hurt. Remaining issues before merge ============================= Before I attempt to merge my changes with David's I would like to (1) get Visual C++ compiling my code, so we can have both compilers working, and (2) get the GUI version working with gcc. C-Kermit changes ================ The changes I had to make to C-Kermit 9.0.304dev06 to get it to integrate with K-95 are given below. If these could be included in dev07, that's one less integration issue. I may not have all the #ifdef conditions exactly appropriate, so please review as needed. Thanks --- vanilla_cku/ckcdeb.h 2013-07-24 15:09:23.000000000 -0400 +++ cku_k95_merge/ckcdeb.h 2013-11-21 23:43:15.703596666 -0500 @@ -2809,7 +2809,7 @@ #else /* _M_PPC */ #ifndef NO_SSL #define CK_SSL -#define SSLDLL +/*#define SSLDLL*/ /* OpenSSL included at link time now. */ #endif /* NO_SSL */ #endif /* _M_PPC */ #ifndef NO_KERBEROS @@ -5371,7 +5371,7 @@ _PROTOTYP( int zclosf, (int) ); #endif /* MAC */ #ifdef NZXPAND -_PROTOTYP( int nzxpand, (char *, int) ); +_PROTOTYP( int nzxpand, (CHAR *, int) ); /* signed/unsigned issue */ #else /* NZXPAND */ _PROTOTYP( int zxpand, (char *) ); #endif /* NZXPAND */ @@ -6062,7 +6062,6 @@ #endif /* def MAXPATHLEN [else] */ #endif /* def VMS [else] */ #endif /* ndef CKMAXPATH */ - /* Maximum length for the name of a tty device */ #ifndef DEVNAMLEN --- vanilla_cku/ckcker.h 2010-04-02 13:13:36.000000000 -0400 +++ cku_k95_merge/ckcker.h 2013-11-21 23:44:03.788995516 -0500 @@ -1309,7 +1309,7 @@ #else /* OS2 */ _PROTOTYP( int conect, (void) ); #endif /* OS2 */ -_PROTOTYP( int ckcgetc, (int) ); +/*_PROTOTYP( int ckcgetc, (int) );*/ /* only used in same .c as definition */ _PROTOTYP( int ckcputc, (int) ); _PROTOTYP (int mdmhup, (void) ); _PROTOTYP( VOID herald, (void) ); --- vanilla_cku/ckcsig.h 2009-10-16 11:35:22.000000000 -0400 +++ cku_k95_merge/ckcsig.h 2013-11-21 23:44:13.035879914 -0500 @@ -90,7 +90,7 @@ #define cklongjmp(x,y) siglongjmp(x,y) #else #ifdef NT -__inline int +static __inline int /* duplicate definition issue */ ck_ih(void) { extern int TlsIndex; #ifdef NTSIG --- vanilla_cku/ckcuni.h 2009-10-16 11:36:04.000000000 -0400 +++ cku_k95_merge/ckcuni.h 2013-11-21 23:45:15.955093315 -0500 @@ -225,7 +225,7 @@ #endif /* CK_ANSIC */ extern struct x_to_unicode * txrinfo[MAXTXSETS+1]; -_PROTOTYP(int isunicode, (void)); +_PROTOTYP(static int isunicode, (void)); /* duplicate definition issue */ _PROTOTYP(int utf8_to_ucs2, (CHAR, USHORT **)); _PROTOTYP(int ucs2_to_utf8, (USHORT, CHAR **)); _PROTOTYP(int tx_cpsub, (USHORT)); @@ -240,7 +240,7 @@ #ifdef OS2 #ifdef NT -_inline +static _inline /* duplicate definition issue */ #else _Inline #endif /* NT */ --- vanilla_cku/ck_ssl.c 2012-07-20 15:45:46.000000000 -0400 +++ cku_k95_merge/ck_ssl.c 2013-11-21 23:53:51.096653159 -0500 @@ -2743,6 +2743,7 @@ char * tls_userid_from_client_cert(ssl) SSL * ssl; { +#ifndef OS2 /* K-95 doesn't have X509_to_user */ static char cn[256]; static char *r = cn; int err; @@ -2759,6 +2760,9 @@ } else return r = NULL; +#else + return NULL; +#endif /* OS2 */ } unsigned char ** @@ -3062,6 +3066,7 @@ int tls_is_user_valid(SSL * ssl, const char *user) { +#ifndef OS2 /* K-95 doesn't have X509_userok */ X509 *client_cert; int r = 0; @@ -3076,6 +3081,9 @@ X509_free(client_cert); return r; +#else + return 0; +#endif /* OS2 */ } int --- vanilla_cku/ck_ssl.h 2012-05-28 14:52:42.000000000 -0400 +++ cku_k95_merge/ck_ssl.h 2013-11-21 23:58:00.729532319 -0500 @@ -152,10 +152,10 @@ _PROTOTYP(int ck_X509_save_cert_to_user_store,(X509 *)); /* SMS 2007/02/15 */ _PROTOTYP(int ssl_check_server_name,(SSL * ssl, char * hostname)); -#ifdef OS2 +/*#ifdef OS2 #include "ckosslc.h" #include "ckossl.h" -#endif /* OS2 */ +#endif*/ /* OS2 */ /* SSL in K-95 is no longer a special case */ #define SSL_CLIENT 0 #define SSL_SERVER 1 --- vanilla_cku/ckuus4.c 2013-07-24 15:09:23.000000000 -0400 +++ cku_k95_merge/ckuus4.c 2013-11-21 23:49:58.661558998 -0500 @@ -62,6 +62,7 @@ #define APIRET ULONG #endif /* NT */ #include "ckocon.h" +#include "ckodir.h" /* for MAXPATHLEN */ #include "ckoetc.h" int StartedFromDialer = 0; HWND hwndDialer = 0; @@ -10383,10 +10384,17 @@ s = "lrwxrwxrwx"; else #endif /* UNIX */ +/* + * K-95 doesn't have ziperm. However, I have not read through this + * code thoroughly, and this needs double checked to see if there are + * any side effects of commenting this out. + */ +#ifdef CK_PERMS s = ziperm(bp[0]); a_ptr[x][4] = NULL; makestr(&(a_ptr[x][4]),s); ckstrncpy(workbuf,s,32); /* Save for later */ +#endif /* Element 5 - Permissions numeric code */ @@ -10396,7 +10404,11 @@ /* Element 6 - Size in bytes */ +#ifdef OS2 /* K-95 doesn't have linkname */ + s = ckfstoa(z); +#else s = zgfs_link ? ckitoa((int)strlen((char *)linkname)) : ckfstoa(z); +#endif a_ptr[x][6] = NULL; makestr(&(a_ptr[x][6]),s); --- vanilla_cku/ckuus6.c 2013-07-24 15:06:53.000000000 -0400 +++ cku_k95_merge/ckuus6.c 2013-11-21 23:36:44.597486165 -0500 @@ -82,6 +82,7 @@ #include "ckntap.h" #endif /* NT */ #include "ckocon.h" +#include "ckodir.h" /* for MAXPATHLEN */ #endif /* OS2 */ extern long vernum, speed; --- vanilla_cku/ckuusr.h 2013-07-24 20:45:27.000000000 -0400 +++ cku_k95_merge/ckuusr.h 2013-11-21 23:51:58.995054622 -0500 @@ -2768,7 +2768,9 @@ _PROTOTYP( int doputenv, ( char *, char * ) ); #endif /* UNIX */ +#ifndef OS2 /* K-95's chkaes is (int, char) instead */ _PROTOTYP( int chkaes, ( char, int ) ); +#endif #ifndef NOICP _PROTOTYP( int matchname, ( char *, int, int ) ); @@ -2871,7 +2873,7 @@ _PROTOTYP( int setfil, (int) ); _PROTOTYP( char * homepath, (void) ); #ifdef OS2 -_PROTOTYP( int settapi, (void) ) ; +/*_PROTOTYP( int settapi, (void) ) ;*/ /* static/non-static issue */ #ifdef OS2MOUSE _PROTOTYP( int setmou, (void) ); #endif /* OS2MOUSE */ --- vanilla_cku/ckuusy.c 2013-07-24 17:37:40.000000000 -0400 +++ cku_k95_merge/ckuusy.c 2013-11-21 22:10:55.646856906 -0500 @@ -1696,7 +1696,9 @@ { "noescape", XA_NOESCAPE, CM_PRE }, #endif /* OS2 */ { "nointerrupts",XA_NOIN, CM_PRE }, +#ifdef HAVE_LOCALE { "nolocale", XA_NOLOCALE, CM_PRE }, +#endif #ifdef KUI { "nomenubar", XA_NOMN, CM_PRE }, #endif /* KUI */ @@ -2895,11 +2897,13 @@ #endif /* NOSPL */ #endif /* NOLOCAL */ +#ifdef HAVE_LOCALE case XA_NOLOCALE: { /* Don't do locale */ extern int nolocale; nolocale = 1; break; } +#endif default: return(-1); }
Date: Fri, 22 Nov 2013 18:36:11 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> On Fri, Nov 22, 2013 at 6:36 AM, Frank da Cruz <fdc@columbia.edu> wrote: > Hi all, > > Jeff said: > > I'm sorry but the "Kermit 95" references really need to go. "Kermit > > 95" is a commercial product of its publisher which is still being sold > > on Amazon: > > > > http://www.amazon.com/dp/1930110057/ > > > Just to clarify, the Kermit 95 software is a product of Columbia > University, > which holds the copyright. The publisher, Manning Publications, held the > copyright only on the manual, and has since relinquished its rights, > allowing it to be published openly on the Internet; e.g. here: > > http://www.kermitproject.org/k95manual/ I just had a look at the license on the back of the v2.1 package and it does fairly clearly state that Manning only has a license to redistribute it and that its still owned by Columbia University. So unless Manning has some agreement with Columbia that says "Only we're allowed to distribute something called 'Kermit 95'" I would think it would be up to Columbia. The only Kermit-related trademarks that I could see on uspto.gov were related to frogs. > However, this document is more for the Dialer than anything else so it's > not very relevant to what we're doing now. There will, of course, need > to be some new documentation (note to myself). > On that note, whats the ownership status of the other manuals? The MS-DOS Kermit one seems to be out of print. I assume the C-Kermit 6.0 one won't be in print forever. > Meanwhile Manning continues to sell K95 shrinkwraps directly and through > Amazon and other outlets at a very slow pace until the stock runs out. > So they don't have any plans to manufacture any more physical copies? > Kermit 95 was the whole package, including Dialer, manual, etc. > C-Kermit for Windows is basically the K95*.EXE executable. > K95 is the short name the K95*.EXE executable, regardless of version. > I think if there is any way we can legitimately continue with the "Kermit 95" name that would be best. Is it worth trying to contact someone at Columbia at all? > Also keep in mind there are lots of Kermit programs, so we can't say > "Kermit 3.0.0" or even "C-Kermit 3.0.0" because there is also a "C-Kermit > 9.0.304". So either we call it "C-Kermit for Windows 3.0.0" or we agree > that it's OK to keep calling in Kermit 95, in which "Kermit 95 3.0.0" > looks pretty natural. > "Kermit 95 3.0.0" is my preference - its what people will search for and dealing with Kermit 95 references on the website would be a bit of a pain if we have to use a different name (especially as most of the information applies to both K95 2.1 and this program). I'll leave the decision up to you and Jeff though. I can rename things fairly easily once a final name has been decided on and to what extent re-branding is necessary (eg, user agent strings, command prompts, etc). Until something has been properly decided I'll hold off on any further work in that area. > Again, the latest C-Kermit has better (if not perfect) support for OpenSSL > 1.0. I honestly don't think it will be that hard to slip in the current > C-Kermit sources (for SSL you'll also need to take some code from the Unix > C-Kermit makefile; see the linux+ssl target). In the ck[cu]* modules, I > haven't done much that could affect K95, I don't think. Have you tried > building with them? The sooner we get all the forks together, the less > work we'll have down the road. > > If you try this and you get errors, let me know and I'll probably be able > to fix them pretty fast. > I've not tried building with them yet but I did go through and diff all the common files a while back to see if there were any changes that could obviously cause problems. I don't recall there being many differences though - I think the C-Kermit sources currently included in K95 are a lot newer than what shipped in v2.1. I expect I've broken large file support though (assuming it ever worked in what ever version of C-Kermit is being used here) with the two changes I made to ckofio.c below (see the pair of TODO comments): https://github.com/davidrg/ckwin/blob/master/kermit/k95/ckofio.c#L5418 I didn't bother trying to actually fix the code as I wasn't sure I would be able to get K95 to compile at all even if I did fix it. I just made the change and moved on to the next compile error. I was using Visual C++ 6.0 at the time as it was the last known compiler to work (Visual C++ 2002 certainly didn't). Maybe newer compiler would handle it (although newer versions certainly didn't handle a lot of other stuff). In the interest of quickly announcing that things are happening with K95 again its probably best to leave the C-Kermit upgrade until after we've got an initial release out though. So 3.0 alpha 1 release to-do is: * Decide on branding * pull over any relevant bits for the news/support/license/copyright/etc screens from C-Kermit 9.0 * Re-enable zlib * build an installer * testing * release notes * put on website, update website, etc.
Date: Fri, 22 Nov 2013 23:34:30 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: ANONYMOUSCODER Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> On Fri, Nov 22, 2013 at 6:19 PM, ANONYMOUSCODER wrote: > I looked into the possibility of merging the current C-Kermit sources > with Kermit 95. This looks to be trivial, in fact, much easier than I > expected. As a bonus, and as Frank expected, we get OpenSSL 1.0 > support for free. > > I agree that it would be better to try and merge my work on the > original k95source.zip with David's git repository. This won't be > worthwhile until I get a copy of Visual Studio (I have one, somewhere) > and set it up so that I can get a single code base compiling with both > VC++ and mingw32. I probably won't get to this until over > Thanksgiving. I would like to document what each -D compiler command > line option is actually doing as part of this. > Microsoft gives out the Visual C++ compiler for free now (just the compiler though - no MFC, IDE or other garbage (although the extremely basic Visual C++ Express Edition IDE should work)). The Platform SDK should give you everything you need. This one should include the 2008 compiler which, while I've never attempted it, should work (2005 & 2010 do): http://www.microsoft.com/en-us/download/details.aspx?id=3138 > As there are a number of discussion items, I will try to address them > individually. > > Version number > ============== > Any reason it can't be called C-Kermit 9.0.304dev06, 21 Nov 2013, for > 32-bit Windows, or "Kermit" for short in the prompt and window title? > Or if keeping the Kermit 95 name, just bump the version to stay in > lockstep with C-Kermit? Especially if the eventual goal is to merge > the sources with C-Kermit into a single ckuNNN.tar file. > Biggest reason to keep them separate is probably the feature and portability differences - unless all the KUI stuff is rewritten the terminal emulator is only available on Windows & OS/2. > GCC changes that may break VC++ > =============================== > As David alluded to, the construction (FARPROC) xxxx = yyyy is used > often. This helps in VC++, but gcc does not allow type casts on the > left side of an assignment operator. I dealt with this by stripping > out all instances of (FARPROC). If this only causes VC++ to generate > a warning, we should just disable the warning. If it truly causes an > error, we should make a compiler dependent macro so that FARPROC_CAST > and HANDLE_CAST can be used to generate (FARPROC) and (HANDLE) with > VC++ and empty strings on gcc, respectively. > I wasn't even sure what I was even looking at when I first saw that - I've never seen type casts done like that before. I've no idea if it produced any runtime issues (I canceled the build to investigate the warnings further) but it only seemed to produce warnings when the cast was absent. Making it into a compiler dependent macro is probably the best option rather than disable the warnings though. > SSH support > =========== > I think several of you have mentioned an interim solution of allowing > K-95 to start a subprocess, such as Plink, with its stdin, stdout, and > stderr redirected to the terminal emulator. I agree, this would allow > similar functionality to the "set net type pty" on Unix, and would > also allow Android "adb" to be run inside Kermit, as is possible on > Unix. > The console version can already do it (set net type command && set host plink.exe). Any program that tries to do anything fancy like colour or moving the cursor around will likely misbehave terribly if it works at all. plinks username/password prompt causes problems here. The GUI version can't do it at all - the program is launched in its own window and the pipes don't get setup properly. Simon Tatham classified the difficulty of this sort of feature as "mayhem: Probably impossible" in PuTTY's win-command-prompt wishlist entry. Support for a local cygwin terminal is much more possible though - a feature I'd like to see in a future version of K95. TerraTerm already has it and there are forks of PuTTY around that do it too. Sadly using K95 as a real SSH client will probably have to wait until the source code for plink is refactored and compiled into K95.
Date: Fri, 22 Nov 2013 9:38:38 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> ANONYMOUSCODER wrote: > Version number > ============== > Any reason it can't be called C-Kermit 9.0.304dev06, 21 Nov 2013, for > 32-bit Windows... > I suppose not! > or "Kermit" for short in the prompt and window title? > Unless there are strong objections, I think we should stick with K95 as the short name, for continuity and familiarity. Anyway, even if we don't use it, nothing prevents somebody else from using (or abusing) it. So better we hang on to it, no? > Or if keeping the Kermit 95 name, just bump the version to stay in > lockstep with C-Kermit? Especially if the eventual goal is to merge > the sources with C-Kermit into a single ckuNNN.tar file. > We always have maintainted two version numbers; the C-Kermit version and the K95 version. This is because, in the heyday of K95 development, there could be several K95 releases with no changes to C-Kermit. In scripts you can test the \v(version) built-in for the C-Kermit version, and you can test \v(xversion) for the K95 version. I believe we did the same thing in the long-forgotten MacKermit, or if not, we should have. So it's mainly a question of what we show in the window title and the startup herald. I'd say, since we no longer show all the registration junk in the startup herald, we could show both version numbers. Maybe something like this (assuming we keep the "K95" nickname): C-Kermit 9.0.304 OPEN SOURCE: Dev.06, 21 Nov 2013, for Windows 32-bit Numeric: 900304; K95 3.0.0, numeric: 3000 THIS IS A TEST VERSION, NOT FOR PRODUCTION USE. Type COPYRIGHT to see copyright and license. The second-to-last line comes out automatically if ck_s_test is a nonempty string (defined in ckcmai.c). I'll fix the code to generate the appropriate herald so once we switch to using current C-Kermit sources, it'll come out right. I'll try to put up Dev.07 within a few days. I'll also fix the VERSION command to be a little more up-front about the two version numbers. > C-Kermit changes > ================ > > The changes I had to make to C-Kermit 9.0.304dev06 to get it to > integrate with K-95 are given below. If these could be included in > dev07, that's one less integration issue. I may not have all the > #ifdef conditions exactly appropriate, so please review as needed. > Will do, thanks! David wrote: > On that note, whats the ownership status of the other manuals? The MS-DOS > Kermit one seems to be out of print. I assume the C-Kermit 6.0 one won't > be in print forever. > Digital Press has changed hands so many times I can't find anyone to speak with about this. Holding companies of holding companies. Making a new and comprehensive book would be a huge job, and the result itself would be too big to carry around. I'm thinking of just consolidating the book and the three update files onto the web in some form, like a cross-indexed command and topic reference with some pages that explain key concepts. I might write another Kermit book at some point, but not a complete manual, more like a introduction to scripting, if it seems there would be any interest. > > Meanwhile Manning continues to sell K95 shrinkwraps directly and through > > Amazon and other outlets at a very slow pace until the stock runs out. > > So they don't have any plans to manufacture any more physical copies? > No. But it *could* happen. Last year a company wanted to purchase 20,000 shrinkwraps, but the deal fell through at the last minute. If it hadn't, I'm sure Manning would have produced them. But it's immaterial to us. K95 2.1.3 is a product with its own license and characterists, and the new version is totally separate. I mentioned before that Columbia still sells K95 bulk licenses, but with no tech support whatsoever. I have no idea how many they are selling, it's secret. When they canceled all the active support contracts, the spoke with each licensee and realized that some of them would want to keep ordering new licenses the same way they did before, and that was an easy way for them to make money. Not as much as they make with gene patents, but money is money. So the old K95 has a life of its own that has nothing to do with us. > I think if there is any way we can legitimately continue with the "Kermit > 95" name that would be best. Is it worth trying to contact someone at > Columbia at all? > The less contact with Columbia the better. The new license gives us, or anybody else, the right to do whatever we want with the code. The only thing we can't do is use the Columbia in advertising (3rd clause of license). > "Kermit 95 3.0.0" is my preference - its what people will search for and > dealing with Kermit 95 references on the website would be a bit of a pain > if we have to use a different name (especially as most of the information > applies to both K95 2.1 and this program). > > I'll leave the decision up to you and Jeff though. I can rename things > fairly easily once a final name has been decided on and to what extent > re-branding is necessary (eg, user agent strings, command prompts, etc). > Until something has been properly decided I'll hold off on any further > work in that area. > I'm tending to favor keeping "Kermit 95" and "K95" (and "K-95") as nicknames that we can use in the code and messages and documention, but changing the formal name C-Kermit for Windows. > So 3.0 alpha 1 release to-do is: > * Decide on branding > * pull over any relevant bits for the news/support/license/copyright/etc > screens from C-Kermit 9.0 > * Re-enable zlib > * build an installer > * testing > * release notes > * put on website, update website, etc. > In light of ANONYMOUSCODER's success with pulling in the current C-Kermit modules, do you want to reconsider that part? About SSH... I think that the minute the world finds out there is a new Open Source K95 that actually runs, people will be crazy to add SSH to it and we'll get some more help. We'll see! About the rollout... David, ANONYMOUSCODER, would you like to write a few lines about who and where you are, affiliation if any, how you would like to identify yourselves to the world? ANONYMOUSCODER said: > I would like to document what each -D compiler command > line option is actually doing as part of this. > What a concept. I actually used to do this, but it has been a long time. Have you seen these: http://www.kermitproject.org/ckccfg.html - Configuration options http://www.kermitproject.org/ckcplm.html - Program logic manual - Frank
Date: Fri, 22 Nov 2013 10:27:02 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER CC: David Goodwin <david@zx.net.nz> Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/22/2013 9:38 AM, Frank da Cruz wrote: > Unless there are strong objections, I think we should stick with K95 > as the short name, for continuity and familiarity. Anyway, even if we > don't use it, nothing prevents somebody else from using (or abusing) it. > So better we hang on to it, no? I believe I have made my strong objections clear. For me "Kermit 95" and "K95" are associated with the commercialization of the product and its ties to Windows 95. Neither is this software a commercial product nor does it have any association with the Windows 9x family which is dead and should rest in peace. The product name when I started working on the code base was "OS/2 C-Kermit". I believe the name for OS/2 if David generates that should return to "OS/2 C-Kermit" and for Windows it should be "Windows C-Kermit". The process name should be "kermit.exe" for the GUI and "kermitc.exe" for the console version. I see no reason why there needs to be a three letter acronym name for the process. Frank has argued that maintaining the Kermit 95 / K95 name is a good thing because it will drive adoption. If anything the Kermit 95 / K95 name is associated with a stale out of date product which abandoned its user base more than a decade ago. This is an opportunity for a fresh start which returns the software to its roots as a shared community collaboration. The name should reflect that. As far as variables go and script compatibility. Here are the variables from the K95g build that is running on my desktop. \v(herald) = Kermit 95 2.2.0, 29 Dec 2005 \v(program) = C-Kermit \v(version) = 800212 \v(xprogram) = K-95G \v(xversion) = 2200 I would like to see these be: \v(herald) = Kermit <version>, <build date> \v(program) = C-Kermit \v(version) = <numeric c-kermit version> \v(xprogram) = Kermit \v(xversion) = <numeric kermit version> where the numeric kermit version should be 1.0 for the first non-beta version. I'm not concerned about breaking scripts that relying upon "K-95" or "K-95G" because those scripts are likely expecting features which may no longer be present. Scripts will be easy to modify to support the new program but will break in an expected fashion and not a random unexpected fashion. Changing the xprogram name informs users that scripts will need to be evaluated. If the scripts were portable to C-Kermit they will of course continue to function as before. Something else to add to the "to do" list. The Windows platform variable support will need to be updated to recognize more recent versions of Windows, 64-bit, 32-bit and WOW64 execution environments. \v(osname) = Windows 2000/XP \v(osrelease) = 6.01 \v(osversion) = (7601) Service Pack 1 \v(platform) = 32-bit_Windows \v(system) = WIN32 Thank you. Jeffrey Altman
Date: Fri, 22 Nov 2013 11:34:53 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: David Goodwin <david@zx.net.nz> Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> On Fri, Nov 22, 2013 at 5:34 AM, David Goodwin <david@zx.net.nz> wrote: > Microsoft gives out the Visual C++ compiler for free now (just the compiler > though - no MFC, IDE or other garbage (although the extremely basic Visual > C++ Express Edition IDE should work)). The Platform SDK should give you > everything you need. This one should include the 2008 compiler which, while > I've never attempted it, should work (2005 & 2010 do): > http://www.microsoft.com/en-us/download/details.aspx?id=3138 Do you think it should work with both VC++ and GCC before release? I don't think it is worth butchering the large file code in order to support VC++ 6. What is the minimum version of VC++ that you can use without disabling anything? Ironically, from reviewing the github changes it looks like it is easier to make this work with gcc than the newer versions of VC++. > Biggest reason to keep them separate is probably the feature and > portability differences - unless all the KUI stuff is rewritten the > terminal emulator is only available on Windows & OS/2. > Actually, the portability differences seem to be well handled. The K-95 code was isolated into cko*.c and ckn*.c modules, and the C-Kermit code uses #ifdefs to include the correct .h files. It's almost to the point of unpack k95source.zip, unpack latest c-kermit development version over top of it, correct a few things, and compile. There are some cku* files that get ignored when building K-95, and the cko* and ckn* files get ignored when building Unix C-Kermit. > I wasn't even sure what I was even looking at when I first saw that - I've > never seen type casts done like that before. > > I've no idea if it produced any runtime issues (I canceled the build to > investigate the warnings further) but it only seemed to produce warnings > when the cast was absent. Making it into a compiler dependent macro is > probably the best option rather than disable the warnings though. > If there is a warning number, you may be able to disable those using a /wd flag on the cl command line, and that would be cleaner than adding yet another ifdef. > The console version can already do it (set net type command && set host > plink.exe). Any program that tries to do anything fancy like colour or > moving the cursor around will likely misbehave terribly if it works at all. > plinks username/password prompt causes problems here. The GUI version can't > do it at all - the program is launched in its own window and the pipes don't > get setup properly. > > Simon Tatham classified the difficulty of this sort of feature as "mayhem: > Probably impossible" in PuTTY's win-command-prompt wishlist entry. Support > for a local cygwin terminal is much more possible though - a feature I'd > like to see in a future version of K95. TerraTerm already has it and there > are forks of PuTTY around that do it too. > > Sadly using K95 as a real SSH client will probably have to wait until the > source code for plink is refactored and compiled into K95. > I had not tried plink until now, and I see that it doesn't look like any curses based program works. There are other projects that embed PuTTY code, like FileZilla, and they may or may not have already done some modularization which might help. And I'm guessing the reason it is difficult to add proper emulation to Plink is because he would need to write a Windows Console based terminal emulator -- which K-95 already has.
Date: Fri, 22 Nov 2013 11:56:28 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> On Fri, Nov 22, 2013 at 9:38 AM, Frank da Cruz <fdc@columbia.edu> wrote: >> The changes I had to make to C-Kermit 9.0.304dev06 to get it to >> integrate with K-95 are given below. If these could be included in >> dev07, that's one less integration issue. I may not have all the >> #ifdef conditions exactly appropriate, so please review as needed. > > Will do, thanks! I didn't check to see if Linux C-Kermit still built with those changes, so make sure I didn't mess anything up. > The less contact with Columbia the better. The new license gives us, or > anybody else, the right to do whatever we want with the code. The only > thing we can't do is use the Columbia in advertising (3rd clause of > license). I have to agree with Jeff on the rights to the name. As long as Kermit 95 still exists as a commercial product, I can't see anything good coming out of having an unrelated open source version with the same name. Actually, the situation seems quite similar as Netscape 4.x vs. Mozilla in the early days of that open source project: abandoned, inferior, but feature complete commercial version; new incomplete open source version. >> * Re-enable zlib I don't think the code makes use of zlib unless SSL is also enabled. >> * build an installer Considering the early alpha stage of this code, is it really insufficient to just provide a .zip file with executables and dlls? > In light of ANONYMOUSCODER's success with pulling in the current C-Kermit > modules, do you want to reconsider that part? I think we should get the latest C-Kermit integrated as well as openssl and zlib. When do we want to release this?
Date: Fri, 22 Nov 2013 11:58:04 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: ANONYMOUSCODER, David Goodwin <david@zx.net.nz> CC: Frank da Cruz <fdc@columbia.edu> Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/22/2013 11:34 AM, ANONYMOUSCODER wrote: > Do you think it should work with both VC++ and GCC before release? I > don't think it is worth butchering the large file code in order to > support VC++ 6. What is the minimum version of VC++ that you can use > without disabling anything? Unfortunately this is not an archived mailing list. If it was I would point you at the e-mail discussions from about a month ago on this very subject. I believe that the lowest compiler that should be supported is the Platform SDK 7.0 compiler (cl version 14.00). This provides the broadest support for operating system compatibility and 64-bit process support. I believe that David posted a link. VC 6 should be dropped. There is no need to support Win 9.x and Windows 2000. If it were up to me I would abandon XP as well because from a security perspective the OS should not be permitted to connect to the Internet. On 8 April 2014 the flood gates are going to open on zero day attacks for which there will never be a fix. > Ironically, from reviewing the github changes it looks like it is > easier to make this work with gcc than the newer versions of VC++. I would rather not have to rely upon non-Microsoft tools. >> Biggest reason to keep them separate is probably the feature and >> portability differences - unless all the KUI stuff is rewritten the >> terminal emulator is only available on Windows & OS/2. > > Actually, the portability differences seem to be well handled. The > K-95 code was isolated into cko*.c and ckn*.c modules, and the > C-Kermit code uses #ifdefs to include the correct .h files. It's > almost to the point of unpack k95source.zip, unpack latest c-kermit > development version over top of it, correct a few things, and compile. > There are some cku* files that get ignored when building K-95, and > the cko* and ckn* files get ignored when building Unix C-Kermit. The cko* and ckn* files need to be updated for 64-bit file I/O. > I had not tried plink until now, and I see that it doesn't look like > any curses based program works. There are other projects that embed > PuTTY code, like FileZilla, and they may or may not have already done > some modularization which might help. And I'm guessing the reason it > is difficult to add proper emulation to Plink is because he would need > to write a Windows Console based terminal emulator -- which K-95 > already has. Simon is very reluctant to accept changes that fundamentally alter the architecture of the software. That is why there are so many forks. Please base any Kermit work off of Marcus Sundberg's fork. https://marcussundberg.com/putty/ Its the only version that supports GSS Key Exchange so PK host keys are not required. Jeffrey Altman
Date: Fri, 22 Nov 2013 12:05:22 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: ANONYMOUSCODER, Frank da Cruz <fdc@columbia.edu> CC: David Goodwin <david@zx.net.nz> Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/22/2013 11:56 AM, ANONYMOUSCODER wrote: >>> * Re-enable zlib > > I don't think the code makes use of zlib unless SSL is also enabled. Correct. The zlib.dll is only used as an engine for OpenSSL. >>> * build an installer > > Considering the early alpha stage of this code, is it really > insufficient to just provide a .zip file with executables and dlls? Building a simple installer with the Wix toolkit is not hard. Adding the associated merge modules for the 14.00 compiler makes it possible for users to install and have things work on a raw system. Look at the wix installers for Heimdal as an example. Those are correct because they are mine. Use master or the 1.6 branch. The repo is on github. Jeffrey Altman
Date: Fri, 22 Nov 2013 12:38:20 EST From: Frank da Cruz <fdc@columbia.edu> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: ANONYMOUSCODER, David Goodwin <david@zx.net.nz> Subject: Re: C-Kermit 9.0.304dev06 Android fixes Jeff said: > Unfortunately this is not an archived mailing list. If it was I would > point you at the e-mail discussions from about a month ago on this very > subject. > I can put it on the website if nobody objects. As a raw mail file, trivial. As a structured document, a little more work. Maybe password-protected? > VC 6 should be dropped. There is no need to support Win 9.x and Windows > 2000. If it were up to me I would abandon XP as well because from a > security perspective the OS should not be permitted to connect to the > Internet. On 8 April 2014 the flood gates are going to open on zero day > attacks for which there will never be a fix. > If the program naturally runs on XP, it might be a little harsh to refuse to run there. Anyway, there might be XPs out there that are not on the Internet and need to do serial port things. For example, on factory floors controlling milling machines. (Such things exist in real life.) Of course we should put cautions about the risks in the release notes and documenation. > Use a warning #pragma instead in the relevant source files. However, a > build specific macro would be my preference to hiding warnings. > (But don't put #pragmas in mainline C-Kermit code.) ANONYMOUSCODER said: > I didn't check to see if Linux C-Kermit still built with those > changes, so make sure I didn't mess anything up. > I always do! > I have to agree with Jeff on the rights to the name. As long as > Kermit 95 still exists as a commercial product, I can't see anything > good coming out of having an unrelated open source version with the > same name. Actually, the situation seems quite similar as Netscape > 4.x vs. Mozilla in the early days of that open source project: > abandoned, inferior, but feature complete commercial version; new > incomplete open source version. > Yikes, "branding" is even harder than writing code! OK, so that brings us back to C-Kermit for Windows or just plain Kermit for Windows. Or Windows Kermit. Let's let it settle for a while and come back to it. In the meantime, let's call it CKW for short. (This reminds of when we first developed Kermit in 1981, but didn't know what to call it, which made it tricky to talk about.) As an aside, the reason I liked K-95 as a name was that it reminded me of "P-38" from when I was in Army; the ultimate gadget: http://en.wikipedia.org/wiki/P-38_can_opener Maybe we should call it P-38 :-) > > In light of ANONYMOUSCODER's success with pulling in the current > > C-Kermit modules, do you want to reconsider that part? > > I think we should get the latest C-Kermit integrated as well as > openssl and zlib. When do we want to release this? > It's not Obamacare :-) No deadlines. "We sell no wine before its time." But that said, personally I'd like to see it available for testing before the end of this year. No special reason. - Frank
Date: Fri, 22 Nov 2013 21:31:31 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Jeffrey Altman <jaltman@your-file-system.com> Cc: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> On Fri, Nov 22, 2013 at 11:58 AM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > I believe that the lowest compiler that should be supported is the > Platform SDK 7.0 compiler (cl version 14.00). This provides the > broadest support for operating system compatibility and 64-bit process > support. I believe that David posted a link. > > VC 6 should be dropped. There is no need to support Win 9.x and Windows > 2000. If it were up to me I would abandon XP as well because from a > security perspective the OS should not be permitted to connect to the > Internet. On 8 April 2014 the flood gates are going to open on zero day > attacks for which there will never be a fix. I agree, not just for those old OSes but to avoid having to change the C-Kermit code to support VC6. Also, correct me if I'm wrong, but I don't know if anyone can get a legal copy of VC6 anymore except from eBay or MSDN. If nothing else, I hope we can remove any conditional code dealing with VC 6. > I would rather not have to rely upon non-Microsoft tools. > I agree that it should build with VC, but that it should also build with mingw32-gcc. I got the GUI version to build with gcc/g++ tonight. I see no reason not to support both, especially the build system continues to be just nmake. > Use a warning #pragma instead in the relevant source files. However, a > build specific macro would be my preference to hiding warnings. > Assuming of course, that the warning doesn't go away by upgrading from VC6. Most of the (FARPROC) code deals with runtime dynamic linking (LoadLibrary, GetProcAddress). I assume this was used extensively so that K-95 could gracefully deal with missing DLLs, like OpenSSL and Kerberos? Now that the product can be rebuilt to add or remove features, do you see any reason not to start phasing out the LoadLibrary code and just include all needed libraries at link time?
Date: Fri, 22 Nov 2013 21:52:16 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: ANONYMOUSCODER CC: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/22/2013 9:31 PM, ANONYMOUSCODER wrote: > I agree, not just for those old OSes but to avoid having to change the > C-Kermit code to support VC6. Also, correct me if I'm wrong, but I > don't know if anyone can get a legal copy of VC6 anymore except from > eBay or MSDN. > > If nothing else, I hope we can remove any conditional code dealing with VC 6. I haven't heard anyone suggest that VC6 continue to be used. My proposal is that you use the compilers and tool chain that comes in the Windows Platform SDK 7.0. http://www.microsoft.com/en-us/download/details.aspx?id=8279 This SDK provides support for XP through Windows 7 / Server 2008 R2 and its binaries can be used in desktop mode on X86 and X64 systems through Windows 8.1 and Server 2012 R2. >> I would rather not have to rely upon non-Microsoft tools. > > I agree that it should build with VC, but that it should also build > with mingw32-gcc. I got the GUI version to build with gcc/g++ > tonight. I see no reason not to support both, especially the build > system continues to be just nmake. As one of the people doing the actual work you get to speak with your commits. I suggest you fork David's github project and send him pull requests. >> Use a warning #pragma instead in the relevant source files. However, a >> build specific macro would be my preference to hiding warnings. > > Assuming of course, that the warning doesn't go away by upgrading from > VC6. Most of the (FARPROC) code deals with runtime dynamic linking > (LoadLibrary, GetProcAddress). I assume this was used extensively so > that K-95 could gracefully deal with missing DLLs, like OpenSSL and > Kerberos? Now that the product can be rebuilt to add or remove > features, do you see any reason not to start phasing out the > LoadLibrary code and just include all needed libraries at link time? The reason that (FARPROC) is used is because that is the type of the return value from GetProcAddress(). The alternative is to provide type definitions for each of the imports and cast the output of GetProcAddress() to the appropriate types for assignment. The reason we use DLLs that are loaded manually at runtime is so that individuals or organizations that wish to use their own versions of the libraries can do so. OpenSSL can be built a thousand different ways with different crypto systems. MIT Kerberos is distributed as a loose collection of DLLs and is frequently customized by institutions. If Kermit will ship with all of the DLLs the correct way to do it would be to package the DLLs as side by side assemblies to protect against DLL Hell. I've already done this work for Heimdal Kerberos. Porting Kermit to use Heimdal instead of MIT is something that could be added to the to do list. I would prefer that the configurable use of DLLs be preserved. Jeffrey Altman
Date: Sat, 23 Nov 2013 17:20:08 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: ANONYMOUSCODER Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> On Sat, Nov 23, 2013 at 5:34 AM, ANONYMOUSCODER wrote: > Do you think it should work with both VC++ and GCC before release? I > don't think it is worth butchering the large file code in order to > support VC++ 6. What is the minimum version of VC++ that you can use > without disabling anything? > All versions of Visual C++ 6 and up currently build fine with everything that is currently enabled. We can loose VC6 and 2002 support just fine without affecting anything. Loosing Visual C++ 2003 affects portability to earlier windows releases and so should stay for now (Although the TerraTerm people are producing 9x/NT4 builds with VC 2005 somehow - statically linking to the CRT I think). Considering the sorts of platforms and compilers C-Kermit currently handles I'd be surprised if upgrading to C-Kermit 9.0 would cause any problems with Visual C++. It would more likely be upgrading the Win32 bits to handle large files that would break things but as much of that already seems to have been done at some point it might be fine. > Ironically, from reviewing the github changes it looks like it is > easier to make this work with gcc than the newer versions of VC++. > Most of the work was getting it to compile and run with Visual C++ 2005 (CRT changes caused at least one bug that I know of). The changes weren't too extensive though - Its just done as a lot of commits so I could easily undo changes if required. It was probably still more work than getting OpenWatcom going though. > > Biggest reason to keep them separate is probably the feature and > > portability differences - unless all the KUI stuff is rewritten the > > terminal emulator is only available on Windows & OS/2. > > Actually, the portability differences seem to be well handled. The > K-95 code was isolated into cko*.c and ckn*.c modules, and the > C-Kermit code uses #ifdefs to include the correct .h files. It's > almost to the point of unpack k95source.zip, unpack latest c-kermit > development version over top of it, correct a few things, and compile. > There are some cku* files that get ignored when building K-95, and > the cko* and ckn* files get ignored when building Unix C-Kermit. > I was meaning more the portability of the terminal emulator. Its a pretty big feature to have as platform-specific. My hope is that one day the GUI version will be rewritten with something like Qt and made available on Linux. But until then only Windows and OS/2 get the terminal emulator. > I had not tried plink until now, and I see that it doesn't look like > any curses based program works. There are other projects that embed > PuTTY code, like FileZilla, and they may or may not have already done > some modularization which might help. And I'm guessing the reason it > is difficult to add proper emulation to Plink is because he would need > to write a Windows Console based terminal emulator -- which K-95 > already has. > I *suspect* TerraTerm is (or has in the past) embedding plink as its SSH client as well. I couldn't quite see how or what was being done though. A lot of the comments are in Japanese. Of course all the putty related stuff in its source tree could just be something far less interesting like pagent integration.
Date: Sat, 23 Nov 2013 17:43:00 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com>, ANONYMOUSCODER So many threads! We need a mailing list or forum or newsgroup or something. Once this is all announced on the website we should probably move comp.protocols.kermit.misc or setup a mailing list. On Sat, Nov 23, 2013 at 6:38 AM, Frank da Cruz <fdc@columbia.edu> wrote: > Jeff said: > > Unfortunately this is not an archived mailing list. If it was I would > > point you at the e-mail discussions from about a month ago on this very > > subject. > > I can put it on the website if nobody objects. As a raw mail file, > trivial. As a structured document, a little more work. Maybe > password-protected? > > > VC 6 should be dropped. There is no need to support Win 9.x and Windows > > 2000. If it were up to me I would abandon XP as well because from a > > security perspective the OS should not be permitted to connect to the > > Internet. On 8 April 2014 the flood gates are going to open on zero day > > attacks for which there will never be a fix. > > If the program naturally runs on XP, it might be a little harsh to refuse > to run there. Anyway, there might be XPs out there that are not on the > Internet and need to do serial port things. For example, on factory floors > controlling milling machines. (Such things exist in real life.) > > Of course we should put cautions about the risks in the release notes and > documenation. > VC6 (and 2002 for that matter) can go. I doubt I'll ever get my hands on the edition that can target Alpha NT so it being able to compile with it doesn't really give us anything. As for dropping platform support, this is one thing I would like to avoid unless its truly necessary. I'd go further than just keeping XP support. I want to see at least one open source release of Kermit for all platforms Kermit-95 originally supported. This gives anyone still on those platforms an alternative to Kermit-95, PuTTY and TerraTerm. They can be desupported when a feature comes along that actually requires them to be desupported. Of course releases for these obsolete platforms don't need to be the same ones that support Windows 7, etc. Having the installer run on all of them would be entirely impractical. A zip file containing binaries specially built with Visual C++ 2003 (or maybe 2005/8.0/cl14 with a few adjustments - the TerraTerm people do it somehow) and a extra download link alongside the 32bit and 64bit downloads for XP and up would be sufficient. From a security perspective I don't think there is any risk to running Kermit on these older platforms. The risk is putting windows (I'd say any version) unprotected directly on the internet. An old windows box in the corner that is being used as a terminal to something else should be perfectly fine as long as network access is limited. > It's not Obamacare :-) No deadlines. "We sell no wine before its time." > But that said, personally I'd like to see it available for testing before > the end of this year. No special reason. > The sooner the better I think. If more people turn up it should make all the rest of the work that needs doing a bit easier.
Date: Sat, 23 Nov 2013 00:14:15 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu> CC: ANONYMOUSCODER Subject: Re: C-Kermit 9.0.304dev06 Android fixes On 11/22/2013 11:43 PM, David Goodwin wrote: > VC6 (and 2002 for that matter) can go. I doubt I'll ever get my hands on > the edition that can target Alpha NT so it being able to compile with it > doesn't really give us anything. > I wouldn't worry about it. The hardware was lost quite a while ago. I used to build for Alpha, MIPS and PowerPC. I also had a port for the unreleased OS/2 Sparc port. > As for dropping platform support, this is one thing I would like to > avoid unless its truly necessary. I'd go further than just keeping XP > support. I want to see at least one open source release of Kermit for > all platforms Kermit-95 originally supported. This gives anyone still on > those platforms an alternative to Kermit-95, PuTTY and TerraTerm. They > can be desupported when a feature comes along that actually requires > them to be desupported. The point of de-supporting the old platforms is to encourage people to move forward to systems that can be secured. The world has changed quite a bit since the early 90s. Writing code for old OSes is a nice hobby but people actually running them in anything other than a locked down emulator is dangerous. All of my projects will stop releasing XP/2003 compatible binaries starting on 8 April 2014. Another reason to halt support is to be able to produce binaries that can support both IPv4 and IPv6. > Of course releases for these obsolete platforms don't need to be the > same ones that support Windows 7, etc. Having the installer run on all > of them would be entirely impractical. A zip file containing binaries > specially built with Visual C++ 2003 (or maybe 2005/8.0/cl14 with a few > adjustments - the TerraTerm people do it somehow) and a extra download > link alongside the 32bit and 64bit downloads for XP and up would be > sufficient. As long as someone is willing to do the work to write the installers, etc. Installers for post-XP tend to be quite different from XP and earlier. Side by side assemblies and merge modules simply don't work correctly with the XP version of the Windows Installer framework. > From a security perspective I don't think there is any risk to running > Kermit on these older platforms. The risk is putting windows (I'd say > any version) unprotected directly on the internet. An old windows box in > the corner that is being used as a terminal to something else should be > perfectly fine as long as network access is limited. There is no safe access to any version of Windows XP or earlier sitting on a network that is connected to the Internet. Even if the XP system itself doesn't make use of the Internet connectivity. Over the course of the last year there have been significant break ins and privilege escalation attacks from XP systems joined to domains which have resulted in major active directory domain compromises. Major US universities will start to ban access from these systems to their networks and off site web sites starting next Summer. > The sooner the better I think. If more people turn up it should make all > the rest of the work that needs doing a bit easier. > Figure out a method of cloning me and I will have all of it done in a week. :-(
Date: Sat, 23 Nov 2013 19:48:19 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER On Sat, Nov 23, 2013 at 6:14 PM, Jeffrey Altman <jaltman@your-file-system.com> wrote: > I wouldn't worry about it. The hardware was lost quite a while ago. I > used to build for Alpha, MIPS and PowerPC. I also had a port for the > unreleased OS/2 Sparc port. > yeah - I've heard the non-x86 compilers were fairly awful. I assume the Sparc port was a similar beast to the PowerPC one. The PPC one was obviously released in some form (Michal over at os2museum.comapparently has a proper copy on CD-ROM) - do you know if it was it ever properly (boxed copies available for order) released? Or was it like Multitasking DOS 4.0 - only available to people who had contracts? A bit of a pity none of that went any further really. It probably would have made a decent platform for an open-source OS/2 - I assume there can't have been a great deal of Microsoft code in it. > As for dropping platform support, this is one thing I would like to > > avoid unless its truly necessary. I'd go further than just keeping XP > > support. I want to see at least one open source release of Kermit for > > all platforms Kermit-95 originally supported. This gives anyone still on > > those platforms an alternative to Kermit-95, PuTTY and TerraTerm. They > > can be desupported when a feature comes along that actually requires > > them to be desupported. > > The point of de-supporting the old platforms is to encourage people to > move forward to systems that can be secured. The world has changed > quite a bit since the early 90s. Writing code for old OSes is a nice > hobby but people actually running them in anything other than a locked > down emulator is dangerous. > The hobby crowd would be the target - For personal/at-home use even a single initial release with no ssh support would be an improvement over HyperTerm. I would certainly hope there are no organisations out there running NT4 in a networked environment today (I'm sure there probably are though. It will be interesting to see how long XP takes to properly disappear - especially as its Microsofts official solution for running older software on Windows 7). > All of my projects will stop releasing XP/2003 compatible binaries > starting on 8 April 2014. > > Another reason to halt support is to be able to produce binaries that > can support both IPv4 and IPv6. > Yeah, IPv6 needs to happen sometime in the not too distant future. Support for older operating systems certainly shouldn't be allowed to prevent new features like that (or a future linux port. Haiku could probably do with a real terminal emulator too). On that topic of future KUI work - can you remember how much of the KUI stuff is actually used? There really does seem like quite a lot in there. I've certainly never seen a spash screen or a graphical download dialog. I'm starting to think we could also do with some form of issue tracker. Currently my To-Do list is on a bunch of pieces of (small) paper from a pad I found in my mailbox from a real-estate agency. It has some guys face taking up a fifth of the already small page. > > Of course releases for these obsolete platforms don't need to be the > > same ones that support Windows 7, etc. Having the installer run on all > > of them would be entirely impractical. A zip file containing binaries > > specially built with Visual C++ 2003 (or maybe 2005/8.0/cl14 with a few > > adjustments - the TerraTerm people do it somehow) and a extra download > > link alongside the 32bit and 64bit downloads for XP and up would be > > sufficient. > > As long as someone is willing to do the work to write the installers, > etc. Installers for post-XP tend to be quite different from XP and > earlier. Side by side assemblies and merge modules simply don't work > correctly with the XP version of the Windows Installer framework. > Could make for a bit of fun I guess. How do other installers usually manage it? I've seen plenty that launch the Visual C++ runtime installer when required but that's a fairly ugly solution - especially if the user has to go through it manually rather than have it happen silently in the background. > Figure out a method of cloning me and I will have all of it done in a > week. :-( > Then it really is a pity we don't have a cloning machine. Franks got some fairly long lists of bugs/improvements that need dealing with too. Although I'm hoping a lot of them will be resolved when the dialer disappears and the SSH client is replaced. Which, now that I think of it, is another thing that needs to go on the to-do list: the list of K95 2.2 changes needs to be pruned a bit so that it only applies to this program - All the dialer and ssh client upgrades/fixes are no longer applicable. The same goes for the bugs list and probably other lists and notes too. I guess much of that is in the category of release documentation.
Date: Sat, 23 Nov 2013 9:32:07 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: Jeffrey Altman <jaltman@your-file-system.com>, ANONYMOUSCODER > I assume the Sparc port was a similar beast to the PowerPC one. The PPC > one was obviously released in some form (Michal over at > os2museum.comapparently has a proper copy on CD-ROM) - do you know if it > was it ever properly (boxed copies available for order) released? Or was > it like Multitasking DOS 4.0 - only available to people who had contracts? > I'm pretty sure it was on the K95 1.20 CD (the one that didn't have the World Trade Center airbrushed out) as an installation option. > > The point of de-supporting the old platforms is to encourage people to > > move forward to systems that can be secured. The world has changed > > quite a bit since the early 90s. Writing code for old OSes is a nice > > hobby but people actually running them in anything other than a locked > > down emulator is dangerous. > > The hobby crowd would be the target - For personal/at-home use even a > single initial release with no ssh support would be an improvement over > HyperTerm. I would certainly hope there are no organisations out there > running NT4 in a networked environment today (I'm sure there probably are > though. It will be interesting to see how long XP takes to properly > disappear - especially as its Microsofts official solution for running > older software on Windows 7). > If somebody is running an old and insecure version of Windows or any other OS (and nobody has been more vocal about how insecure Windows has been from the very beginning than the Kermit Project), Kermit is going to be the least of their problems. Jeff is working to provide secure modes of network communication to his clients and has a responsibility to give them the best advice. Kermit is something else though. Throughout the years we have found that there will always be people who run old OS's for a variety of reasons, ranging from laziness to highly specialized requirements, most commonly applications they depend on that only run on those old platforms. A suprisingly common example are doctor's and dentist's offices running an accounting and billing system based on 30-year-old versions of Xenix or AT&T Unix. Another example I mentioned before are factory-floor Windows PCs driving computing controlled press brake, flat roll, die-cutting, milling, and drilling machines. In both these cases, the machines are not on the Internet. But even if they are, and even if they aim to upgrade for security, sometimes Kermit is a tool they need to migrate. > On that topic of future KUI work - can you remember how much of the KUI > stuff is actually used? There really does seem like quite a lot in there. > I've certainly never seen a spash screen or a graphical download dialog. > It's a lot of code but it's not functional. Mainly just dialogs partially implemented that don't do anything. For example I recall a lot of work went into a custom file upload dialog, in which you could browse all over your to put together a list of files to be uploaded, selected from all different directories, something that MS's GUI APIs made no provision for. I think it would be massive job to make a fully GUI version of this program. We did this 30 years ago for the Macintosh (Mac Kermit was based on C-Kermit), and that was when C-Kermit was much simpler than it is now, and it was a dead end because, GUIs are moving targets, whereas text is pretty much "eternal", or at least stable. Microsoft (and Apple) have few qualms about changing the rules, requiring millions of developers to scramble to "upgrade" their code to the latest "standard" and a lot of perfectly good products disappear because of this. Personally I like K95G.EXE the way it is. The only GUI add-on that would make sense to me would be a file upload dialog. Not necessarily the super-flexible one I just mentioned; just a normal browse box would serve nicely since picking files out of diverse directories is something few people would ever do, and since Kermit automatically switches between text and binary mode based on each file's contents, so there don't need to be a lot of doodads in the dialog (e.g. a text/binary selection for each file, as I believe we had in the first try). On the other hand if you type HELP SEND at the prompt you can see how complex a fully functional upload dialog could be! But once we start competing with Terraterm and PuTTY and HyperTerm in the user interface area, I think we'll lose what's special about Kermit. The good thing about Kermit is what it does (and how well it does it), not how it looks. Its text-based interface is what makes it extendable and automatable. Let everybody else waste their time with on form while we provide content. > I'm starting to think we could also do with some form of issue tracker. > Currently my To-Do list is on a bunch of pieces of (small) paper from a > pad I found in my mailbox from a real-estate agency. It has some guys face > taking up a fifth of the already small page. > As you noted I have all kinds of bug lists and to-do lists, and these should certainly be updated, edited to remove Dialer references, and so on. We'll have to settle on a process for doing that. I realize you guys prefer modern automated web-based things, but these come and go with amazing speed. I'd just as soon do it manually on the Kermit website with good old hand-made web pages that I update daily. But I'm not a fanatic about it. > Then it really is a pity we don't have a cloning machine. Franks got some > fairly long lists of bugs/improvements that need dealing with too. Although > I'm hoping a lot of them will be resolved when the dialer disappears and > the SSH client is replaced. > Personally I'm anxious for the day when I can build it myself on my own PC so I can work on certain bugs that have driven me crazy for years without having to bother anybody else about it. I realize I could do this right now, thanks to you guys, but I'd rather wait until we settle on a tool set, makefile, etc. By the way, I was very happy to see keyboard macros working again for the first time in 10 years! (In which you can assign the execution of an arbitrarily complex Kermit macro to a keystroke; this was broken inadvertantly in the 2.1.3 release.) > Which, now that I think of it, is another thing that needs to go on the > to-do list: the list of K95 2.2 changes needs to be pruned a bit so that it > only applies to this program - All the dialer and ssh client upgrades/fixes > are no longer applicable. The same goes for the bugs list and probably > other lists and notes too. I guess much of that is in the category of > release documentation. > I'll do that, OK? It's on my list. - Frank
Date: Sun, 24 Nov 2013 11:56:42 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: Jeffrey Altman <jaltman@your-file-system.com>, ANONYMOUSCODER On Sun, Nov 24, 2013 at 3:32 AM, Frank da Cruz <fdc@columbia.edu> wrote: > But once we start competing with Terraterm and PuTTY and HyperTerm in the > user interface area, I think we'll lose what's special about Kermit. The > good thing about Kermit is what it does (and how well it does it), not how > it looks. Its text-based interface is what makes it extendable and > automatable. Let everybody else waste their time with on form while we > provide content. > I think a new-connection dialog (like the PuTTY one but more usable) that optionally displays on startup would make sense. It would allow new users to do something useful straight away and see what the program is like without having to check any getting-started documentation. Anyway, the reason I asked about the KUI stuff is really just because if its unused its only getting in the way at the moment. Any old half implemented upload dialogs, etc, may as well just be deleted to trim that part of the codebase down to a more manageable size. If anyone did ever want to revive any of it its still in source control and can be easily restored in the future if needed. > As you noted I have all kinds of bug lists and to-do lists, and these > should certainly be updated, edited to remove Dialer references, and so > on. We'll have to settle on a process for doing that. I realize you guys > prefer modern automated web-based things, but these come and go with > amazing speed. I'd just as soon do it manually on the Kermit website with > good old hand-made web pages that I update daily. But I'm not a fanatic > about it. > The advantage of the web-based issue tracker programs is that other people can add bugs/features to the list and everyone can comment on them, see who is currently working on them, attach screenshots and debug logs, etc. But at the moment we don't need any of that. I expect once this is all more public people will end up just using the issue tracker that's built into github. > Personally I'm anxious for the day when I can build it myself on my own > PC so I can work on certain bugs that have driven me crazy for years > without having to bother anybody else about it. I realize I could do this > right now, thanks to you guys, but I'd rather wait until we settle on a > tool set, makefile, etc. > I think we've largely settled on a tool set. GCC support will appear eventually but Visual C++ support isn't going anywhere, especially for the newer compilers. If you grab the 2005 or 2008 compiler (links are further up in this thread somewhere) you'll probably be fine for a couple of years. the .bat files have been fixed up too so all you've got to do to build it is adjust & run setvars.bat and run mkg.bat
Date: Sun, 24 Nov 2013 16:03:53 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: Jeffrey Altman <jaltman@your-file-system.com>, David Goodwin <david@zx.net.nz> > Good news - I have a very early implementation of putty-based ssh > within K-95 working. > > I used ckossh.c, the only left over portion of the previous > implementation, as a guide. The basic idea is, I believe, the same, > where the SSH event loop runs in a separate thread and calls to > ssh_tchk, ssh_inc, ssh_xin, ssh_toc, and ssh_tol communicate > unencrypted data with the SSH thread using IPC. I am using Dave > Hart's implementation of pipes with asynchronous support > (http://www.davehart.net/remote/PipeEx.c). > > While I have not done enough analysis or testing to ensure that this > will be robust against deadlocks, blocking syscalls or other > synchronization problems, the initial results are > promising--transferring a 120 mb file over 100 Mbps ethernet takes 54 > seconds in old K-95 and 12 seconds using my test code. > Whoa! Sundays seem to be productive days. I just uploaded C-Kermit 9.0 Dev.07: http://www.kermitproject.org/ckdaily.html (reload if necessary). Hopefully I didn't screw anything up. Also there is a brief web page about this -- nothing links to it so don't worry -- that just shows the current status. Comments welcome. ANONYMOUSCODER, about your diffs: For Android, I changed your change to ckuusy.c; it's better to leave the nolocale option there so it's available in all versions, even if it doesn't do anything; that way we don't get fatal errors if some shell script uses it in a Kermit invocation. So instead, I changed the nolocale definition in ckcmai.c to set nolocale according to whether HAVE_LOCALE was defined. For the Windows changes... #ifdef NZXPAND -_PROTOTYP( int nzxpand, (char *, int) ); +_PROTOTYP( int nzxpand, (CHAR *, int) ); /* signed/unsigned issue */ Oops! It's char in Unix but CHAR in Windows. Probably it should be CHAR for all platforms but I suspect it's char in Unix for a reason so I changed it only #ifdef OS2. Other patches, OK, except sometimes I used a different style. Also, I updated the NEWS command, fixed some dates, updated some URLs, commented out any calls to shoreg(), changed the program name to C-Kermit, etc. The SUPPORT command in the current code should be OK. The startup greeting should come out OK, but we'll see. If any changes are needed to my code, let me know and I'll take care of it asap. - Frank
Date: Sun, 24 Nov 2013 16:30:04 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: Jeffrey Altman <jaltman@your-file-system.com>, David Goodwin <david@zx.net.nz> I forgot to say that I didn't do anything about the "K95" version number, but I think I agree with Jeff. If it's C-Kermit it might as well use the regular C-Kermit version number. So next time, I'll make that change too. - Frank
Date: Mon, 25 Nov 2013 23:25:00 +1300 Subject: Re: PuTTY ssh From: David Goodwin <david@zx.net.nz> To: ANONYMOUSCODER Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> On 25 November 2013 08:50, ANONYMOUSCODER wrote: > Good news - I have a very early implementation of putty-based ssh > within K-95 working. > At this rate we might actually have an ssh-enabled release out before christmas!
Date: Mon, 25 Nov 2013 13:57:00 -0500 Subject: Re: PuTTY ssh From: ANONYMOUSCODER To: David Goodwin <david@zx.net.nz> Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> On Mon, Nov 25, 2013 at 5:25 AM, David Goodwin <david@zx.net.nz> wrote: > At this rate we might actually have an ssh-enabled release out before > christmas! > Ideally - I do need to take a break to get back to day job and at some point I need to learn enough about Git so that our codebases don't diverge.
Date: Tue, 26 Nov 2013 10:01:08 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> To: ANONYMOUSCODER, Frank da Cruz <fdc@columbia.edu>, David Goodwin <david@zx.net.nz> Subject: Re: PuTTY ssh You should be able to use ckossh.c pretty much as is. Just fill in the details for your implementation. I believe the pipe handling loop is present in ckossh.c Here is the guide to Git that we wrote for OpenAFS http://wiki.openafs.org/GitDevelopers/
Date: Sun, 1 Dec 2013 22:59:00 -0500 Subject: Re: PuTTY ssh From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Hi Frank: line 96 of ckcsig.h shouldn't have + at front of line definition of SHOLOC on line 2007 of ckuusr.h shouldn't be wrapped in HAVE_LOCALE to handle the situation you described in your first paragraph. I have been trying to get K-95 to build with Visual C++ now... something between the original k95source.zip and David's version mysteriously changed such that if I build the old version, I get an executable that crashes on the first launch, yet works on subsequent launches until reboot, yet David's version always works. My versions built with GCC worked fine every time. Strange.
Date: Mon, 2 Dec 2013 19:36:03 +1300 Subject: KUI Cleanup From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com>, ANONYMOUSCODER Hi Everyone, I've been having a look through the KUI code to try and figure out what is actually required by k95g. It turns out probably half of it is either unused, inaccessible (part of the code path to get to them (eg, menu items) is commented out/missing) or unimplemented (an empty class that does nothing). The following modules in particular are relatively easy to remove: kcliserv KClientClientServ clientserver window's client area kcmdcom KCmdCommuniocations command processor for comms property page kcmddown KCmdDownload command processor for download property page kcmdlog KCmdLogfiles command processor for longfile property page kcmdmous KCmdMouse command processor for mouse property page kcmdproc KCmdProc base class for command processing used by property pages kcmdprot KCmdProtocol command processor for protocol property page kcmdscri KCmdScript command processor for script property page kcmdterm KCmdTerminal command processor for terminal property page kcmdup KCmdUpload command processor for upload property page kcolor KColor color dialog box kcommand KCommand command window kcserver KClientServer clientserver window kflname KFileName [looks like something to do with uploading files] kprop KProperty main property dialog box ksplash KSplash Splash Screen kupload KUpload upload dialog box (there is actually more than just this but some of it is a bit too well embedded in the C-Kermit bits to bother ripping out before upgrading to C-Kermit 9.0) While the above stuff is all inaccessible it is still all wired up and present in the executable. For example, if you send the right messages to the retail release of K-95 you can summon up a partially functional settings dialog: http://ftp2.zx.net.nz/pub/Kermit95/k95-213-settings.png (there is a font dialog too which actually seems to work). This means that while its all unused its still there getting in the way. Does anyone mind if this stuff is just deleted?
Date: Mon, 02 Dec 2013 08:46:50 -0500 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: David Goodwin <david@zx.net.nz>, Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER Subject: Re: KUI Cleanup A bit of background. The original plan was to replace the dialer with a full set of functions matching the C-Kermit command processor options. The underlying problem is that the C-Kermit command processor is not thread safe. It is designed to be run as a single thread in a process that only has one thread. The KUI dialogs and multiple windows for terminal and commands at the same time were implemented or partially implemented. The work stopped because a redesign of C-Kermit's command processor was not in the cards. Essentially the C-Kermit processor must be redesigned so that multiple instances can operate at the same time within the same process. For that to happen all global state must be removed and converted into per-thread context state. This could be done by adding a global context and per-thread context object to each function. The command parser would also need to permit interruption by asynchronous events. I do not imagine that this work would occur any time soon (if ever). The KUI code is in the repository. Remove components one change at a time so that the removal can be reversed if it is desired. Jeffrey Altman
Date: Fri, 22 Nov 2013 00:19:49 -0500 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> I looked into the possibility of merging the current C-Kermit sources with Kermit 95. This looks to be trivial, in fact, much easier than I expected. As a bonus, and as Frank expected, we get OpenSSL 1.0 support for free. I agree that it would be better to try and merge my work on the original k95source.zip with David's git repository. This won't be worthwhile until I get a copy of Visual Studio (I have one, somewhere) and set it up so that I can get a single code base compiling with both VC++ and mingw32. I probably won't get to this until over Thanksgiving. I would like to document what each -D compiler command line option is actually doing as part of this. As there are a number of discussion items, I will try to address them individually. Version number ============== Any reason it can't be called C-Kermit 9.0.304dev06, 21 Nov 2013, for 32-bit Windows, or "Kermit" for short in the prompt and window title? Or if keeping the Kermit 95 name, just bump the version to stay in lockstep with C-Kermit? Especially if the eventual goal is to merge the sources with C-Kermit into a single ckuNNN.tar file. GCC changes that may break VC++ =============================== As David alluded to, the construction (FARPROC) xxxx = yyyy is used often. This helps in VC++, but gcc does not allow type casts on the left side of an assignment operator. I dealt with this by stripping out all instances of (FARPROC). If this only causes VC++ to generate a warning, we should just disable the warning. If it truly causes an error, we should make a compiler dependent macro so that FARPROC_CAST and HANDLE_CAST can be used to generate (FARPROC) and (HANDLE) with VC++ and empty strings on gcc, respectively. GCC changes that shouldn't break VC++ ===================================== Both the VC++ and gcc builds are passing flags to cause the compiler to treat all "char" as unsigned. However, there are places where the headers declare a prototype with CHAR and the .c file uses char, or vice versa. VC++ must treat these as equivalent, but gcc generates an error even with -funsigned-char. There are several places where a function is declared as static and then implemented as non-static, or vice versa. GCC won't allow this, but VC++ must handle it. There are a handful of inline functions (IsUnicode being one example) that are implemented in header files. GCC requires these be defined as "static" to avoid link time duplicate function errors. SSH support =========== I think several of you have mentioned an interim solution of allowing K-95 to start a subprocess, such as Plink, with its stdin, stdout, and stderr redirected to the terminal emulator. I agree, this would allow similar functionality to the "set net type pty" on Unix, and would also allow Android "adb" to be run inside Kermit, as is possible on Unix. In the long term, as far as built in support, having OpenSSL 1.0 available certainly can't hurt. Remaining issues before merge ============================= Before I attempt to merge my changes with David's I would like to (1) get Visual C++ compiling my code, so we can have both compilers working, and (2) get the GUI version working with gcc. C-Kermit changes ================ The changes I had to make to C-Kermit 9.0.304dev06 to get it to integrate with K-95 are given below. If these could be included in dev07, that's one less integration issue. I may not have all the #ifdef conditions exactly appropriate, so please review as needed. Thanks --- vanilla_cku/ckcdeb.h 2013-07-24 15:09:23.000000000 -0400 +++ cku_k95_merge/ckcdeb.h 2013-11-21 23:43:15.703596666 -0500 @@ -2809,7 +2809,7 @@ #else /* _M_PPC */ #ifndef NO_SSL #define CK_SSL -#define SSLDLL +/*#define SSLDLL*/ /* OpenSSL included at link time now. */ #endif /* NO_SSL */ #endif /* _M_PPC */ #ifndef NO_KERBEROS @@ -5371,7 +5371,7 @@ _PROTOTYP( int zclosf, (int) ); #endif /* MAC */ #ifdef NZXPAND -_PROTOTYP( int nzxpand, (char *, int) ); +_PROTOTYP( int nzxpand, (CHAR *, int) ); /* signed/unsigned issue */ #else /* NZXPAND */ _PROTOTYP( int zxpand, (char *) ); #endif /* NZXPAND */ @@ -6062,7 +6062,6 @@ #endif /* def MAXPATHLEN [else] */ #endif /* def VMS [else] */ #endif /* ndef CKMAXPATH */ - /* Maximum length for the name of a tty device */ #ifndef DEVNAMLEN --- vanilla_cku/ckcker.h 2010-04-02 13:13:36.000000000 -0400 +++ cku_k95_merge/ckcker.h 2013-11-21 23:44:03.788995516 -0500 @@ -1309,7 +1309,7 @@ #else /* OS2 */ _PROTOTYP( int conect, (void) ); #endif /* OS2 */ -_PROTOTYP( int ckcgetc, (int) ); +/*_PROTOTYP( int ckcgetc, (int) );*/ /* only used in same .c as definition */ _PROTOTYP( int ckcputc, (int) ); _PROTOTYP (int mdmhup, (void) ); _PROTOTYP( VOID herald, (void) ); --- vanilla_cku/ckcsig.h 2009-10-16 11:35:22.000000000 -0400 +++ cku_k95_merge/ckcsig.h 2013-11-21 23:44:13.035879914 -0500 @@ -90,7 +90,7 @@ #define cklongjmp(x,y) siglongjmp(x,y) #else #ifdef NT -__inline int +static __inline int /* duplicate definition issue */ ck_ih(void) { extern int TlsIndex; #ifdef NTSIG --- vanilla_cku/ckcuni.h 2009-10-16 11:36:04.000000000 -0400 +++ cku_k95_merge/ckcuni.h 2013-11-21 23:45:15.955093315 -0500 @@ -225,7 +225,7 @@ #endif /* CK_ANSIC */ extern struct x_to_unicode * txrinfo[MAXTXSETS+1]; -_PROTOTYP(int isunicode, (void)); +_PROTOTYP(static int isunicode, (void)); /* duplicate definition issue */ _PROTOTYP(int utf8_to_ucs2, (CHAR, USHORT **)); _PROTOTYP(int ucs2_to_utf8, (USHORT, CHAR **)); _PROTOTYP(int tx_cpsub, (USHORT)); @@ -240,7 +240,7 @@ #ifdef OS2 #ifdef NT -_inline +static _inline /* duplicate definition issue */ #else _Inline #endif /* NT */ --- vanilla_cku/ck_ssl.c 2012-07-20 15:45:46.000000000 -0400 +++ cku_k95_merge/ck_ssl.c 2013-11-21 23:53:51.096653159 -0500 @@ -2743,6 +2743,7 @@ char * tls_userid_from_client_cert(ssl) SSL * ssl; { +#ifndef OS2 /* K-95 doesn't have X509_to_user */ static char cn[256]; static char *r = cn; int err; @@ -2759,6 +2760,9 @@ } else return r = NULL; +#else + return NULL; +#endif /* OS2 */ } unsigned char ** @@ -3062,6 +3066,7 @@ int tls_is_user_valid(SSL * ssl, const char *user) { +#ifndef OS2 /* K-95 doesn't have X509_userok */ X509 *client_cert; int r = 0; @@ -3076,6 +3081,9 @@ X509_free(client_cert); return r; +#else + return 0; +#endif /* OS2 */ } int --- vanilla_cku/ck_ssl.h 2012-05-28 14:52:42.000000000 -0400 +++ cku_k95_merge/ck_ssl.h 2013-11-21 23:58:00.729532319 -0500 @@ -152,10 +152,10 @@ _PROTOTYP(int ck_X509_save_cert_to_user_store,(X509 *)); /* SMS 2007/02/15 */ _PROTOTYP(int ssl_check_server_name,(SSL * ssl, char * hostname)); -#ifdef OS2 +/*#ifdef OS2 #include "ckosslc.h" #include "ckossl.h" -#endif /* OS2 */ +#endif*/ /* OS2 */ /* SSL in K-95 is no longer a special case */ #define SSL_CLIENT 0 #define SSL_SERVER 1 --- vanilla_cku/ckuus4.c 2013-07-24 15:09:23.000000000 -0400 +++ cku_k95_merge/ckuus4.c 2013-11-21 23:49:58.661558998 -0500 @@ -62,6 +62,7 @@ #define APIRET ULONG #endif /* NT */ #include "ckocon.h" +#include "ckodir.h" /* for MAXPATHLEN */ #include "ckoetc.h" int StartedFromDialer = 0; HWND hwndDialer = 0; @@ -10383,10 +10384,17 @@ s = "lrwxrwxrwx"; else #endif /* UNIX */ +/* + * K-95 doesn't have ziperm. However, I have not read through this + * code thoroughly, and this needs double checked to see if there are + * any side effects of commenting this out. + */ +#ifdef CK_PERMS s = ziperm(bp[0]); a_ptr[x][4] = NULL; makestr(&(a_ptr[x][4]),s); ckstrncpy(workbuf,s,32); /* Save for later */ +#endif /* Element 5 - Permissions numeric code */ @@ -10396,7 +10404,11 @@ /* Element 6 - Size in bytes */ +#ifdef OS2 /* K-95 doesn't have linkname */ + s = ckfstoa(z); +#else s = zgfs_link ? ckitoa((int)strlen((char *)linkname)) : ckfstoa(z); +#endif a_ptr[x][6] = NULL; makestr(&(a_ptr[x][6]),s); --- vanilla_cku/ckuus6.c 2013-07-24 15:06:53.000000000 -0400 +++ cku_k95_merge/ckuus6.c 2013-11-21 23:36:44.597486165 -0500 @@ -82,6 +82,7 @@ #include "ckntap.h" #endif /* NT */ #include "ckocon.h" +#include "ckodir.h" /* for MAXPATHLEN */ #endif /* OS2 */ extern long vernum, speed; --- vanilla_cku/ckuusr.h 2013-07-24 20:45:27.000000000 -0400 +++ cku_k95_merge/ckuusr.h 2013-11-21 23:51:58.995054622 -0500 @@ -2768,7 +2768,9 @@ _PROTOTYP( int doputenv, ( char *, char * ) ); #endif /* UNIX */ +#ifndef OS2 /* K-95's chkaes is (int, char) instead */ _PROTOTYP( int chkaes, ( char, int ) ); +#endif #ifndef NOICP _PROTOTYP( int matchname, ( char *, int, int ) ); @@ -2871,7 +2873,7 @@ _PROTOTYP( int setfil, (int) ); _PROTOTYP( char * homepath, (void) ); #ifdef OS2 -_PROTOTYP( int settapi, (void) ) ; +/*_PROTOTYP( int settapi, (void) ) ;*/ /* static/non-static issue */ #ifdef OS2MOUSE _PROTOTYP( int setmou, (void) ); #endif /* OS2MOUSE */ --- vanilla_cku/ckuusy.c 2013-07-24 17:37:40.000000000 -0400 +++ cku_k95_merge/ckuusy.c 2013-11-21 22:10:55.646856906 -0500 @@ -1696,7 +1696,9 @@ { "noescape", XA_NOESCAPE, CM_PRE }, #endif /* OS2 */ { "nointerrupts",XA_NOIN, CM_PRE }, +#ifdef HAVE_LOCALE { "nolocale", XA_NOLOCALE, CM_PRE }, +#endif #ifdef KUI { "nomenubar", XA_NOMN, CM_PRE }, #endif /* KUI */ @@ -2895,11 +2897,13 @@ #endif /* NOSPL */ #endif /* NOLOCAL */ +#ifdef HAVE_LOCALE case XA_NOLOCALE: { /* Don't do locale */ extern int nolocale; nolocale = 1; break; } +#endif default: return(-1); }
Date: Fri, 22 Nov 2013 23:34:30 +1300 Subject: Re: C-Kermit 9.0.304dev06 Android fixes From: David Goodwin <david@zx.net.nz> To: ANONYMOUSCODER Cc: Frank da Cruz <fdc@columbia.edu>, Jeffrey Altman <jaltman@your-file-system.com> On Fri, Nov 22, 2013 at 6:19 PM, ANONYMOUSCODERwrote: > I looked into the possibility of merging the current C-Kermit sources > with Kermit 95. This looks to be trivial, in fact, much easier than I > expected. As a bonus, and as Frank expected, we get OpenSSL 1.0 > support for free. > > I agree that it would be better to try and merge my work on the > original k95source.zip with David's git repository. This won't be > worthwhile until I get a copy of Visual Studio (I have one, somewhere) > and set it up so that I can get a single code base compiling with both > VC++ and mingw32. I probably won't get to this until over > Thanksgiving. I would like to document what each -D compiler command > line option is actually doing as part of this. > Microsoft gives out the Visual C++ compiler for free now (just the compiler though - no MFC, IDE or other garbage (although the extremely basic Visual C++ Express Edition IDE should work)). The Platform SDK should give you everything you need. This one should include the 2008 compiler which, while I've never attempted it, should work (2005 & 2010 do): http://www.microsoft.com/en-us/download/details.aspx?id=3138 > As there are a number of discussion items, I will try to address them > individually. > > Version number > ============== > Any reason it can't be called C-Kermit 9.0.304dev06, 21 Nov 2013, for > 32-bit Windows, or "Kermit" for short in the prompt and window title? > Or if keeping the Kermit 95 name, just bump the version to stay in > lockstep with C-Kermit? Especially if the eventual goal is to merge > the sources with C-Kermit into a single ckuNNN.tar file. > Biggest reason to keep them separate is probably the feature and portability differences - unless all the KUI stuff is rewritten the terminal emulator is only available on Windows & OS/2. > GCC changes that may break VC++ > =============================== > As David alluded to, the construction (FARPROC) xxxx = yyyy is used > often. This helps in VC++, but gcc does not allow type casts on the > left side of an assignment operator. I dealt with this by stripping > out all instances of (FARPROC). If this only causes VC++ to generate > a warning, we should just disable the warning. If it truly causes an > error, we should make a compiler dependent macro so that FARPROC_CAST > and HANDLE_CAST can be used to generate (FARPROC) and (HANDLE) with > VC++ and empty strings on gcc, respectively. > I wasn't even sure what I was even looking at when I first saw that - I've never seen type casts done like that before. I've no idea if it produced any runtime issues (I canceled the build to investigate the warnings further) but it only seemed to produce warnings when the cast was absent. Making it into a compiler dependent macro is probably the best option rather than disable the warnings though. > GCC changes that shouldn't break VC++ > ===================================== > Both the VC++ and gcc builds are passing flags to cause the compiler > to treat all "char" as unsigned. However, there are places where the > headers declare a prototype with CHAR and the .c file uses char, or > vice versa. VC++ must treat these as equivalent, but gcc generates an > error even with -funsigned-char. > > There are several places where a function is declared as static and > then implemented as non-static, or vice versa. GCC won't allow this, > but VC++ must handle it. > > There are a handful of inline functions (IsUnicode being one example) > that are implemented in header files. GCC requires these be defined > as "static" to avoid link time duplicate function errors. > > SSH support > =========== > I think several of you have mentioned an interim solution of allowing > K-95 to start a subprocess, such as Plink, with its stdin, stdout, and > stderr redirected to the terminal emulator. I agree, this would allow > similar functionality to the "set net type pty" on Unix, and would > also allow Android "adb" to be run inside Kermit, as is possible on > Unix. > The console version can already do it (set net type command && set host plink.exe). Any program that tries to do anything fancy like colour or moving the cursor around will likely misbehave terribly if it works at all. plinks username/password prompt causes problems here. The GUI version can't do it at all - the program is launched in its own window and the pipes don't get setup properly. Simon Tatham classified the difficulty of this sort of feature as "mayhem: Probably impossible" in PuTTY's win-command-prompt wishlist entry. Support for a local cygwin terminal is much more possible though - a feature I'd like to see in a future version of K95. TerraTerm already has it and there are forks of PuTTY around that do it too. Sadly using K95 as a real SSH client will probably have to wait until the source code for plink is refactored and compiled into K95. In the long term, as far as built in support, having OpenSSL 1.0 available certainly can't hurt.
Date: Fri, 6 Dec 2013 19:56:58 EST From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: PuTTY ssh Hi ANONYMOUSCODER (and everybody), > line 96 of ckcsig.h shouldn't have + at front of line definition of > SHOLOC on line 2007 of ckuusr.h shouldn't be wrapped in HAVE_LOCALE > to handle the situation you described in your first paragraph. > OK, both of these should be fixed or otherwise "improved" now. > I have been trying to get K-95 to build with Visual C++ now... > something between the original k95source.zip and David's version > mysteriously changed such that if I build the old version, I get an > executable that crashes on the first launch, yet works on subsequent > launches until reboot, yet David's version always works. My versions > built with GCC worked fine every time. Strange. > Well, just to move the process along I put up Dev.08 just now: http://www.kermitproject.org/ckdaily.html I tried to remove most of the references to Kermit 95, K-95, and K95 (etc) from the text strings and did some other things too, that are described at the bottom of the NOTES.TXT file: ftp://ftp.kermitproject.org/kermit/test/text/NOTES.TXT As it says there, the MANUAL command is going to require some rethinking. Presently in UNIX, it looks for a man page; in Windows it looks for the online HTML manual, and in VMS it looks for the VMS Kermit Help Topic. Probably these should all be consolidated into a single web reference. But then I'll have to write one. Also I didn't do anything about the filenames we use for the initialization and customization files in Windows (k95.ini, k95site.ini, and k95custom.ini). In Unix we have ~/.kermrc and in VMS ckermit.ini. We probably don't want to use dot-file notation on Windows (right?). I was thinking, however, that maybe .ini is the wrong extension. Maybe ksc would be better, because then you could launch the program from its initialization file because of the file association (which, of course, the installer will have to establish). As a precedent, C-Kermit for Unix and other OS's used have a humongous init file that defined all kinds of macros and services, but I realized that most people didin't use any of it, and it just made it slow to start. And then I learned how to make Kermit scripts self-launching in Unix, so that was the end of the "standard" init file. - Frank
Date: Sun, 19 Jan 2014 15:21:42 +1300 Subject: C-Kermit 9 changes From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Hi Frank, I've finally got around to integrating the latest C-Kermit 9 code into the windows version. While I've not attempted making any connections or transferring files yet it does at least build and run. To make it work a few minor changes to the C-Kermit 9.0.304dev08 code were required. Whats the best way to send these changes back to you? I can provide individual diffs with a description if you'd like. Regards, David
Date: Sun, 19 Jan 2014 9:05:28 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Subject: Re: C-Kermit 9 changes > I've finally got around to integrating the latest C-Kermit 9 code into the > windows version. While I've not attempted making any connections or > transferring files yet it does at least build and run. > Good news! > To make it work a few minor changes to the C-Kermit 9.0.304dev08 code were > required. Whats the best way to send these changes back to you? I can > provide individual diffs with a description if you'd like. > I like plain old plain-text email containing the diffs and any narrative. I always go through diffs line by line rather than applying them with some automated tool. Anyway, glad to hear we're moving again! - Frank
Date: Mon, 20 Jan 2014 12:32:48 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: C-Kermit 9 changes Welcome back! > I've included the diffs below. Two changes were to fix compile errors, > the rest were removing what I hope is the last of the old license > enforcement code. > OK, I put them in. http://www.kermitproject.org/ckdaily.html > Yesterday I had a quick go at producing a 64bit version of C-Kermit > for Windows and managed to get the console version compiling and > running as a telnet client. I'll probably hold off on doing anything > with these patches until I can get the TAPI module and GUI version > compiling though. A fair bit of testing will be required if we ever do > a production-ready 64bit version though as there are probably bugs > lurking that will only appear in 64bit builds (I ran into a number of > functions returning pointers being used without prototypes - no > compile errors or warnings, just a crash at runtime when the upper > 32bits of the pointer are lost). > I think the main thing is to get the long-file access and transfer working; I'm not sure why else we'd need full 64-bit support unless it was to have a near-infinite scrollback buffer. Speaking of the scrollback buffer... It just occurred to me that a nice GUI feature for the new version would be an Edit->Find dialog. There's a way to do that now with a Kverb, but it's pretty obscure. - Frank
Date: Sun, 2 Feb 2014 11:09:10 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz>, ANONYMOUSCODER Subject: KUI Cc: Jeffrey Altman <jaltman@your-file-system.com> I forgot all about this.... Some 1997 screen shots from the "KUI": http://www.columbia.edu/kermit/kuishots.html - Frank
Date: Tue, 18 Mar 2014 9:22:17 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz>, ANONYMOUSCODER Subject: C-Kermit for Windows - any news? Cc: Jeffrey Altman <jaltman@your-file-system.com> Hi guys, Have there been any developments since November? It seemed to me like we were pretty close to having a new version of C-Kermit for Windows that could be built with gcc, that could make SSH connections, that was based on C-Kermit 9.0.304, and that didn't include any proprietary code. If we can put together a consistent source set that meets those requirements -- and it seems to me that between the two of you, the bases are already covered -- I can put it on the Kermit website, announce it, and then suddenly we'll widen the potential base of developers to the whole planet (even me!) and you guys can retire. - Frank
Date: Wed, 19 Mar 2014 09:09:02 +1300 Subject: Re: C-Kermit for Windows - any news? From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> Yeah, we do seem to have lost a bit of momentum which is a pity. We're really quite close to having something ready to go. I've got a week off at the end of April which I plan to do something productive with so I'll see if I can get some proper work done on this then. I might look into sorting out GCC support before then but its not really critical for release. The current state of the codebase up on github ( https://github.com/davidrg/ckwin ) is: * K95 2.2 * C-Kermit 9.0.304 Dev.08 merged in. I've only really tested that it builds and can make telnet connections though - Iarge file support and other things may well be broken * Some unused KUI bits have been removed. There is still some stuff which I've not removed because its rather well integrated (the transfer status window seems to have bits of code everywhere). * All registration code from both K95 and C-Kermit has been removed (I should probably prepare some patches for you if I haven't already) * All modern Microsoft compilers are supported This repository is currently public so anyone who stumbles across it is able to grab the code, make changes and send a pull request to have their changes merged in. Nothing is currently linking to it though so its unlikely anyone will notice its there. I think the only remaining thing (aside from testing the C-Kermit 9 integration and building an installer) is an SSH client. I don't know what the current status of that is but I think once we have one it won't take too long to get a (beta) release up on the website.
Date: Mon, 6 Oct 2014 15:57:01 -0400 Subject: Re: New Kermit 95 From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> Would prefer not to reveal name. I did have a decent start getting SSH through putty's libraries starting to work, I should have a chance to look at that again soon.
Date: Mon, 6 Oct 2014 16:10:13 EDT From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: New Kermit 95 > Would prefer not to reveal name. > OK. > I did have a decent start getting SSH through putty's libraries > starting to work, I should have a chance to look at that again soon. > Should I wait for word from you before publishing the page? You've got a big head start on any newcomers. - Frank
Date: Tue, 7 Oct 2014 15:49:04 +1300 Subject: Re: New Kermit 95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> Hi Everyone, Sadly nothing much has changed from my end since January - been a bit busy with other projects. I think its about time I picked this up again though. The code up on github is fairly current and includes C-Kermit 9.0.304 Dev.08 built-in. Anyone with some recent version (including the free ones) of the Visual C++ compilers installed should be able to produce a graphical windows version of C-Kermit 9 based only on the source code and easy to follow build instructions up on github. Aside from removed proprietary features, SSH and possibly large-file support it seems to work but could do with a regression test. The builds up on my ftp site are fairly out of date at this point (still whatever C-Kermit version K95 shipped with) so I'll try and produce some fresh binaries more suitable for public consumption in the next few days. I'll also integrate the Dev.09 release at the same time so it can be properly up-to-date. I need to send diffs of the multi-platform C-Kermit modules back to you (Frank) sometime too if I haven't already so the changes can be integrated into future C-Kermit releases. I think the plink-based SSH was only present in that one special test build on the ftp server - fresh builds from source don't include it. From memory it sort of worked but wasn't very secure (username & password were visible in task manager) so I didn't pursue it any further. ANONYMOUSCODER's work is the right direction. So the first properly public builds will still be without SSH but maybe it won't stay that way for long. Plus its still a very good terminal emulator even if limited to telnet and serial. And I'm sure it supports the Kermit protocol better than the likes of Tera Term. I'm happy for my name and any emails you think are suitable to be made public. Happy to receive email from new developers too - probably worth setting up a mailing list or newsgroup if enough people turn up. - David
Date: Tue, 7 Oct 2014 20:27:39 +1300 Subject: Re: New Kermit 95 From: David Goodwin <david@zx.net.nz> To: Frank da Cruz <fdc@columbia.edu> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> Fresh build is available here: http://ftp2.zx.net.nz/pub/Kermit95/test_builds/3_0-7-oct-2014/ckn9.0.304.09-3.0-7-oct-2014.zip There is also a handy symlink which I'll keep pointed at whatever is current: http://ftp2.zx.net.nz/pub/Kermit95/test_builds/latest_build.zip This build includes C-Kermit 9.0.304 Dev.09. Sources are of course up on github. Looks like it needs some versioning and naming adjustments though - the GUI still thinks its K-95 3.0. - David
Date: Tue, 7 Oct 2014 10:35:40 EDT From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz> Cc: ANONYMOUSCODER, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: New Kermit 95 OK, I'll delay making this public for a while to see what develops. Meanwhile I updated the page: http://www.kermitproject.org/newk95.html which is still not linked to from anywhere. - Frank
Date: Wed, 8 Oct 2014 22:03:29 -0400 Subject: Re: New Kermit 95 From: ANONYMOUSCODER To: Frank da Cruz <fdc@columbia.edu> Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> The k95bin.tgz on the site is old and didn't have the SSH support added. I should be able to find my code in the next few days. I was having issues being able to go from the command screen and back. I need to study how PuTTY itself operates before continuing. Also, are there any export issues with releasing cryptography-enabled binaries or having to notify anyone? I believe OpenSSL has to deal with this, but maybe source is ok.
Date: Thu, 9 Oct 2014 10:17:24 EDT From: Frank da Cruz <fdc@columbia.edu> To: ANONYMOUSCODER Cc: David Goodwin <david@zx.net.nz>, Jeffrey Altman <jaltman@your-file-system.com> Subject: Re: New Kermit 95 > The k95bin.tgz on the site is old and didn't have the SSH support added. I > should be able to find my code in the next few days. I was having issues > being able to go from the command screen and back. I need to study how > PuTTY itself operates before continuing. > > Also, are there any export issues with releasing cryptography-enabled > binaries or having to notify anyone? > Here are the current guidelines: http://www.bis.doc.gov/index.php/policy-guidance/encryption/ and in particular: http://www.bis.doc.gov/index.php/policy-guidance/encryption/registration#One I'm not a lawyer but it seems K95 might not need permission because it is "Publicly available encryption software and source code under license exception TSU (740.13)"; this category requires a notification but not permission. Or: "License Exception ENC 740.17(b)(1) and Mass Market provision - 42.15(b)(1) allow self-classification of an item and export after submission of a required encryption registration." I'm not sure who is supposed to do this in a case like ours where we are just individuals. > I believe OpenSSL has to deal with this, but maybe source is ok. > It would seem this is still true; see top item here: http://www.bis.doc.gov/index.php/forms-documents/doc_view/328-flowchart-2 It looks like: (a) We can distribute anything we want without notifying anybody if the encryption key lengths are below BIS's limits but evidently PuTTY uses longer keys than that and if we care about security probabably we should too. (b) Maybe we can simply notify, as described above. (c) If we are using Plink out of the box, then if it has export permission, we should be able to piggyback on it. However a cursory Google search only reveals stuff like this: "Some people have asked us for an Export Control Classification Number (ECCN) for PuTTY. We don't know whether we have one, and as a team of free software developers based in the UK we don't have the time, money, or effort to deal with US bureaucracy to investigate any further. We believe that PuTTY falls under 5D002 on the US Commerce Control List, but that shouldn't be taken as definitive. If you need to know more you should seek professional legal advice. The same applies to any other country's legal requirements and restrictions." (d) Somebody who is not in the USA but can build the new K95 from source code can distribute the binary. - Frank
Date: Thu, 09 Oct 2014 10:28:05 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER CC: David Goodwin <david@zx.net.nz> Subject: Re: New Kermit 95 Frank, Unfortunately, "Kermit 95" is not governed by that. Kermit 95 has an explicit product classification and export license determined by BXA from when it was sold as a commercial product. This is one reason that the name should be changed. Assuming the name is changed, the export exception for open source only applies if all of the code is open source and the code has been submitted to the BXA prior to release via e-mail. I don't have the e-mail address handy. The Putty and OpenSSL code having been developed outside the U.S. has not been submitted to BXA. The fact is that most people just export and ignore the issue. Jeffrey Altman
Date: Thu, 9 Oct 2014 11:49:52 EDT From: Frank da Cruz <fdc@columbia.edu> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: ANONYMOUSCODER, David Goodwin <david@zx.net.nz> Subject: Re: New Kermit 95 > Unfortunately, "Kermit 95" is not governed by that. Kermit 95 has an > explicit product classification and export license determined by BXA > from when it was sold as a commercial product. This is one reason that > the name should be changed. > That's a pretty convincing argument. How about we change it (and there is ample precedent for this) to Open Kermit 95, nickname OK95? OK? :-) Maybe we can release it by its 20th anniversary. - Frank
Date: Thu, 09 Oct 2014 11:54:02 -0400 From: Jeffrey Altman <jaltman@your-file-system.com> Organization: Your File System, Inc. To: Frank da Cruz <fdc@columbia.edu> CC: ANONYMOUSCODER, David Goodwin <david@zx.net.nz> Subject: Re: New Kermit 95 On 10/9/2014 11:49 AM, Frank da Cruz wrote: >> Unfortunately, "Kermit 95" is not governed by that. Kermit 95 has an >> explicit product classification and export license determined by BXA >> from when it was sold as a commercial product. This is one reason that >> the name should be changed. > > That's a pretty convincing argument. How about we change it (and there > is ample precedent for this) to Open Kermit 95, nickname OK95? OK? :-) > Maybe we can release it by its 20th anniversary. > Get rid of the 95. It's "Kermit" or "C-Kermit" as it was in the old days. If you must call it "OpenKermit" do so but only if you are calling all of the other Kermits OpenKermit as well.
Date: Fri, 10 Oct 2014 09:51:36 +1300 Subject: Re: New Kermit 95 From: David Goodwin <david@zx.net.nz> To: Jeffrey Altman <jaltman@your-file-system.com> Cc: Frank da Cruz <fdc@columbia.edu>, ANONYMOUSCODER The code up on github largely refers to itself as C-Kermit 9.0.304 at the moment. The GUI title bar ("K-95") and about dialog ("Kermit for Windows 3.0") still need adjusting but that shouldn't be much work. As for export control, Debian went through this a few years ago (see: https://www.debian.org/legal/cryptoinmain) and it looks like they just have to send off a notification to an agency or two when a new piece of software appears that they haven't notified about before.
Date: Mon, 3 Nov 2014 12:02:41 EST From: Frank da Cruz <fdc@columbia.edu> To: David Goodwin <david@zx.net.nz>, ANONYMOUSCODER Subject: C-Kermit updates Cc: Jeffrey Altman <jaltman@your-file-system.com> Hi guys, any progess? I've been avoiding making changes to C-Kermit so as not to complicate any K95 developments, but I had to make some today mainly because of a pretty glaring bug that some users were complaining about (this is how we find out we still have users). The new code is in the usual place: http://www.kermitproject.org/ckdaily.html with changes listed here: ftp://ftp.kermitproject.org/kermit/test/text/NOTES.TXT (at the bottom). - Frank
I haven't revisited since then. Actually integrating the PuTTY code into C-Kermit and calling it upon an SSH session is fairly easily, where I got stuck and stopped was starting to try and make all the "show ssh/set ssh" runtime commands and alt-X out of and into the session actually work robustly.and David Goodwin said:
I'm still around and working on things intermittently as time allows. Lately I've been looking at adding CMake as an alternative to the current build system to allow for building with GCC. Nothing much to announce in this area at this time though. Making things public is probably a good idea. Letting everyone out there know of the existence and location of an up-to-date and compilable codebase might bring out some more people. Plus the current builds of CKfW are really only missing SSH support at this time - for people working with older systems over serial or telnet these builds may still be useful.