OLEPictureImpl_Load: fix for headerless pictures

Kirill Smelkov kirr at landau.phys.spbu.ru
Wed Feb 4 12:49:56 CST 2004


On Tue, 3 Feb 2004, Fabian Cenedese wrote:

>
> >> >> This fails on on my computer and I don't
> >> >> know how wine could detect if it's a headerless picture or no picture at all
> >> >> if they look the same (so far).
> >> >
> >> >Maybe check header[0] to be real .bmp or .gif magic and header[1] for
> >> >zero?
> >>
> >> I couldn't see a difference, always 0x746c in the first entry.
> >
> >Then what type of picture it is?
> >
> >0x4947  GIF
> >0xd8ff  JPEG
> >0x4d42  BMP
> >0x0000  ICON
> >0x746c  ???
>
> Well, as I didn't use any pictures I don't know what it's supposed to be.
> Might as well be "NoPic" :) But I have also seen this marker where the
> second field was not zero.

It's probably some ole-storage magic. Don't know as i have no clue on how
ole works at all :)

>
> >Have you seen something like "Unknown magic, blah-blah-blah..."?
>
> It depends.
>
> Without your patch (where [0]=746c, and [1]=0) :
> trace:ole:OLEPictureImpl_Load (0x40383880,0x414de29c)
> fixme:ole:OLEPictureImpl_Load icon.idReserved=0
> fixme:ole:OLEPictureImpl_Load icon.idType=0
> fixme:ole:OLEPictureImpl_Load icon.idCount=0
> fixme:ole:OLEPictureImpl_Load [0] width 0
> fixme:ole:OLEPictureImpl_Load [0] height 0
> fixme:ole:OLEPictureImpl_Load [0] bColorCount 0
> fixme:ole:OLEPictureImpl_Load [0] bReserved 0
> fixme:ole:OLEPictureImpl_Load [0] xHotspot 0
> fixme:ole:OLEPictureImpl_Load [0] yHotspot 0
> fixme:ole:OLEPictureImpl_Load [0] dwDIBSize 0
> fixme:ole:OLEPictureImpl_Load [0] dwDIBOffset 0
> fixme:ole:OLEPictureImpl_Load CreateIcon failed.
> (obviously when all data are 0)
> trace:ole:OLEPictureImpl_Release (0x40383880)->(ref=2)
> trace:ole:OLEPictureImpl_Release (0x40382ec8)->(ref=1)
> trace:ole:OLEPictureImpl_Destroy (0x40382ec8)
> trace:ole:OLEPictureImpl_Release (0x40383880)->(ref=1)
> trace:ole:OLEPictureImpl_Destroy (0x40383880)
> fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete
> trace:ole:OLEPictureImpl_Release (0x40380a70)->(ref=1)
> trace:ole:OLEPictureImpl_Destroy (0x40380a70)
> trace:ole:OLEFontImpl_ReleaseHfont (0x4037f648)->(0xd82) (lock=0)
> trace:ole:OLEPictureImpl_Release (0x4037f7a8)->(ref=1)
> trace:ole:OLEPictureImpl_Destroy (0x4037f7a8)
>
> With your patch (already earlier with [0]=756c, [1]=...):
> fixme:ole:OLEPictureImpl_Load Could only read 109 of 2763 bytes in no-header case?
> fixme:ole:OLEPictureImpl_Load Unknown magic 746c, 109 read bytes:
> 6c 74 00 00 00 00 00 00 6c 74
> 00 00 00 00 00 00 00 00 01 00
> 00 00 0a 00 54 00 61 00 62 00
> 20 00 31 00 01 00 00 00 04 52
> e3 0b 91 8f ce 11 9d e3 00 aa
> 00 4b b8 51 6c 74 00 00 00 00
> 00 00 00 00 00 00 00 00 0a 00
> 54 00 61 00 62 00 20 00 32 00
> 01 00 00 00 04 52 e3 0b 91 8f
> ce 11 9d e3 00 aa 00 4b b8 51
> 6c 74 00 00 00 00 00 00 00 00
> 00 00 00 00 ff 02 04
>
> Maybe this isn't even part of a picture and we shouldn't be reading this.
> How does it know that a picture is coming? Perhaps we shouldn't
> even enter OLEPictureImpl_Load if there is no picture at all.

Fabi,

I temporarly disable checking for (header[1]==0). even in such case your
test-case doesn't start:
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:OleLoadPictureEx
(0x418ae294,774,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x4075fb08),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x418ae294,774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x4075fad8),
partially implemented.
fixme:ole:SPCF_CreateInstance
(0x40acdbc8,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x402313a4),
creating stdpic with PICTYPE_NONE.
fixme:ole:SPCF_CreateInstance
(0x40acdbc8,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x40231aac),
creating stdpic with PICTYPE_NONE.
fixme:ole:OLEPictureImpl_Load CreateIcon failed.
fixme:ole:OLEPictureImpl_Destroy Unsupported type 0 - unable to delete
fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

and then

MessageBox with
"Failed to load control 'SSTab' from TABCTL32.OCX. Your version of
TABCTL32.OCX is outdated...."

Does it work at all?

If so, then we probably should figure out whethere there are some
ole-storage magic present and chek for them when decidign whether to look at header[1]
and how to interpret it.

>
> Thanks
>
> bye  Fabi

--
	Kirill.




More information about the wine-devel mailing list