gpack.dll version 0.1
gpack.zip 387682 bytes

This is a dynamic link library which packs 4 graphic file format related
libraries into 1.  Namely
	libtiff	version 3.4beta 36
	libjpeg	version 6.2
	libpng	version 1.01
	libz	version 1.12
are contained in gpack.dll  The basic idea is to avoid name conflicts and
to achieve binary compatibilities across versions of these libraries.

Due to OS/2 restriction, you cannot load different DLLs of the same name
at the same time.  Moreover in order for two different versions of the same
DLLs to be binary compatible, the ordinal for each pair of corresponding
entry points must be the same.

Unfortunately there are no standardized ordinal assignments for entry points
of any of the above mentioned libraries.  You can typically observe this
misfeature by looking at module definition files for MS Windows comes with
the source distributions of libz and libpng.  OS/2 module definition files
which sometimes comes also with the package has yet to show any causes of
binary incompatibility.  However, since the ordinals for entry points are not
explicitely specified in these files, there always are dangers of future
incompatibilities if the libraries extend their functionalities.  This means
if one of your application uses one version of png.dll and another one uses
another version of png.dll, then it is hardly expected that you can run them
together.

This is my attempt to standardize the ordinal assignments.  
As far as these OS/2 restriction explained above is concerned, I believe I
did it right.  However, there is a possibility that each library may not be
written binary compatible.  It is very unfortunate that it is the case with
libpng and libjpeg.
  - the libpng document says the changes between 0.9x and 1.0 are the last
    binary incompatible ones.  Future versions will be upper compatible to
    1.0  So it is recommended to recompile/relink your applications now if
    they were compiled/linked with the previous release of gpack.dll
    Since the changes between 0.9x and 1.0 are rather minor, you can perhaps
    try setting an environment variable PNG_LENIENT_VERSION_CHK to a non-null
    value e.g. in startx.cmd and see if your applications work without
    recompile/relink.
  - each different version of libjpeg is written deliberately binary
    incompatible.  From this version on, gpack.dll checks with what versions
    of libjpeg your applications are compiled/linked and dynamically loads
    appropriate version of libjpeg into memory.

I didn't linked C++ ziostream interface code into the DLL for several reasons:
  - zfstream can be compiled with emx 0.9c and is compatible with gcc 2.5--2.7,
    but if you want to use the same interface with gcc 2.8, then you have to
    specify -fno-rtti compiler flag.
  - since there is not a DLL version of libstdc++, linking zfstream object into
    gpack.dll requires libstdc++ to be statically linked into the library,
    which causes:
	-- bloat of the DLL
	-- restricted usability of the DLL because of LGPL
  - zstream (another C++ interface) does not work well with gcc 2.7 due to the
    flakey support for template of the compiler.  (And you do not need any
    binary object since all the members are inline.)

Although the libtiff version hasn't changed since the last release, it is now
linked against libjpeg 6.2 rather than 6.1  Also PixarLog compression is newly
supported.

It is compiled for the use for XFree86/OS2 applications in mind.  So be sure to
	use emx (anyway emx runtime is required)
	compile with -Zmt flag
	link with -Zmt -Zbin-files flags
Yet another caveat is that before installing this package you have to rename
z.a and z.lib in XFree86/lib directory to z_s.a and z_s.lib  This is actually
conforming to Imake file rules on OS/2 and shouldn't cause any misbehaviour.

Will be sporadically updated.

Shigeru Miyata (miyata@kusm.kyoto-u.ac.jp)