You need to find the exact call to a Global/Local/HeapFree (or whatever free routine is being used) that causes the crash. Ie, the source line in either your app or ernie's imagelib that does such a call. Once you've found that line, it will hopefully be possible to trace backwards through the code and see what's going on.
Posted on 2004-03-09 07:51:33 by f0dder
I've got it!

If i comment off these lines of code in BitmapFromMemory, my program will work.

; release the stream
mov eax, pStream
push eax
mov eax,
call .IPicture.Release

; release the Picture object
mov eax, pPicture
push eax
mov eax,
call .IPicture.Release

Somehow, the Release of the IPicture streams and objects caused the crashes.

I wonder would there be any side effects?
Posted on 2004-03-09 10:03:52 by trexxz
I took a look at ernie's ImageLib routines from masm32v8, and
two things made me raise my brow. First, he uses CoTaskMemAlloc
instead of GlobalAlloc. GlobalAlloc still uses HeapAlloc (which
uses NtAllocateHeap) internally as most other allocation rotuines,
but Global/LocalAlloc does some additional bookkeeping (includes
an 8-byte structure before the allocated memory) + adds some
undocumented flags to the HeapAlloc call. I haven't bothered
looking at CoTaskMemAlloc, but PlatformSDK says to use GlobalAlloc,
so I would recommend doing that.

Second, he frees the CoTaskMemAlloc'ed memory before returning.
This is pretty bad, since he specified TRUE for fDeleteOnRelease
when calling CreateStreamOnHGlobal, meaning it's the responsibility
of the IStream to dealloc the memory when the Release method is called.

You ought to adapt his routines for your own use... this bug is
a bad thing, and the routines do CoInitialize + CoUninitalize
every time they're caled; wasteful, better to do this in your
own app at startup & shutdown.
Posted on 2004-03-09 10:21:02 by f0dder

I don't use bitmap from memory but I do use IPicture and have never had any problems reported with it. You must release the stream and the interface. Try this project, it is a test platform I use for some IPicture stuff. See if it GPFs :
Posted on 2004-03-09 10:21:34 by donkey
You seem to be doing double-free as well, donkey.
Posted on 2004-03-09 10:26:53 by f0dder

You seem to be doing double-free as well, donkey.

Yeah, that's why I was wondering if it would GPF, it is embedded in alot of my code that way and though I normally don't support NT4, it will be useful to know whether it causes problems. I haven't ever gotten a report that it has even in TBPaint which uses the routine. I am currently rewriting TBPaint in GoAsm and will take care of the oversight but I am interested to know. I just don't have NT4 to test with nor am I particularly interested in getting it as I see it as a pretty much dead end OS.
Posted on 2004-03-09 10:35:11 by donkey
The thing with stuff like double-free is that it might only give problems sometimes. Some combinations of alloc/dealloc routines used, the order of calls Posted on 2004-03-09 10:39:15 by f0dder
Actually looking over my other code I don't free the heap, it seems only to be in my test bed. I must have been trying something a while back and didn't remove the line. TBPaint does not have the problem nor does any of my other software, just one demo that was done after the test apparently.
Posted on 2004-03-09 10:50:51 by donkey
*pats donkey on the back* - good coder :)
Posted on 2004-03-09 10:51:39 by f0dder
Thanks, donkey. I'll test out your project on my NT 4 machine.

I'm experimenting Jeremy's JCALG1 compression program right now. I tried compression JPEG images. The result i get is some of the JPEG images get compressed and some don't. Does anyone of you know why?

f0dder, thanks again.

TQN, i have yet to try those that u have recommended.
Posted on 2004-03-09 23:37:58 by trexxz
trexxz, generally - if the first algorithm is good enough & used at appropriate data - you will hardly be able to gain any further savings by using another compression algorithm. Otherwise, you could keep compressing to infinity, and sadly :p this is not possible.

JPEG is pretty good at what it does - lossy compression of photo-style images - so when applied to this class of images, you will not gain very much.

JPEG should also yield better results than using something like JCALG1 or Jibz' aPLib on the source image, unless if you're working on "simple" graphics. Btw you might want to test Jibz' aPLib against JCALG1, I think Jibz improved compression ratios since JCALG1 was written?
Posted on 2004-03-10 05:18:43 by f0dder
do you preserve ebx esi edi ebp?
Posted on 2004-03-10 14:57:58 by comrade