view release on metacpan or  search on metacpan

src/Source/LibJPEG/install.txt  view on Meta::CPAN

  2. in event of a fatal error, it exits by calling exit().

A simple stopgap solution for problem 1 is to replace the line
	fprintf(stderr, "%s\n", buffer);
(in output_message in jerror.c) with
	MessageBox(GetActiveWindow(),buffer,"JPEG Error",MB_OK|MB_ICONERROR);
It's highly recommended that you at least do that much, since otherwise
error messages will disappear into nowhere.  (Beginning with IJG v6b, this
code is already present in jerror.c; just define USE_WINDOWS_MESSAGEBOX in
jconfig.h to enable it.)

The proper solution for problem 2 is to return control to your calling
application after a library error.  This can be done with the setjmp/longjmp
technique discussed in libjpeg.txt and illustrated in example.c.  (NOTE:
some older Windows C compilers provide versions of setjmp/longjmp that
don't actually work under Windows.  You may need to use the Windows system
functions Catch and Throw instead.)

The recommended memory manager under Windows is jmemnobs.c; in other words,
let Windows do any virtual memory management needed.  You should NOT use
jmemdos.c nor jmemdosa.asm under Windows.

For Windows 3.1, we recommend compiling in medium or large memory model;
for newer Windows versions, use a 32-bit flat memory model.  (See the MS-DOS
sections above for more info about memory models.)  In the 16-bit memory
models only, you'll need to put
	#define MAX_ALLOC_CHUNK 65520L	/* Maximum request to malloc() */
into jconfig.h to limit allocation chunks to 64Kb.  (Without that, you'd
have to use huge memory model, which slows things down unnecessarily.)
jmemnobs.c works without modification in large or flat memory models, but to
use medium model, you need to modify its jpeg_get_large and jpeg_free_large
routines to allocate far memory.  In any case, you might like to replace
its calls to malloc and free with direct calls on Windows memory allocation
functions.

You may also want to modify jdatasrc.c and jdatadst.c to use Windows file
operations rather than fread/fwrite.  This is only necessary if your C
compiler doesn't provide a competent implementation of C stdio functions.

You might want to tweak the RGB_xxx macros in jmorecfg.h so that the library
will accept or deliver color pixels in BGR sample order, not RGB; BGR order
is usually more convenient under Windows.  Note that this change will break
the sample applications cjpeg/djpeg, but the library itself works fine.


Many people want to convert the IJG library into a DLL.  This is reasonably
straightforward, but watch out for the following:

  1. Don't try to compile as a DLL in small or medium memory model; use
large model, or even better, 32-bit flat model.  Many places in the IJG code
assume the address of a local variable is an ordinary (not FAR) pointer;
that isn't true in a medium-model DLL.

  2. Microsoft C cannot pass file pointers between applications and DLLs.
(See Microsoft Knowledge Base, PSS ID Number Q50336.)  So jdatasrc.c and
jdatadst.c don't work if you open a file in your application and then pass
the pointer to the DLL.  One workaround is to make jdatasrc.c/jdatadst.c
part of your main application rather than part of the DLL.

  3. You'll probably need to modify the macros GLOBAL() and EXTERN() to
attach suitable linkage keywords to the exported routine names.  Similarly,
you'll want to modify METHODDEF() and JMETHOD() to ensure function pointers
are declared in a way that lets application routines be called back through
the function pointers.  These macros are in jmorecfg.h.  Typical definitions
for a 16-bit DLL are:
	#define GLOBAL(type)		type _far _pascal _loadds _export
	#define EXTERN(type)		extern type _far _pascal _loadds
	#define METHODDEF(type)		static type _far _pascal
	#define JMETHOD(type,methodname,arglist)  \
		type (_far _pascal *methodname) arglist
For a 32-bit DLL you may want something like
	#define GLOBAL(type)		__declspec(dllexport) type
	#define EXTERN(type)		extern __declspec(dllexport) type
Although not all the GLOBAL routines are actually intended to be called by
the application, the performance cost of making them all DLL entry points is
negligible.

The unmodified IJG library presents a very C-specific application interface,
so the resulting DLL is only usable from C or C++ applications.  There has
been some talk of writing wrapper code that would present a simpler interface
usable from other languages, such as Visual Basic.  This is on our to-do list
but hasn't been very high priority --- any volunteers out there?


Microsoft Windows, Borland C:

The provided jconfig.bcc should work OK in a 32-bit Windows environment,
but you'll need to tweak it in a 16-bit environment (you'd need to define
NEED_FAR_POINTERS and MAX_ALLOC_CHUNK).  Beware that makefile.bcc will need
alteration if you want to use it for Windows --- in particular, you should
use jmemnobs.c not jmemdos.c under Windows.

Borland C++ 4.5 fails with an internal compiler error when trying to compile
jdmerge.c in 32-bit mode.  If enough people complain, perhaps Borland will fix
it.  In the meantime, the simplest known workaround is to add a redundant
definition of the variable range_limit in h2v1_merged_upsample(), at the head
of the block that handles odd image width (about line 268 in v6 jdmerge.c):
  /* If image width is odd, do the last output column separately */
  if (cinfo->output_width & 1) {
    register JSAMPLE * range_limit = cinfo->sample_range_limit; /* ADD THIS */
    cb = GETJSAMPLE(*inptr1);
Pretty bizarre, especially since the very similar routine h2v2_merged_upsample
doesn't trigger the bug.
Recent reports suggest that this bug does not occur with "bcc32a" (the
Pentium-optimized version of the compiler).

Another report from a user of Borland C 4.5 was that incorrect code (leading
to a color shift in processed images) was produced if any of the following
optimization switch combinations were used: 
	-Ot -Og
	-Ot -Op
	-Ot -Om
So try backing off on optimization if you see such a problem.  (Are there
several different releases all numbered "4.5"??)


Microsoft Windows, Microsoft Visual C++:

jconfig.vc should work OK with any Microsoft compiler for a 32-bit memory
model.  makefile.vc is intended for command-line use.  (If you are using
the Developer Studio environment, you may prefer the DevStudio project