Re: OLEPictureImpl_Load: fix for headerless pictures

[Fabian Cenedese]

> Hi,
> In my case headerless bitmaps have
> { 0x42, 0x4d, 0x9c, 0xbd, 0x00, 0x00, 0x00, 0x00 } first 8 bytes.
>
> So, when last four are equal to zero its 'no header' case.
>
> ChangeLog:
>        OLEPictureImpl_Load: fix for headerless pictures
> Index: dlls/oleaut32/olepicture.c
>
> RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v
> retrieving revision 1.30
> diff -u -r1.30 olepicture.c
> --- dlls/oleaut32/olepicture.c  5 Sep 2003 23:08:33 -0000       1.30
> +++ dlls/oleaut32/olepicture.c  1 Feb 2004 12:35:41 -0000
> @@ -875,7 +875,7 @@
>       FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread);
>       return hr;
>   }
> - if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */
> - if (header[1] > statstg.cbSize.QuadPart || (header[1]==0)) {/* Incorrect header, assume none. */
>  xread = 8;
>  xbuf = This->data = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,statstg.cbSize.QuadPart);
>  memcpy(xbuf,&header,8);

I don't think that this is correct. If header[1] is 0 then it means that there is no picture at
all, and not a picture without header (me thinks). When trying to start a program that uses
the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because
wine tries to create icons that aren't in the stream. So there's no point in continuing and trying
to read data from the stream. I could only make it work when I jump out of this function
without doing anything if header[1] is 0. That may be wrong too but this patch doesn't
solve it either.

Described here:
http://www.winehq.org/hypermail/wine-devel/2004/01/0968.html

bye   Fabi

OLEPictureImpl_Load: fix for headerless pictures

[Kirill Smelkov]

On Tue, 3 Feb 2004, Fabian Cenedese wrote:
> > Hi,
> > In my case headerless bitmaps have
> > { 0x42, 0x4d, 0x9c, 0xbd, 0x00, 0x00, 0x00, 0x00 } first 8 bytes.
> >
> > So, when last four are equal to zero its 'no header' case.
> >
> > ChangeLog:
> >        OLEPictureImpl_Load: fix for headerless pictures
> > Index: dlls/oleaut32/olepicture.c
> >
> > RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v
> > retrieving revision 1.30
> > diff -u -r1.30 olepicture.c
> > --- dlls/oleaut32/olepicture.c  5 Sep 2003 23:08:33 -0000       1.30
> > +++ dlls/oleaut32/olepicture.c  1 Feb 2004 12:35:41 -0000
> > @@ -875,7 +875,7 @@
> >       FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread);
> >       return hr;
> >   }
> > - if (header[1] > statstg.cbSize.QuadPart) {/* Incorrect header, assume none. */
> > - if (header[1] > statstg.cbSize.QuadPart || (header[1]==0)) {/* Incorrect header, assume none. */
> >  xread = 8;
> >  xbuf = This->data = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,statstg.cbSize.QuadPart);
> >  memcpy(xbuf,&header,8);
>
> I don't think that this is correct. If header[1] is 0 then it means that there is no picture at
> all, and not a picture without header (me thinks). When trying to start a program that uses
> the SSTab from TabCtl32.ocx without having assigned icons to the tabs it fails because
> wine tries to create icons that aren't in the stream. So there's no point in continuing and trying
> to read data from the stream. I could only make it work when I jump out of this function
> without doing anything if header[1] is 0. That may be wrong too but this patch doesn't
> solve it either.

In my case there are lots of *.bmp (with picture) with exactly same header
i mentioned. Thus header[1]==0 doesnt imply 'there is no picture at all'

This pictures came in ole storage taken from a real win32 app, and loading
them on windows works correctly.

--
    Kirill.