Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
109
handler, all of which are application-replaceable. (cjpeg/djpeg are more
heavily dependent on stdio.) malloc and free are called only from the memory
manager "back end" module, so you can use a different memory allocator by
replacing that one file.
The code generally assumes that C names must be unique in the first 15
characters. However, global function names can be made unique in the
first 6 characters by defining NEED_SHORT_EXTERNAL_NAMES.
More info about porting the code may be gleaned by reading jconfig.txt,
jmorecfg.h, and jinclude.h.
Notes for MS-DOS implementors
-----------------------------
The IJG code is designed to work efficiently in 80x86 "small" or "medium"
memory models (i.e., data pointers are 16 bits unless explicitly declared
"far"; code pointers can be either size). You may be able to use small
model to compile cjpeg or djpeg by itself, but you will probably have to use
medium model for any larger application. This won't make much difference in
performance. You *will* take a noticeable performance hit if you use a
large-data memory model (perhaps 10%-25%), and you should avoid "huge" model
if at all possible.
The JPEG library typically needs 2Kb-3Kb of stack space. It will also
malloc about 20K-30K of near heap space while executing (and lots of far
heap, but that doesn't count in this calculation). This figure will vary
depending on selected operating mode, and to a lesser extent on image size.
There is also about 5Kb-6Kb of constant data which will be allocated in the
near data segment (about 4Kb of this is the error message table).
Thus you have perhaps 20K available for other modules' static data and near
heap space before you need to go to a larger memory model. The C library's
static data will account for several K of this, but that still leaves a good
deal for your needs. (If you are tight on space, you could reduce the sizes
of the I/O buffers allocated by jdatasrc.c and jdatadst.c, say from 4K to
1K. Another possibility is to move the error message table to far memory;
this should be doable with only localized hacking on jerror.c.)
About 2K of the near heap space is "permanent" memory that will not be
released until you destroy the JPEG object. This is only an issue if you
save a JPEG object between compression or decompression operations.
Far data space may also be a tight resource when you are dealing with large
images. The most memory-intensive case is decompression with two-pass color
quantization, or single-pass quantization to an externally supplied color
map. This requires a 128Kb color lookup table plus strip buffers amounting
to about 40 bytes per column for typical sampling ratios (eg, about 25600