August 2014 - Wine-Devel - list.winehq.org

Re: include: add EncryptedFileRaw functions and defines (try 2)

by Austin English

On Thu, Aug 28, 2014 at 2:19 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > On 08/28/2014 12:37 AM, Austin English wrote: > > Splitting from https://source.winehq.org/patches/data/106010 for easier > > review > And the patch? > > bye > michael > Resent, thanks Michael. -- -Austin

Aug. 28, 2014

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

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

Aug. 28, 2014

Re: wpcap: Load libpcap dynamically

by Henri Verbeet

On 28 August 2014 18:23, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > André already mentioned a good counter-example ... capi2032. > Considering it's a very small DLL, I think that would be easy to fix.

Aug. 28, 2014

Re: wpcap: Load libpcap dynamically

by Sebastian Lackner

Am 28.08.2014 um 18:17 schrieb Vincent Povirk: > On Wed, Aug 27, 2014 at 7:03 AM, Scott Ritchie <scottritchie(a)ubuntu.com> wrote: >> As an update for the Ubuntu packages, I have opted for modifying the >> package rules rather than patching wine. As a general rule I like to >> minimize the number of patches to upstream in my packages. I would >> still recommend applying Andre's patch upstream as it provides some >> consistency with the way the rest of Wine operates, but it's no big >> deal. > > I think it's consistent with the rest of Wine as it is now. We > generally don't load dependencies dynamically if the dll would be > completely useless without them (e.g. openal32, mscms, winex11, every > sound driver). Openal at least is truly optional, in that Wine should > be just as compatible without it (it's not part of Windows, so all > Windows apps that need it should ship with a usable native version). > > André already mentioned a good counter-example ... capi2032.

Aug. 28, 2014

Re: wpcap: Load libpcap dynamically

by Vincent Povirk

On Wed, Aug 27, 2014 at 7:03 AM, Scott Ritchie <scottritchie(a)ubuntu.com> wrote: > As an update for the Ubuntu packages, I have opted for modifying the > package rules rather than patching wine. As a general rule I like to > minimize the number of patches to upstream in my packages. I would > still recommend applying Andre's patch upstream as it provides some > consistency with the way the rest of Wine operates, but it's no big > deal. I think it's consistent with the rest of Wine as it is now. We generally don't load dependencies dynamically if the dll would be completely useless without them (e.g. openal32, mscms, winex11, every sound driver). Openal at least is truly optional, in that Wine should be just as compatible without it (it's not part of Windows, so all Windows apps that need it should ship with a usable native version).

Aug. 28, 2014

Wine test analysis August 28th

by Jeremy White

Hi Folks, Good news - we've made progress! We're down to only 25 issues. I have now annotated every single failure: https://www.winehq.org/~jwhite/5aeb834dd4e7.html (although some of my annotations are out of date). It looks like the biggest win will come if Francois and Hans can figure out the msi timing stuff. I think there are a number of ones that might be 'easy': http://test.winehq.org/data/tests/gdi32:font.html Bug 35573, 35760, fails in certain locales http://test.winehq.org/data/tests/mmdevapi:capture.html I asked Jorg, but he may have a hard time getting to it. It's nice and consistent... http://test.winehq.org/data/tests/shell32:shlexec.html Nice and consistent; asked Misha to look into it, but he can't. http://test.winehq.org/data/tests/user32:sysparams.html Nice and consistent; I'd invited Frederic to work on this one, but looks like he could use help... Don't be shy, there are plenty of consistent failures to go around! From there, I think nudging Jacek, Nikolay, and Huw will get us our next big set of wins. Nudge, nudge, nudge. Cheers, Jeremy p.s. Reminder: my analysis always shows up at http://winehq.org/~jwhite/latest.html

Aug. 28, 2014

Re: winemenubuilder: fix crash caused by invalid icon entries and avoid future crashes by ignoring unhandled png entries (resend)

by Akihiro Sagawa

On Thu, 28 Aug 2014 09:30:34 +0300, Indrek Altpere wrote: > Forgot to link to the bug before, also added more detailed description. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=19241 > > For the InnoSetup 5 crash (and likely other similar reported crashes), the > issue seems to be GRPICONDIRENTRY with invalid information. (...) > 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. Hello Indrek, I think your patch looks nice, but needs to split into two or more parts. This means one for invalid GRPICONDIRENTRY issue and one for PNG entry's enhancement. If you do this, it will be easier to read and easier to pass. For details, please read our Patch Submission Guidelines[1], especially Code Guidelines section. [1] http://wiki.winehq.org/SubmittingPatches Regards, Akihiro Sagawa

Aug. 28, 2014

Re: [1/2] netcfgx: Add stub for INetCfgComponent

by Alistair Leslie-Hughes

On 28/08/2014 6:39 AM, André Hentschel wrote: > --- > dlls/netcfgx/netcfg.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 148 insertions(+) > Your missing tests to show that this interface exist. Same goes for INetCfgClassSetup2. Best Regards Alistair Leslie-Hughes

Aug. 28, 2014

Re: include: add EncryptedFileRaw functions and defines (try 2)

by Michael Stefaniuc

On 08/28/2014 12:37 AM, Austin English wrote: > Splitting from https://source.winehq.org/patches/data/106010 for easier > review And the patch? bye michael

Aug. 28, 2014

Re: [PATCH 2/5] dxgi: Free the wined3d object when device creation fails (Valgrind).

by Matteo Bruni

2014-08-27 19:22 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 27 August 2014 18:40, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> --- >> dlls/dxgi/device.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/dlls/dxgi/device.c b/dlls/dxgi/device.c >> index 837c57f..0f3ae7d 100644 >> --- a/dlls/dxgi/device.c >> +++ b/dlls/dxgi/device.c >> @@ -350,7 +350,7 @@ HRESULT dxgi_device_init(struct dxgi_device *device, struct dxgi_device_layer *l >> IWineDXGIDeviceParent *dxgi_device_parent; >> IWineDXGIAdapter *wine_adapter; >> UINT adapter_ordinal; >> - struct wined3d *wined3d; >> + struct wined3d *wined3d = NULL; >> void *layer_base; >> HRESULT hr; >> WINED3DCAPS caps; >> @@ -430,6 +430,12 @@ fail: >> wined3d_device_decref(device->wined3d_device); >> LeaveCriticalSection(&dxgi_cs); >> } >> + else if (wined3d) >> + { >> + EnterCriticalSection(&dxgi_cs); >> + wined3d_decref(wined3d); >> + LeaveCriticalSection(&dxgi_cs); >> + } > > I don't think this works as intended. For example, if > IDXGIAdapter_QueryInterface() fails, you'd call wined3d_decref() > twice. Uh, indeed. I'll fix that up. > There's also a wined3d_decref() after wined3d_device_create(), That too. > although it's indeed missing for IWineDXGIDevice_QueryInterface() and > wined3d_get_device_caps().

Aug. 27, 2014