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@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