Welcome to the SQLitening support forums!
Started by Jean-Pierre LEROY, May 02, 2011, 11:41:32 AM
QuoteQ1. I don't use "encryption" or "compression" with SQLitening so why zlib.dll is needed for SQLiteningClient.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 ?
QuoteQ3. Is-there any other workaround in order to be able to use SQLitening and libHaru library with there own version of zlib ?
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.
QuoteHPDF_SetCompressionMode()HPDF_STATUS HPDF_SetCompressionMode (HPDF_Doc pdf, HPDF_UINT mode);DescriptionHPDF_SetCompressionMode() set the mode of compression.Parameterspdf - 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 ValueWhen 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.