Re: [2/2] winemenubuilder: ignore icons in unsupported PNG format

[Damjan Jovanovic]

Please don't commit this patch, it's unnecessary. PNG support is not
"missing": winemenubuilder supports PNG icons just fine and has for
many years (IIRC, from .ico files and "valid" .exes/.dlls): it's
implemented by using windowscodecs (starting from
IWICImagingFactory_CreateDecoderFromStream() called from
convert_to_native_icon()) which auto-detects the file format.

In the case of PNG, that BITMAPINFO *pIcon pointer may not point to a
valid BITMAPINFO structure, but who cares, the fields of that
structure are never accessed, only opaquely memcpy()'ed en-masse.
Using void* or BYTE* instead of BITMAPINFO* might be clearer, but the
semantics are the same.

I've tested Stepmania 5, one of the problematic apps from #19241, and
winemenubuilder creates working 256x256 PNG icons when the previous
patch is applied and this one isn't.

Otherwise thank you for your contribution Indrek.

Regards
Damjan

On Thu, Aug 28, 2014 at 6:09 PM, Indrek Altpere
<efbiaiinzinz(a)hotmail.com> wrote:
> While fixing https://bugs.winehq.org/show_bug.cgi?id=19241 I saw that
> winemenubuilder does not handle/ignore png icon entries currently.
>
> As per MSDN blog, icon resources can contain raw PNG information instead of
> regular BITMAPINFO, but due to weird decisions, only way to differentiate
> between them is to check if the resource starts with PNG header bytes.
> http://blogs.msdn.com/b/oldnewthing/archive/2010/10/22/10079192.aspx
> Made the winemenubuilder ignore such entries for now (with fixme notices),
> since using PNG raw bytes as BITMAPINFO data is definitely invalid and is
> due to cause other issues/crashes when the best matching size icon happens
> to be PNG. A new bug should be opened for the missing PNG support.
>
> Regards,
> Indrek