• Welcome, Guest. Please login.
 

Zlib.dll incompatibility between libHaru (Haru Free PDF Library) and SQLitening

Started by Jean-Pierre LEROY, May 02, 2011, 11:41:32 AM

Previous topic - Next topic

Jean-Pierre LEROY

Hi Fred,

I would like to use the Haru Free PDF Library with one PB project in which I already use SQLitening.

For libHaru I use the headers made by Jose Roca on his WebSite (http://www.jose.it-berater.org/smfforum/index.php?topic=3058.0).

Both dll (libhpdf.dll and SQLiteningClient.dll) use the zlib.dll on the client side.

if I use the zlib.dll (72,5 Ko, 82 functions exported) that is provided with SQLitening version 1.40, my application gpf when I call libHaru functions.

If I use the zlib.dll (59 Ko, 51 functions exported) that is provided with libHaru 2.1.0, libHaru works and it seems that SQLitening is also working correctly ...

I have nevertheless a few questions ...

Q1. I don't use "encryption" or "compression" with SQLitening so why zlib.dll is needed for SQLiteningClient.dll ?
Q2. It is safe to use the zlib.dll file that comes with libHaru with SQLitening on the client side ? again it seems to work but it could be due to the fact that I don't use "encryption" or "compression" with SQLitening ?
Q3. Is-there any other workaround in order to be able to use SQLitening and libHaru library with there own version of zlib ?

Thank you for your help.
Jean-Pierre

Fred Meier

QuoteQ1. I don't use "encryption" or "compression" with SQLitening so why zlib.dll is needed for SQLiteningClient.dll ?
SQLiteningClient.Dll uses Zlib.Dll to compress/uncompress the messages to/from SLQiteningServer.Exe
SQLitening.Dll uses SQLiteningAuxRuts.Dll and Zlib.Dll to compress/uncompress field data but only if you request it.
SQLiteningServer.Exe does not use ZLib.Dll.
QuoteQ2. It is safe to use the zlib.dll file that comes with libHaru with SQLitening on the client side ? again it seems to work but it could be due to the fact that I don't use "encryption" or "compression" with SQLitening ?
No. That ZLib.Dll was compiled with the CDecl calling conventions while the ZLib.Dll released with SQLitening uses SDecl calling conventions which is Windows standard.   See below for there reasons.
QuoteQ3. Is-there any other workaround in order to be able to use SQLitening and libHaru library with there own version of zlib ?
You can recompile SQLiteningAuxRuts and SQLiteningClient changing the Compuress/Uncompress Declares to CDecl.
QuoteFrequently Asked Questions about ZLIB1.DLL

6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
    convention.  Why not use the STDCALL convention?
    STDCALL is the standard convention in Win32, and I need it in
    my Visual Basic project!

    (For readability, we use CDECL to refer to the convention
     triggered by the "__cdecl" keyword, STDCALL to refer to
     the convention triggered by "__stdcall", and FASTCALL to
     refer to the convention triggered by "__fastcall".)

  - Most of the native Windows API functions (without varargs) use
    indeed the WINAPI convention (which translates to STDCALL in
    Win32), but the standard C functions use CDECL.  If a user
    application is intrinsically tied to the Windows API (e.g.
    it calls native Windows API functions such as CreateFile()),
    sometimes it makes sense to decorate its own functions with
    WINAPI.  But if ANSI C or POSIX portability is a goal (e.g.
    it calls standard C functions such as fopen()), it is not a
    sound decision to request the inclusion of <windows.h>, or to
    use non-ANSI constructs, for the sole purpose to make the user
    functions STDCALL-able.

    The functionality offered by zlib is not in the category of
    "Windows functionality", but is more like "C functionality".

    Technically, STDCALL is not bad; in fact, it is slightly
    faster than CDECL, and it works with variable-argument
    functions, just like CDECL.  It is unfortunate that, in spite
    of using STDCALL in the Windows API, it is not the default
    convention used by the C compilers that run under Windows.
    The roots of the problem reside deep inside the unsafety of
    the K&R-style function prototypes, where the argument types
    are not specified; but that is another story for another day.

    The remaining fact is that CDECL is the default convention.
    Even if an explicit convention is hard-coded into the function
    prototypes inside C headers, problems may appear.  The
    necessity to expose the convention in users' callbacks is one
    of these problems.

    The calling convention issues are also important when using
    zlib in other programming languages.  Some of them, like Ada
    (GNAT) and Fortran (GNU G77), have C bindings implemented
    initially on Unix, and relying on the C calling convention.
    On the other hand, the pre- .NET versions of Microsoft Visual
    Basic require STDCALL, while Borland Delphi prefers, although
    it does not require, FASTCALL.

    In fairness to all possible uses of zlib outside the C
    programming language, we choose the default "C" convention.
    Anyone interested in different bindings or conventions is
    encouraged to maintain specialized projects.  The "contrib/"
    directory from the zlib distribution already holds a couple
    of foreign bindings, such as Ada, C++, and Delphi.

Jean-Pierre LEROY

Hi Fred,

Thank you for your reply; in the meantime I found a workaround.

In libHaru, If I set the compression mode to none (no compression) with the command HPDF_SetCompressionMode(), then I can keep your original zlib.dll and use at the same time libHaru; the generated pdf files are a bit bigger but it is not an issue for me.

Here is the description of the HPDF_SetCompressionMode() command; it's an extract from the help file available online at this location : http://libharu.org/wiki/Documentation
Quote
HPDF_SetCompressionMode()

HPDF_STATUS HPDF_SetCompressionMode (HPDF_Doc    pdf,
                                     HPDF_UINT   mode);

Description

HPDF_SetCompressionMode() set the mode of compression.

Parameters

pdf - The handle of a document object.
mode - One or more of the following or'ed together:

    HPDF_COMP_NONE - No compression.
    HPDF_COMP_TEXT - Compress the contents stream of the page.
    HPDF_COMP_IMAGE - Compress the streams of the image objects.
    HPDF_COMP_METADATA - Other stream datas (fonts, cmaps and so on) are compressed.
    HPDF_COMP_ALL - All stream datas are compressed (HPDF_COMP_TEXT | HPDF_COMP_IMAGE | HPDF_COMP_METADATA).

Return Value

When HPDF_SetCompressionMode() succeeds, it returns HPDF_OK. Otherwise, it returns error code and error-handler is called.

Error codes

    HPDF_INVALID_DOCUMENT - An invalid document handle was set.
    HPDF_INVALID_COMPRESSION_MODE - An invalid compression mode was specified.
    HPDF_FAILD_TO_ALLOC_MEM - Memory allocation failed.

I hope that could help other users of SQLitening and libHaru.

Thanks,
Jean-Pierre

Fred Meier

Good, I will consider renaming the ZLib.Dll that SQLitening uses in the next release.  That would eliminate the conflict.

Jean-Pierre LEROY

Fred,

Yes it could be a good idea to do that to avoid definitely a potential conflict in the future.

Thanks,
Jean-Pierre