2002.05.17 ~11  Project FI zlib

For the hell of it, I threw in zlib to the compile pipeline.  Only two
modifications were needed to compile cleanly: (1) getting rid of "short"
(16-bit integer), which QVM bytecodes doesn't like for endian reasons, and
(2) defining fdopen(), which zlib manages to use some place.  Actually,
fdopen just returns NULL (signifying error (to wit, "not implemented yet",
but errno isn't set properly (there's no EDAMNPROGRAMMERWASTOOLAZY))).

This is only sufficient to get an error-less compile.  Actual (de)compres
has not been done.  I'm not sure how the semantics would change, especially
since "short" was simply jacked up to a full "int" (32-bit), and there are
all sorts of short-based offsets and (de)referencing throughout zlib.
OTOH, Ogg Vorbis used arrays of shorts, and promoting those didn't break it
horribly.

The fdopen() whacking disturbs me, though.  There's only one use of fopen
in zlib, and that's just to (re)generate the compile-time file trees.h.
All other functions related to I/O points back to fdopen().  Trying to
implement fdopen() in QVM is quite non-trivial.  It basically goes
something like this: EOF is determined by recording the file length and
checking current file position against that.  File length is obtained at
open time as the return value of trap_FS_FOpenFile.  This trap will only
accept a file name (to specify a particular file).  File name is not
recorded elsewhere by the trap, i.e. there is no native means of obtaining
the file name give the file handle/descriptor.  In effect, given just a
file descriptor, EOF-ness cannot be determined, as the length is not
available.  The return value of trap_FS_Read() will return the final
character of the file upon EOF; in this regard, a repeat character is
indistringuishable from EOF state.

There are a few attacks at this problem I can think of.  One is writing
wrappers around the traps (the trap_*() are already wrappers around a
generalized syscall trampoline), to keep track of the fd-filename
association.  Another is to just traverse the array of stream objects,
searching for any member that has a record (bad pun) of the given file
descriptor in hand, then resurrecting or copying the object.  Another is to
cannibalize parts of PalmZlib that may help with regards to I/O (fdopen in
particular) in a crippled environment.  Or maybe a combination.  Yes,
perhaps a combination...