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.

PassiveFTP 1.7

PassiveFTP version 1.7.1955.38236 — allows the upload rate to be limited for fussy servers.

From the Windows page, as usual.

PassiveFTP problem

I have observed a flaw in the implementation of PassiveFTP. I intended to make the data channel socket non-blocking, but instead re-asserted that for the command channel. Also the host I usually FTP to has started to choke on uploads done at full ADSL rate, so I need to get the non-blocking behaviour fixed, so I can throttle the upload rate appropriately.

Look for an update in the next week or so.

Angerona/CTClib/CTCJava suspended

Well it's probably time to formally declare that there isn't going to be any more work on CTClib, CTCJava or Angerona, except for bug-fixes that affect my own use of the system. It's too much ancient history now.

Strict XHTML Applets

Noting that this page was reached by the search query "Strict XHTML Applets", a brief guide to what I've done along these lines.

I started with Hixie's Embedding flash without <embed>, which nests <object /> tags, but suffers from parameter duplication, and, IIRC, unless I had things back-to-front, it also leaves empty place-holders for the "other platform" applet in some browsers. By using IE conditional comments in a sneaky fashion, one only need duplicate the opening <object> as follows (code based upon that in my N-body applet page):-

<!--[if IE]>

<object archive="nbodyzip.zip" type="application/x-java-object"
code="Nbody.class" width="250" height="150" title="&lambda; Serpentis
II system simulation" standby="standby" >
<![endif]-->

<!--[if !IE]> -->
<object archive="nbodyzip.zip" type="application/x-java-object"
classid="java:Nbody.class" title="&lambda; Serpentis II system
simulation" standby="standby" width="250" height="150" >
<!-- <![endif]-->

<!-- shared parameter tags go here if needed e.g. -->
    <param name="bgcolor" value="#000000" />

<!-- followed by fallback content such as:- -->

    <p>Alas! Either your browser is not one for which I've been able to get
    XHTML object tags to work, or perhaps it's not Java enabled!</p>

<!-- finally close the one object tag -->

</object>

Here IE wants the main-class via the code attribute code="Nbody.class"; whereas Gecko browsers (Netscape, Mozilla, Firefox) want it via the classid attribute, classid="java:Nbody.class". Both use the archive attribute to show where the bytecode is to be found.

This works for Netscape 4 and up. I believe it also works in Konqueror (KHTML), and thus also Safari - but if you know different, please say.

It would be nicer if I could find one tag that would feed Java to all these browsers…

XPP -- XML PreProcessor

XPP 1.0.1708.27390 — Use it to fold repeated units into static pages as a compile-before-upload step for XHTML web pages. See the ReadMe file in the archive for more details.

From the Windows page

PassiveFTP 1.6

PassiveFTP 1.6 — PassiveFTP version 1.6.1701.15662 — when XP SP2 dropped my screen depth from 32-bit to 16-bit off its own bat, all hell broke loose. Fix for the default 16-bit style, maybe all 16-bit and even 24-bit. No 8-bit or less planned.