Subject: Big wv/LibOLE2 patch
From: James Montgomerie (jamie@montgomerie.net)
Date: Tue May 30 2000 - 17:39:56 CDT
I've finally managed to find some time to work on this, and attached are two
patches (one for the abi tree, one for the wv tree) which implement the
LibOLE2/wv integration talked about a couple of months ago.
I think it's stable enough to be integrated with the tree, save for a few
things:
I'm not sure about endianness. Hopefully, it'll work as-is, but It might
need a couple of (simple) changes will need to be made if it doesn't. I'd
be grateful if people with non-Intel endian try importing a few documents
and report on success/failure.
Dom Lachowicz expressed some concerns about his glib mini-port (used by
LibOLE2 if glib is not found on the local system) compiling under non-Linux
systems. There were no problem reports at the time, but it's something to
look out for.
LibOLE2 likes to uses mmap. I /think/ any problems should be taken care of
by the make system (the mmap-using bits were kindly put in #ifdef HAVE_MMAPs
for us by the LibOLE team), but, again, it hasn't been tested, so be on the
lookout for it not working.
I also haven't performed much regression-testing (being limited in the
number of Word documents I have). I'm confident everything runs smoothly
(indeed, if anything, the use of LibOLE2 should make us /more/ compatible),
but I'd be grateful if everyone could test documents that they know used to
work and documents they know used to not work and report any anomalies
(remember to report positive (i.e. not working -> working) results too!).
Below, for those interested, a little description of what's changed
internally:
The FILE* streams which wv used to use for decoding documents were replaced
with an abstraction layer called 'wvStream' with it's own file I/O like
functions in an earlier patch. This abstraction layer has now been made
more complete, with functions for creating and cleaning up streams in an
implementation-independent manner in support.c.
The underlying structure of the wvStreams has been changed (easy to do,
thanks to the abstraction layer) into a more 'dynamic' structure which can
either hold a FILE* or a MsOleStream* (from LibOLE2), and can determine it's
own type at runtime.
When attempting to open a document wv now tries to use LibOLE2, and
constructs it's wvStreams based on the MsOleStreams that LibOLE2 creates.
If, for some reason, LibOLE2 fails, it then falls back onto the older
routines, and creates wvStreams based on FILE*s. This means that it
/should/ still be able to open and happily deal with the old, pre-OLE
documents that wv used to support, but LibOLE2 doesn't.
Miscellaneous other small changes have also been made (like passing char*s
containing file paths in some places where we used to pass FILE*s, because
LibOLE2 needs the paths), but nothing that should impact functionality.
Jamie.
This archive was generated by hypermail 2b25 : Tue May 30 2000 - 17:38:08 CDT