inline-able.  Some compilers have a switch that tells the compiler to inlineany function it thinks is profitable (e.g., -finline-functions for gcc).Enabling such a switch is likely to make the compiled code bigger but faster.In general, it's worth trying the maximum optimization level of your compiler,and experimenting with any optional optimizations such as loop unrolling.(Unfortunately, far too many compilers have optimizer bugs ... be prepared toback off if the code fails self-test.)  If you do any experimentation alongthese lines, please report the optimal settings to jpeg-info@uunet.uu.net sowe can mention them in future releases.  Be sure to specify your machine andcompiler version.HINTS FOR SPECIFIC SYSTEMS==========================We welcome reports on changes needed for systems not mentioned here.  Submit'em to jpeg-info@uunet.uu.net.  Also, if configure or ckconfig.c is wrongabout how to configure the JPEG software for your system, please let us know.Acorn RISC OS:(Thanks to Simon Middleton for these hints on compiling with Desktop C.)After renaming the files according to Acorn conventions, take a copy ofmakefile.ansi, change all occurrences of 'libjpeg.a' to 'libjpeg.o' andchange these definitions as indicated:CFLAGS= -throwback -IC: -WnLDLIBS=C:o.StubsSYSDEPMEM=jmemansi.oLN=LinkAR=LibFile -c -oAlso add a new line '.c.o:; $(cc) $< $(cflags) -c -o $@'.  Remove thelines '$(RM) libjpeg.o' and '$(AR2) libjpeg.o' and the 'jconfig.h'dependency section.Copy jconfig.doc to jconfig.h.  Edit jconfig.h to define TWO_FILE_COMMANDLINEand CHAR_IS_UNSIGNED.Run the makefile using !AMU not !Make.  If you want to use the 'clean' and'test' makefile entries then you will have to fiddle with the syntax a bitand rename the test files.Amiga:SAS C 6.50 reportedly is too buggy to compile the IJG code properly.A patch to update to 6.51 is available from SAS or AmiNet FTP sites.The supplied config files are set up to use jmemname.c as the memorymanager, with temporary files being created on the device named by"JPEGTMP:".Atari ST/STE/TT: Copy the project files makcjpeg.st, makdjpeg.st, maktjpeg.st, and makljpeg.stto cjpeg.prj, djpeg.prj, jpegtran.prj, and libjpeg.prj respectively.  Theproject files should work as-is with Pure C.  For Turbo C, change libraryfilenames "pc..." to "tc..." in each project file.  Note that libjpeg.prjselects jmemansi.c as the recommended memory manager.  You'll probably want toadjust the DEFAULT_MAX_MEM setting --- you want it to be a couple hundred Kless than your normal free memory.  Put "#define DEFAULT_MAX_MEM nnnn" intojconfig.h to do this.To use the 68881/68882 coprocessor for the floating point DCT, add thecompiler option "-8" to the project files and replace pcfltlib.lib withpc881lib.lib in cjpeg.prj and djpeg.prj.  Or if you don't have acoprocessor, you may prefer to remove the float DCT code by undefiningDCT_FLOAT_SUPPORTED in jmorecfg.h (since without a coprocessor, the floatcode will be too slow to be useful).  In that case, you can deletepcfltlib.lib from the project files.Note that you must make libjpeg.lib before making cjpeg.ttp, djpeg.ttp,or jpegtran.ttp.  You'll have to perform the self-test by hand.We haven't bothered to include project files for rdjpgcom and wrjpgcom.Those source files should just be compiled by themselves; they don'tdepend on the JPEG library.There is a bug in some older versions of the Turbo C library which causes thespace used by temporary files created with "tmpfile()" not to be freed afteran abnormal program exit.  If you check your disk afterwards, you will findcluster chains that are allocated but not used by a file.  This should nothappen in cjpeg/djpeg/jpegtran, since we enable a signal catcher to explicitlyclose temp files before exiting.  But if you use the JPEG library with yourown code, be sure to supply a signal catcher, or else use a differentsystem-dependent memory manager.Cray:Should you be so fortunate as to be running JPEG on a Cray YMP, there is acompiler bug in old versions of Cray's Standard C (prior to 3.1).  If youstill have an old compiler, you'll need to insert a line reading"#pragma novector" just before the loop	    for (i = 1; i <= (int) htbl->bits[l]; i++)      huffsize[p++] = (char) l;in fix_huff_tbl (in V5beta1, line 204 of jchuff.c and line 176 of jdhuff.c).[This bug may or may not still occur with the current IJG code, but it'sprobably a dead issue anyway...]HP-UX:If you have HP-UX 7.05 or later with the "software development" C compiler,you should run the compiler in ANSI mode.  If using the configure script,say	./configure CC='cc -Aa'(or -Ae if you prefer).  If configuring by hand, use makefile.ansi and add"-Aa" to the CFLAGS line in the makefile.If you have a pre-7.05 system, or if you are using the non-ANSI C compilerdelivered with a minimum HP-UX system, then you must use makefile.unix(and do NOT add -Aa); or just run configure without the CC option.On HP 9000 series 800 machines, the HP C compiler is buggy in revisions priorto A.08.07.  If you get complaints about "not a typedef name", you'll have touse makefile.unix, or run configure without the CC option.Macintosh, generic comments:The supplied user-interface files (cjpeg.c, djpeg.c, etc) are set up toprovide a Unix-style command line interface.  You can use this interface onthe Mac by means of the ccommand() library routine provided by MetrowerksCodeWarrior or Think C.  This is only appropriate for testing the library,however; to make a user-friendly equivalent of cjpeg/djpeg you'd really wantto develop a Mac-style user interface.  There isn't a complete exampleavailable at the moment, but there are some helpful starting points:1. Sam Bushell's free "To JPEG" applet provides drag-and-drop conversion toJPEG under System 7 and later.  This only illustrates how to use thecompression half of the library, but it does a very nice job of that part.The CodeWarrior source code is available from http://www.pobox.com/~jsam.2. Jim Brunner prepared a Mac-style user interface for both compression anddecompression.  Unfortunately, it hasn't been updated since IJG v4, andthe library's API has changed considerably since then.  Still it may be ofsome help, particularly as a guide to compiling the IJG code under Think C.Jim's code is available from the Info-Mac archives, at sumex-aim.stanford.eduor mirrors thereof; see file /info-mac/dev/src/jpeg-convert-c.hqx.jmemmac.c is the recommended memory manager back end for Macintosh.  It usesNewPtr/DisposePtr instead of malloc/free, and has a Mac-specificimplementation of jpeg_mem_available().  It also creates temporary files thatfollow Mac conventions.  (That part of the code relies on System-7-or-later OSfunctions.  See the comments in jmemmac.c if you need to run it on System 6.)NOTE that USE_MAC_MEMMGR must be defined in jconfig.h to use jmemmac.c.You can also use jmemnobs.c, if you don't care about handling images largerthan available memory.  If you use any memory manager back end other thanjmemmac.c, we recommend replacing "malloc" and "free" by "NewPtr" and"DisposePtr", because Mac C libraries often have peculiar implementations ofmalloc/free.  (For instance, free() may not return the freed space to theMac Memory Manager.  This is undesirable for the IJG code because jmemmgr.calready clumps space requests.)Macintosh, Metrowerks CodeWarrior:The Unix-command-line-style interface can be used by defining USE_CCOMMAND.You'll also need to define TWO_FILE_COMMANDLINE to avoid stdin/stdout.This means that when using the cjpeg/djpeg programs, you'll have to type theinput and output file names in the "Arguments" text-edit box, rather thanusing the file radio buttons.  (Perhaps USE_FDOPEN or USE_SETMODE wouldeliminate the problem, but I haven't heard from anyone who's tried it.)On 680x0 Macs, Metrowerks defines type "double" as a 10-byte IEEE extendedfloat.  jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a powerof 2.  Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.The supplied configuration file jconfig.mac can be used for your jconfig.h;it includes all the recommended symbol definitions.  If you have AppleScriptinstalled, you can run the supplied script makeproj.mac to create CodeWarriorproject files for the library and the testbed applications, then build thelibrary and applications.  (Thanks to Dan Sears and Don Agro for this niftyhack, which saves us from trying to maintain CodeWarrior project files as partof the IJG distribution...)Macintosh, Think C:The documentation in Jim Brunner's "JPEG Convert" source code (see above)includes detailed build instructions for Think C; it's probably somewhatout of date for the current release, but may be helpful.If you want to build the minimal command line version, proceed as follows.You'll have to prepare project files for the programs; we don't include anyin the distribution since they are not text files.  Use the file lists inany of the supplied makefiles as a guide.  Also add the ANSI and Unix Clibraries in a separate segment.  You may need to divide the JPEG files intomore than one segment; we recommend dividing compression and decompressionmodules.  Define USE_CCOMMAND in jconfig.h so that the ccommand() routine iscalled.  You must also define TWO_FILE_COMMANDLINE because stdin/stdoutdon't handle binary data correctly.On 680x0 Macs, Think C defines type "double" as a 12-byte IEEE extended float.jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power of 2.Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.jconfig.mac should work as a jconfig.h configuration file for Think C,but the makeproj.mac AppleScript script is specific to CodeWarrior.  Sorry.MIPS R3000:MIPS's cc version 1.31 has a rather nasty optimization bug.  Don't use -Oif you have that compiler version.  (Use "cc -V" to check the version.)Note that the R3000 chip is found in workstations from DEC and others.MS-DOS, generic comments for 16-bit compilers:The IJG code is designed to work well in 80x86 "small" or "medium" memorymodels (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 tocompile cjpeg or djpeg by itself, but you will probably have to use mediummodel for any larger application.  This won't make much difference inperformance.  You *will* take a noticeable performance hit if you use alarge-data memory model, and you should avoid "huge" model if at allpossible.  Be sure that NEED_FAR_POINTERS is defined in jconfig.h if you usea small-data memory model; be sure it is NOT defined if you use a large-datamodel.  (The supplied makefiles and jconfig files for Borland and Microsoft Ccompile in medium model and define NEED_FAR_POINTERS.)The DOS-specific memory manager, jmemdos.c, should be used if possible.It needs some assembly-code routines which are in jmemdosa.asm; make sureyour makefile assembles that file and includes it in the library.  If youdon't have a suitable assembler, you can get pre-assembled object files forjmemdosa by FTP from ftp.uu.net:/graphics/jpeg/jdosaobj.zip.  (DOS-orienteddistributions of the IJG source code often include these object files.)When using jmemdos.c, jconfig.h must define USE_MSDOS_MEMMGR and must setMAX_ALLOC_CHUNK to less than 64K (65520L is a typical value).  If yourC library's far-heap malloc() can't allocate blocks that large, reduceMAX_ALLOC_CHUNK to whatever it can handle.If you can't use jmemdos.c for some reason --- for example, because youdon't have an assembler to assemble jmemdosa.asm --- you'll have to fallback to jmemansi.c or jmemname.c.  You'll probably still need to setMAX_ALLOC_CHUNK in jconfig.h, because most DOS C libraries won't malloc()more than 64K at a time.  IMPORTANT: if you use jmemansi.c or jmemname.c,you will have to compile in a large-data memory model in order to get theright stdio library.  Too bad.wrjpgcom needs to be compiled in large model, because it malloc()s a 64KBwork area to hold the comment text.  If your C library's malloc can'thandle that, reduce MAX_COM_LENGTH as necessary in wrjpgcom.c.Most MS-DOS compilers treat stdin/stdout as text files, so you must usetwo-file command line style.  But if your compiler has either fdopen() orsetmode(), you can use one-file style if you like.  To do this, defineUSE_SETMODE or USE_FDOPEN so that stdin/stdout will be set to binary mode.(USE_SETMODE seems to work with more DOS compilers than USE_FDOPEN.)  Youshould test that I/O through stdin/stdout produces the same results as I/Oto explicitly named files... the "make test" procedures in the suppliedmakefiles do NOT use stdin/stdout.MS-DOS, generic comments for 32-bit compilers:None of the above comments about memory models apply if you are using a32-bit flat-memory-space environment, such as DJGPP or Watcom C.  (And youshould use one if you have it, as performance will be much better than8086-compatible code!)  For flat-memory-space compilers, do NOT define