XeNTaX

I'm trying to fix the slowness.
when the slowness will be solved the memory allocation problem will be removed (or at least super-reduced) too.

the good news is that I have fixed the script, it was caused by the usage of SIZE instead of ZSIZE.
this problem has probably caused also some damaged files (files bigger than requested).
so now the script 0.4 is ok.

the bad news is that there is also a bug in quickbms that wastes memory and I'm going to fix it immediately.
in the meantime you can use an older version like the following:
http://aluigi.org/papers/quickbms_0.5.4.zip

let me know if now it's all ok.

aluigi wrote:the good news is that I have fixed the script, it was caused by the usage of SIZE instead of ZSIZE.

yay! thanks!

aluigi wrote:this problem has probably caused also some damaged files (files bigger than requested).

Yes, I've noticed this because the XMA streams weren't parsable correctly and had the start of the next track at the end.

aluigi wrote:the bad news is that there is also a bug in quickbms that wastes memory and I'm going to fix it immediately.
in the meantime you can use an older version like the following:
http://aluigi.org/papers/quickbms_0.5.4.zip

Ok, this one seem to work perfectly. I'll get back to you as soon as I've checked the files.
Thanks so far!

Checked it - looks really good! Thanks a lot for this!

I have released a new version of quickbms that allows you to disable the secure allocation functions using the option -9.
obviously you don't need to use it from the command-line, just create a link to quickbms.exe and add the -9 option in the Target field of the link's properties.

the problem is that there are physical and math limitations in using a secure allocation function because:

• VirtualAlloc is NOT malloc and so it doesn't manage the memory correctly, in short if it finds space it allocates otherwise bye bye (malloc instead moves the memory). and no, I can't use malloc with PAGE_GUARDs. the only way to limit this limitation is using linked lists for reusing old freed buffers
• malloc(1) allocates 16kb... yeah I know it's a lot but take a look at some math:
  a memory page is usually 4kb
  we need a page for the linked list informations, one before the buffer (buffer underflow protection), one after it (buffer overflow) and the buffer aligned to the page size.
  only the informations about the linked lists are not much necessary and I could find alternative solutions to them but after all 12kb instead of 16kb doesn't change much
• the linked lists (the index) are slow to handle if there are too many entries

ah right, the good news is that fear.bms is probably one of the very rare scripts that have performance problems with the secure allocation feature so don't worry.