Short: Alloc32P - AllocMem/AllocVec patch V2.0 Author: Andreas_Kleinert@t-online.de Uploader: Andreas_Kleinert t-online de Type: util/sys Architecture: m68k-amigaos This patch does a few things: o Sometimes programs fail with a "not enough memory" error, but after calling "avail flush" the same operation does succeed without problems. Obviously AllocMem/AllocVec does not force such a "flush" operation AND tries to allocate memory again, immediately after the flushing has been done. Why ? Why has the program to assume, that its allocation did fail, although there may has been some memory released by the flush ? This patch does ensure, that AllocMem/AllocVec won't fail unless there's really no memory available, even by flushing. This means: - less "out of memory" failures - less "bad behaviour" of bad programs, which don't check results of AllocMem/AllocVec - no more need to call "avail flush" by hand from the shell - thus no more "retry" operations after "avail flush" - no more unused libraries/devices consuming memory when it is already low o (new) AllocMem() and AllocVec() calls are changed into new-style memory allocation calls o 32 Byte alignment for new-style memory allocated buffers o new-style memory allocation does work as follows: each memory request will be extended by space for certain administration data, which fulfils several tasks: - it does contain some information on the allocation, such as buffer size and various pointers - imitating an AllocVec allocation - aligning the actually used buffer pointer to the next 32 byte boundary (Exec aligns to 8 byte boundaries, so we add another 24 bytes) Additionally, this alignment also takes place at the end of the buffer, where upto 31 bytes may be added, to align it to the next 32 byte boundary. So, each memory allocation will at least be 64 bytes wide. o delocating a new style buffer works by taking the information from the extended space (from within the extra 24 bytes), which does work quite similar to a common AlloVec call, where the buffer size is stored before the buffer, too. But with Alloc32P, this is possible with usual AllocMem() calls as well. The "size" parameter of a FreeMem(ptr, size) call will be ignored - or optionally just be used for safety comparisons. o basically it does not matter, at which point you start the patch, since it will recognize, when any program does try to delocate buffers that had been allocated before the patch had been running. It then will delocate these the old way. But it does make sense, to TEST it fromout the Shell first, and THEN add it to s:startup-sequence or s:user-startup Note: Needs V37+ and 68020. Note: DO NOT RUN MUNGWALL IN PARALLEL - IT WILL NOT RECOGNIZE THE PATCH AND MAY PRODUCE ENDLESS MUNGWALL HITS ! (Additionally, this does not make sense anyway, since the patch may falsify the results out of testing buggy programs - it may compensate some of these bugs actually ;) Usage: Try starting in the Shell/CLI. If it does run stable, copy it into your C: directory and add it somewhere into your s:user-startup AllocP >NIL: