CTCJava 2.0 Beta 2 - update

Testing in advance of Beta 3 has shown that there are some problems with managing keyrings in key generation. This includes some problems with the handle to the JVM environment through multiple levels of calls Java->native->Java->native...; and failing to pick up the keyring files once they have been updated. This will take more than simple refactoring or easy Swing UI tweaks.

If the bug turns out to be made more difficult to resolve because of the back and forth calling, I may end up pulling more of the OpenPGP functionality into the Java layer. I will certainly be making it more C++ with a C interface where that simplifies matters for me.

CTCJava 2.0 Beta 2

Beta 2 of CTCJava 2.0 — a simpler archive structure (archive = archive2 + signature; archive2 = jar+java source zip+dll 2.3.2205.36688+ctcjlib JNI layer source). The main change is that documents are shown in the main window, by selecting the current document from the tree control, though there are other minor UI changes and behind the scenes updates.

There will be at least one more interation with UI tweaks before I declare RC.

CTCJava 2.0 Beta 1

This release is a 7-zip format archive, and uses Java 5 (JRE 1.5) or later, rather than the Java 1.1 of the previous models. The main feature of this release is a replacement of the UI widgets with Java Swing components; and the start of a rework of the way in which multiple open files are managed.

This release archive contains a 7-zip archive with detached signature; within that 4 other such archives, each containing a file and its detached signature. The files in the innermost archives, the ones with accompanying signature, are

1. CTCJava.jar — the compiled file including icons (Both the “Dean's icons” set used before, and the preferred Tango Project set.
2. java.zip — the refactored source code
3. ctcjlib.dll — version 2.3.2192.30638; modified from the previous version to take into account changes in the names of classes and methods in the Java code
4. ctcjlib-src.zip — the modified source used to build the above.

I shan't make promises about the likely schedule of further updates.

CTCjlib -- IMPORTANT UPDATE!

The previous CTCjlib update (2.3.2178.34472) was built off an experimental (and broken) code-base, the result of my having set the project aside some years (and computers) ago, and taking from the wrong repository.

I have now reverted the code-base to the last released archive from this site, and built CTCJlib.dll v 2.3.2181.36359 from that. As noted before, this incorporates the fix noted in the 26-Jun-05 entry below, plus the altered source files, and with detached signatures in the archive too.

Please accept my apologies, and — Enjoy!

Enkoder applet

“E”-ddress encoder 1.0 — a utility based on the the old Hiveware “Enkoder”, only this one is a Java app/applet. Offered into the public domain.

PassiveFTP 1.8

PassiveFTP 1.8 — build 1.8.2127.30224 — minor bug-fix release — only treats client-side executables as possibly having unique icons, so does not get icon creation failures when scanning client-side folders with vary many files. Also set default upload to dial-up compatible 2kb/s for best observed stability.

From the windows page

CTClib inflate issue

The CTClib deflate implementation follows PGP 2.x in limiting the compression window to 8k; it also limits the decompression window similarly. Other implementations e.g. Bouncy Castle, do not heed this limitation. Andrew Paterson writes:

Since my last e-mail, I did a quick experiment and I have established that, as you suggested, the 8K window size was the culprit. As it was easier to modify CTC, I changed the definition of WSIZE back to 32K (0x8000) in gzip.h then defined WSIZE as 8K (0x2000) in deflate.c before gzip.h was included. That did the trick! Encryption/signing (deflating) uses an 8K window size whilst decryption (inflating) uses a 32K window size. Problem solved and, as a bonus, the compatibility of CTC is actually increased.

Unfortunately, it does mean that I will have to rebuild/redeploy all of my software that uses CTC but I think I prefer that to using an uneasy hybrid of Sun JDK, hacked Bouncy Castle JCE and hacked GNU Classpath zip classes. There are also licence implications in that the Bouncy Castle crypto libraries are not under the GPL whereas the GNU Classpath classes obviously are.

Look for an update build sometime.