jmemdos.pas

DELPHI版的JPEG文件解码源程序

Unit JmemDos;


{ This file provides an MS-DOS-compatible implementation of the system-
  dependent portion of the JPEG memory manager.  Temporary data can be
  stored in extended or expanded memory as well as in regular DOS files.

  If you use this file, you must be sure that NEED_FAR_POINTERS is defined
  if you compile in a small-data memory model; it should NOT be defined if
  you use a large-data memory model.  This file is not recommended if you
  are using a flat-memory-space 386 environment such as DJGCC or Watcom C.
  Also, this code will NOT work if struct fields are aligned on greater than
  2-byte boundaries.

  Based on code contributed by Ge' Weijers. }

{ Original: jmemdos.c;  Copyright (C) 1992-1996, Thomas G. Lane. }


interface

{$I jconfig.inc}

uses
  jmorecfg,
  jpeglib;

{ If you have both extended and expanded memory, you may want to change the
  order in which they are tried in jopen_backing_store.  On a 286 machine
  expanded memory is usually faster, since extended memory access involves
  an expensive protected-mode-and-back switch.  On 386 and better, extended
  memory is usually faster.  As distributed, the code tries extended memory
  first (what? not everyone has a 386? :-).

  You can disable use of extended/expanded memory entirely by altering these
  definitions or overriding them from the Makefile (eg, -DEMS_SUPPORTED=0).}

{GLOBAL}
procedure jpeg_open_backing_store (cinfo : j_common_ptr;
                                   info : backing_store_ptr;
                                   total_bytes_needed : long);

{ These routines take care of any system-dependent initialization and
  cleanup required. }

{GLOBAL}
function jpeg_mem_init (cinfo : j_common_ptr) : long;

{GLOBAL}
procedure jpeg_mem_term (cinfo : j_common_ptr);

{ These two functions are used to allocate and release small chunks of
  memory.  (Typically the total amount requested through jpeg_get_small is
  no more than 20K or so; this will be requested in chunks of a few K each.)
  Behavior should be the same as for the standard library functions malloc
  and free; in particular, jpeg_get_small must return NIL on failure.
  On most systems, these ARE malloc and free.  jpeg_free_small is passed the
  size of the object being freed, just in case it's needed.
  On an 80x86 machine using small-data memory model, these manage near heap. }


{ Near-memory allocation and freeing are controlled by the regular library
  routines malloc() and free(). }

{GLOBAL}
function jpeg_get_small (cinfo : j_common_ptr;
                         sizeofobject : size_t) : pointer;

{GLOBAL}
{object is a reserved word in Borland Pascal }
procedure jpeg_free_small (cinfo : j_common_ptr;
                           an_object : pointer;
                           sizeofobject : size_t);

{ These two functions are used to allocate and release large chunks of
  memory (up to the total free space designated by jpeg_mem_available).
  The interface is the same as above, except that on an 80x86 machine,
  far pointers are used.  On most other machines these are identical to
  the jpeg_get/free_small routines; but we keep them separate anyway,
  in case a different allocation strategy is desirable for large chunks. }


{ "Large" objects are allocated in far memory, if possible }


{GLOBAL}
function jpeg_get_large (cinfo : j_common_ptr;
                         sizeofobject : size_t) : voidp; {far}

{GLOBAL}
procedure jpeg_free_large (cinfo : j_common_ptr;
                          {var?} an_object : voidp; {FAR}
                          sizeofobject : size_t);

{ This routine computes the total memory space available for allocation.
  It's impossible to do this in a portable way; our current solution is
  to make the user tell us (with a default value set at compile time).
  If you can actually get the available space, it's a good idea to subtract
  a slop factor of 5% or so. }

{GLOBAL}
function jpeg_mem_available (cinfo : j_common_ptr;
                             min_bytes_needed : long;
		             max_bytes_needed : long;
                             already_allocated : long) : long;


{ The macro MAX_ALLOC_CHUNK designates the maximum number of bytes that may
  be requested in a single call to jpeg_get_large (and jpeg_get_small for that
  matter, but that case should never come into play).  This macro is needed
  to model the 64Kb-segment-size limit of far addressing on 80x86 machines.
  On those machines, we expect that jconfig.h will provide a proper value.
  On machines with 32-bit flat address spaces, any large constant may be used.

  NB: jmemmgr.c expects that MAX_ALLOC_CHUNK will be representable as type
  size_t and will be a multiple of sizeof(align_type). }


{$ifdef USE_MSDOS_MEMMGR}            { Define this if you use jmemdos.c }
const
  MAX_ALLOC_CHUNK = long(32752); {65520}  { Maximum request to malloc() }
                             { MAX_ALLOC_CHUNK should be less than 64K. }
{$else}
const
  MAX_ALLOC_CHUNK = long(1000000000);
{$endif}

implementation

uses
  dos,
  jmemdosa,
  jdeferr,
  jerror;



{ Selection of a file name for a temporary file.
  This is highly system-dependent, and you may want to customize it. }

var
  next_file_num : int;          { to distinguish among several temp files }

{LOCAL}
procedure select_file_name (var fname : TEMP_STRING);
var
  env : string;
  suffix,
  prefix : TEMP_STRING;
  tfile : FILE;
  l : byte;
begin
  { Keep generating file names till we find one that's not in use }
  while TRUE do
  begin
     { Get temp directory name from environment TMP or TEMP variable;
      if none, use "." }
    env := getenv('TMP');
    if (env = '') then
    begin
      env := getenv('TEMP');
      if (env = '') then         { null string means "." }
        env := '.';
    end;
    prefix := env;                { copy name to fname }
    { length(fname) > 0 !! }
    if (prefix[length(prefix)] <> '\')
    and (prefix[length(prefix)] <> '/') then
      prefix := prefix + '\';     { append backslash if not in env variable }
    { Append a suitable file name }
    Inc(next_file_num);         { advance counter }

    Str(next_file_num, suffix);
    for l := Length(suffix)+1 to 3 do
      suffix := '0' + suffix;
    fname := prefix + 'JPG' + suffix + '.TMP';
    { Probe to see if file name is already in use }
    system.assign(tfile, fname);
    {$ifdef IoCheck} {$I-} {$endif}
    system.reset(tfile, 1);
    {$ifdef IoCheck} {$I+} {$endif}
    if (IOresult <> 0) then
    begin
      fname := fname + #0;
      break;
    end;
    system.close(tfile);        { oops, it's there; close tfile & try again }
  end;
end;

{ These two functions are used to allocate and release small chunks of
  memory.  (Typically the total amount requested through jpeg_get_small is
  no more than 20K or so; this will be requested in chunks of a few K each.)
  Behavior should be the same as for the standard library functions malloc
  and free; in particular, jpeg_get_small must return NIL on failure.
  On most systems, these ARE malloc and free.  jpeg_free_small is passed the
  size of the object being freed, just in case it's needed.
  On an 80x86 machine using small-data memory model, these manage near heap. }


{ Near-memory allocation and freeing are controlled by the regular library
  routines malloc() and free(). }

{GLOBAL}
function jpeg_get_small (cinfo : j_common_ptr;
                         sizeofobject : size_t) : pointer;
var
  p : pointer;
begin
  getmem(p, sizeofobject);
  jpeg_get_small := p;
end;

{GLOBAL}
{object is a reserved word in Borland Pascal }
procedure jpeg_free_small (cinfo : j_common_ptr;
                           an_object : pointer;
                           sizeofobject : size_t);
begin
  freemem(an_object, sizeofobject);
end;

{ These two functions are used to allocate and release large chunks of
  memory (up to the total free space designated by jpeg_mem_available).
  The interface is the same as above, except that on an 80x86 machine,
  far pointers are used.  On most other machines these are identical to
  the jpeg_get/free_small routines; but we keep them separate anyway,
  in case a different allocation strategy is desirable for large chunks. }


{GLOBAL}
function jpeg_get_large (cinfo : j_common_ptr;
                         sizeofobject : size_t) : voidp; {far}
var
  p : voidp; {FAR}
begin
  {far_malloc;}
  getmem(p, sizeofobject);
  jpeg_get_large := p;
end;

{GLOBAL}
procedure jpeg_free_large (cinfo : j_common_ptr;
                          {var?} an_object : voidp; {FAR}
                          sizeofobject : size_t);
begin
  {far_free(an_object);}
  FreeMem(an_object, sizeofobject);
end;

{ This routine computes the total space still available for allocation by
  jpeg_get_large.  If more space than this is needed, backing store will be
  used.  NOTE: any memory already allocated must not be counted.

  There is a minimum space requirement, corresponding to the minimum
  feasible buffer sizes; jmemmgr.c will request that much space even if
  jpeg_mem_available returns zero.  The maximum space needed, enough to hold
  all working storage in memory, is also passed in case it is useful.
  Finally, the total space already allocated is passed.  If no better
  method is available, cinfo->mem->max_memory_to_use - already_allocated
  is often a suitable calculation.

  It is OK for jpeg_mem_available to underestimate the space available
  (that'll just lead to more backing-store access than is really necessary).
  However, an overestimate will lead to failure.  Hence it's wise to subtract
  a slop factor from the true available space.  5% should be enough.

  On machines with lots of virtual memory, any large constant may be returned.
  Conversely, zero may be returned to always use the minimum amount of memory.}



{ This routine computes the total memory space available for allocation.
  It's impossible to do this in a portable way; our current solution is
  to make the user tell us (with a default value set at compile time).
  If you can actually get the available space, it's a good idea to subtract
  a slop factor of 5% or so. }

const
  DEFAULT_MAX_MEM = long(300000);   { for total usage about 450K }

{GLOBAL}
function jpeg_mem_available (cinfo : j_common_ptr;
                             min_bytes_needed : long;
		             max_bytes_needed : long;
                             already_allocated : long) : long;
begin
  {jpeg_mem_available := cinfo^.mem^.max_memory_to_use - already_allocated;}
  jpeg_mem_available := MaxAvail*95 div 100;  { 95% }

  { Nomssi: limit the available memory for test purpose }
  {jpeg_mem_available := 30000;}
end;


{ Backing store (temporary file) management.
  Backing store objects are only used when the value returned by
  jpeg_mem_available is less than the total space needed.  You can dispense
  with these routines if you have plenty of virtual memory; see jmemnobs.c. }


{ For MS-DOS we support three types of backing storage:
    1. Conventional DOS files.  We access these by direct DOS calls rather
       than via the stdio package.  This provides a bit better performance,
       but the real reason is that the buffers to be read or written are FAR.
       The stdio library for small-data memory models can't cope with that.
    2. Extended memory, accessed per the XMS V2.0 specification.
    3. Expanded memory, accessed per the LIM/EMS 4.0 specification.
  You'll need copies of those specs to make sense of the related code.
  The specs are available by Internet FTP from the SIMTEL archives
  (oak.oakland.edu and its various mirror sites).  See files
  pub/msdos/microsoft/xms20.arc and pub/msdos/info/limems41.zip. }



{ Access methods for a DOS file. }


{METHODDEF}
procedure read_file_store (cinfo : j_common_ptr;
                           info : backing_store_ptr;
                           buffer_address : pointer; {FAR}
                           file_offset : long;
                           byte_count : long); far;
begin
  if jdos_seek(info^.handle.file_handle, file_offset) <> 0 then
    ERREXIT(cinfo, JERR_TFILE_SEEK);
  { Since MAX_ALLOC_CHUNK is less than 64K, byte_count will be too. }
  if (byte_count > long(65535))	then { safety check }
    ERREXIT(cinfo, JERR_BAD_ALLOC_CHUNK);
  if jdos_read(info^.handle.file_handle, buffer_address,
		ushort(byte_count)) <> 0 then
    ERREXIT(cinfo, JERR_TFILE_READ);
end;


{METHODDEF}
procedure write_file_store (cinfo : j_common_ptr;
                            info : backing_store_ptr;
		            buffer_address : pointer; {FAR}
		            file_offset : long;
                            byte_count : long); far;
begin
  if (jdos_seek(info^.handle.file_handle, file_offset)) <> 0 then
    ERREXIT(cinfo, JERR_TFILE_SEEK);
  { Since MAX_ALLOC_CHUNK is less than 64K, byte_count will be too. }
  if (byte_count > long(65535)) then  { safety check }
    ERREXIT(cinfo, JERR_BAD_ALLOC_CHUNK);
  if jdos_write(info^.handle.file_handle, buffer_address,
		 ushort(byte_count)) <> 0 then
    ERREXIT(cinfo, JERR_TFILE_WRITE);
end;


{METHODDEF}
procedure close_file_store (cinfo : j_common_ptr;
                            info : backing_store_ptr); far;
var
  f : FILE;
begin
  jdos_close(info^.handle.file_handle);	{ close the file }
  	        
  system.assign(f, info^.temp_name);
  system.erase(f);                      { delete the file }
{ If your system doesn't have remove(), try unlink() instead.
  remove() is the ANSI-standard name for this function, but
  unlink() was more common in pre-ANSI systems. }

  TRACEMSS(cinfo, 1, JTRC_TFILE_CLOSE, info^.temp_name);
end;


{LOCAL}
function open_file_store (cinfo : j_common_ptr;
                          info : backing_store_ptr;
                          total_bytes_needed : long): boolean;  far;
var
  handle : short;
begin
  select_file_name(info^.temp_name);
  if jdos_open(handle, info^.temp_name[1]) <> 0 then
  begin
    { might as well exit since jpeg_open_backing_store will fail anyway }
    ERREXITS(cinfo, JERR_TFILE_CREATE, info^.temp_name);
    open_file_store := FALSE;
    exit;
  end;
  info^.handle.file_handle := handle;
  info^.read_backing_store := read_file_store;
  info^.write_backing_store := write_file_store;