2002.05.27 ~00  PiNGer.JPEG

http://palmboxer.sourceforge.net/

What is now known as ZBoxZ was known as Palmboxer, prior to a sawfishian
(re)naming... incident.  ZBoxZ is a GPL'd file manager application, with
several satellite applications (plugins, if you will).  Among them is
PiNGer, an image viewer, to view files packaged in "boxes" (some sort of
PDB encapsulation of files), which supposed displays GIF (87 and 89) and
PNG images.  So far only PNG works (as an aside, the GIF portion was based
on gif2png, but a source check against gif2png 2.4.2 shows the GIF code in
PiNGer to be inconsistent).

I spent the last couple of days banging on PiNGer for JPEG support.  One
breakthrough discovery (for me, at least) is an alternative PalmOS library
mechanism called "GLib" (no relation to GTK+'s glib).  The original library
mechanism, SysLib, requires all library functions to take a library refnum
as their first argument.  Eyemodule (a Handspring Visor camera thingy,
http://www.eyemodule.com) already did a port of IJG's JPEG library
("libjpeg") to PalmOS using the SysLib method, requiring a mass of wrapper
code to expect the refnum argument.  Unfortunately, Eyemodule's JPEG port
only covers the compression half (i.e. from Eyemodule image data to
JPEG-in-PDB).

GLib, on the other hand, doesn't require this refnum passing doohickey.  I
suspect this is based on using one of the spare registers on the M68K.  In
any case, porting existing *nix libraries is more straightforward, since the
necessary state munging is left to the compiler instead of the developer.
There are still other brick walls, like the 32K code segment limit.  Which
libjpeg slams into at 130KB.

Cue a prc-tools hack, the multiple resources mechanism.  The basic idea is
to divvy up the code into a bunch of <32K segments, then glue them together
with jump tables.  The developer still has to mark how the code will be
split, but the glue stuff is done automagically by the tools.  This method
comes with a cost: reaching across the boundaries is time-consuming.

What is not clear to me, though, is whether using both GLib and multiple
resources is canon.  I've already marked libjpeg for the various sections,
and already set it up for GLib-style shared-library compilation, but
linking this to PiNGer and using a jpeg function causes catastrophe.

Then I tried regular static library (.a) linkage without multi-res.  That
broke 32K easily.  Then I split up PiNGer and relinked.  Near as I can
tell, it falls over when it dereferences a function pointer to a function
in another segment.

Nonetheless, my meddling in PalmOS programming is enlightening me on
matters of Q3 modding.  In particular, toolchains, library, C extensions,
limited environment, assembly.