jmemsys.pas 7.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177
  1. Unit jmemsys;
  2. { This is a skeleton you need to create a working system-dependent
  3. JPEG memory manager.
  4. No other modules need include it. (The system-independent portion is
  5. jmemmgr.c; there are several different versions of the system-dependent
  6. portion.)
  7. This code will not compile - Check JMEMDOS.PAS for an example }
  8. { Original: jmemsys.h; Copyright (C) 1992-1996, Thomas G. Lane. }
  9. interface
  10. uses
  11. jmorecfg,
  12. jpeglib;
  13. { The macro MAX_ALLOC_CHUNK designates the maximum number of bytes that may
  14. be requested in a single call to jpeg_get_large (and jpeg_get_small for that
  15. matter, but that case should never come into play). This macro is needed
  16. to model the 64Kb-segment-size limit of far addressing on 80x86 machines.
  17. On those machines, we expect that jconfig.h will provide a proper value.
  18. On machines with 32-bit flat address spaces, any large constant may be used.
  19. NB: jmemmgr.c expects that MAX_ALLOC_CHUNK will be representable as type
  20. size_t and will be a multiple of sizeof(align_type). }
  21. {$ifdef USE_MSDOS_MEMMGR} { Define this if you use jmemdos.c }
  22. const
  23. MAX_ALLOC_CHUNK = long(65520); { Maximum request to malloc() }
  24. {$else}
  25. const
  26. MAX_ALLOC_CHUNK = long(1000000000);
  27. {$endif}
  28. { Initial opening of a backing-store object. This must fill in the
  29. read/write/close pointers in the object. The read/write routines
  30. may take an error exit if the specified maximum file size is exceeded.
  31. (If jpeg_mem_available always returns a large value, this routine can
  32. just take an error exit.) }
  33. EXTERN procedure jpeg_open_backing_store (cinfo : j_common_ptr;
  34. info : backing_store_ptr;
  35. total_bytes_needed : long);
  36. { These routines take care of any system-dependent initialization and
  37. cleanup required. jpeg_mem_init will be called before anything is
  38. allocated (and, therefore, nothing in cinfo is of use except the error
  39. manager pointer). It should return a suitable default value for
  40. max_memory_to_use; this may subsequently be overridden by the surrounding
  41. application. (Note that max_memory_to_use is only important if
  42. jpeg_mem_available chooses to consult it ... no one else will.)
  43. jpeg_mem_term may assume that all requested memory has been freed and that
  44. all opened backing-store objects have been closed. }
  45. EXTERN function jpeg_mem_init (cinfo : j_common_ptr) : long;
  46. EXTERN procedure jpeg_mem_term (cinfo : j_common_ptr);
  47. implementation
  48. { This structure holds whatever state is needed to access a single
  49. backing-store object. The read/write/close method pointers are called
  50. by jmemmgr.c to manipulate the backing-store object; all other fields
  51. are private to the system-dependent backing store routines. }
  52. const
  53. TEMP_NAME_LENGTH = 64; { max length of a temporary file's name }
  54. {$ifdef USE_MSDOS_MEMMGR} { DOS-specific junk }
  55. type
  56. XMSH = ushort; { type of extended-memory handles }
  57. EMSH = ushort; { type of expanded-memory handles }
  58. handle_union = record
  59. case byte of
  60. 0:(file_handle : short); { DOS file handle if it's a temp file }
  61. 1:(xms_handle : XMSH); { handle if it's a chunk of XMS }
  62. 2:(ems_handle : EMSH); { handle if it's a chunk of EMS }
  63. end;
  64. {$endif - USE_MSDOS_MEMMGR }
  65. type
  66. backing_store_ptr = ^backing_store_info;
  67. backing_store_info = record
  68. { Methods for reading/writing/closing this backing-store object }
  69. read_backing_store : procedure (cinfo : j_common_ptr;
  70. info : backing_store_ptr;
  71. buffer_address : pointer; {far}
  72. file_offset : long;
  73. byte_count : long);
  74. write_backing_store : procedure (cinfo : j_common_ptr;
  75. info : backing_store_ptr;
  76. buffer_address : pointer; {far}
  77. file_offset : long;
  78. byte_count : long);
  79. close_backing_store : procedure (cinfo : j_common_ptr;
  80. info : backing_store_ptr);
  81. { Private fields for system-dependent backing-store management }
  82. {$ifdef USE_MSDOS_MEMMGR}
  83. { For the MS-DOS manager (jmemdos.c), we need: }
  84. handle : handle_union; { reference to backing-store storage object }
  85. temp_name : string[TEMP_NAME_LENGTH]; { name if it's a file }
  86. {$else}
  87. { For a typical implementation with temp files, we need: }
  88. temp_file : FILE; { stdio reference to temp file }
  89. temp_name : string[TEMP_NAME_LENGTH]; { name of temp file }
  90. {$endif}
  91. end;
  92. { These two functions are used to allocate and release small chunks of
  93. memory. (Typically the total amount requested through jpeg_get_small is
  94. no more than 20K or so; this will be requested in chunks of a few K each.)
  95. Behavior should be the same as for the standard library functions malloc
  96. and free; in particular, jpeg_get_small must return NIL on failure.
  97. On most systems, these ARE malloc and free. jpeg_free_small is passed the
  98. size of the object being freed, just in case it's needed.
  99. On an 80x86 machine using small-data memory model, these manage near heap. }
  100. EXTERN function jpeg_get_small (cinfo : j_common_ptr;
  101. sizeofobject : size_t) : pointer;
  102. EXTERN procedure jpeg_free_small (cinfo : j_common_ptr;
  103. object : pointer;
  104. sizeofobject : size_t);
  105. { These two functions are used to allocate and release large chunks of
  106. memory (up to the total free space designated by jpeg_mem_available).
  107. The interface is the same as above, except that on an 80x86 machine,
  108. far pointers are used. On most other machines these are identical to
  109. the jpeg_get/free_small routines; but we keep them separate anyway,
  110. in case a different allocation strategy is desirable for large chunks. }
  111. EXTERN function jpeg_get_large (cinfo : j_common_ptr cinfo;
  112. sizeofobject : size_t) : pointer; {far}
  113. EXTERN procedure jpeg_free_large (cinfo : j_common_ptr;
  114. object : pointer; {far}
  115. sizeofobject : size_t);
  116. { This routine computes the total space still available for allocation by
  117. jpeg_get_large. If more space than this is needed, backing store will be
  118. used. NOTE: any memory already allocated must not be counted.
  119. There is a minimum space requirement, corresponding to the minimum
  120. feasible buffer sizes; jmemmgr.c will request that much space even if
  121. jpeg_mem_available returns zero. The maximum space needed, enough to hold
  122. all working storage in memory, is also passed in case it is useful.
  123. Finally, the total space already allocated is passed. If no better
  124. method is available, cinfo->mem->max_memory_to_use - already_allocated
  125. is often a suitable calculation.
  126. It is OK for jpeg_mem_available to underestimate the space available
  127. (that'll just lead to more backing-store access than is really necessary).
  128. However, an overestimate will lead to failure. Hence it's wise to subtract
  129. a slop factor from the true available space. 5% should be enough.
  130. On machines with lots of virtual memory, any large constant may be returned.
  131. Conversely, zero may be returned to always use the minimum amount of memory.}
  132. EXTERN function jpeg_mem_available (cinfo : j_common_ptr;
  133. min_bytes_needed : long;
  134. max_bytes_needed : long;
  135. already_allocated : long) : long;
  136. end.