November 2011 - Wine-devel - list.winehq.org

Antw.: RFC: depending on getifaddrs in iphlpapi
by André Hentschel 10 Nov '11

10 Nov '11

Why? AFAIK getifaddr was added to at least openSolaris Last year and you still can use the old Code as fallback Gesendet mit meinem HTC ----- Reply message ----- Von: "Juan Lang" <juan.lang(a)gmail.com> An: "Michael Stefaniuc" <mstefani(a)redhat.com> Cc: "Wine Devel" <wine-devel(a)winehq.org> Betreff: RFC: depending on getifaddrs in iphlpapi Datum: Do., Nov. 10, 2011 18:41 >> I'm thinking of replacing the current IPv4 enumeration code, which >> uses ioctl/SIOCGIFCONF, with getifaddrs. The reason I'm leaning >> toward replacing, rather than adding side-by-side with the current >> code, is that getifaddrs is commonly available: it's available on all >> recent versions of Linux, as well as on FreeBSD and MacOS. There > recent versions of Linux as of which year? Good question. When I was writing this code in 2003, the stable version of Debian didn't support it. I haven't seen a Linux system that doesn't support it since then, but I've only checked periodically. >> might be some platform somewhere that's disenfranchised by this, but >> I'm not sure it's worth the code complexity to maintain the current >> code. > What about Solaris/OpenSolaris? That's the only other major system where > Wine can be made to run. Ah. Okay, that's an important objection. I'll go with keeping the current code, then. Thanks, --Juan

2 1

RFC: depending on getifaddrs in iphlpapi
by Juan Lang 10 Nov '11

10 Nov '11

Hi folks, right now iphlpapi uses autoconf to detect if getifaddrs is available, and only uses it to enumerate IPv6 addresses. I'm thinking of replacing the current IPv4 enumeration code, which uses ioctl/SIOCGIFCONF, with getifaddrs. The reason I'm leaning toward replacing, rather than adding side-by-side with the current code, is that getifaddrs is commonly available: it's available on all recent versions of Linux, as well as on FreeBSD and MacOS. There might be some platform somewhere that's disenfranchised by this, but I'm not sure it's worth the code complexity to maintain the current code. Any strenuous objections? Reasons to use getifaddrs rather than ioctls: 1. SIOCGIFCONF is actually pretty fiddly, and is the current code is broken on FreeBSD, or FreeBSD's support is broken (bug 27653.) 2. SIOCGIFFLAGS is apparently broken on current Linux versions. I haven't found any bug against Wine or Linux about that, I just noticed it while testing the existing code. Thanks, --Juan

2 2

RFC: ddraw: Fix conversion between D3DVIEWPORT and D3DVIEWPORT2
by Octavian Voicu 10 Nov '11

10 Nov '11

Hi, Attached is a series of patches to add better tests and fix Wine's implementation of the conversion between D3DVIEWPORT and D3DVIEWPORT2 structures in IDirect3DViewport / IDirect3DViewport2 / IDirect3DViewport3 implementation. I'm sending this to to wine-devel because next commit round will be on Monday, so I hope to get some feedback until then and fix any issues before sending to wine-patches. I'm also working on fixing IDirect3DViewport::TransformVertices, which at the very least does not work if viewport data is set using D3DVIEWPORT2. This will fix bug http://bugs.winehq.org/show_bug.cgi?id=11819, which is actually caused by Wine's buggy implementation of TransformVertices and has nothing to do with the z-buffer locking not begin implemented. I'm working on some tests and a fix, and will post them here when they are ready. Octavian -- Octavian Voicu (5): ddraw/tests: Remove some redundant d3d viewport tests. ddraw/tests: Add macro to verify viewport data bounds. ddraw/tests: Make ViewportTest loop through an array of tests. ddraw: Add error checking for IDirect3DViewportImpl_[GS]etViewport, with tests. ddraw: Add more viewport tests and make them pass under Windows and Wine. dlls/ddraw/tests/d3d.c | 329 ++++++++++++++++++++++++++++-------------------- dlls/ddraw/viewport.c | 114 ++++++++++------- 2 files changed, 260 insertions(+), 183 deletions(-)

1 0

Re: winspool.drv: Correct test for Device Capabilities (resend)
by Marvin 10 Nov '11

10 Nov '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=15332 Your paranoid android. === WINEBUILD (build) === Can't determine base name

2 1

Re: [PATCH 3/3] wined3d: Report all FBO-attachable formats as suitable for render target usage.
by Matteo Bruni 10 Nov '11

10 Nov '11

2011/11/9 Matteo Bruni <mbruni(a)codeweavers.com>: > --- This patch is not correct, please ignore it...

1 0

Re: d3dx9_36/tests [patch 2/2, try 3]: Add tests for D3DXCreatePolygon
by Matteo Bruni 09 Nov '11

09 Nov '11

2011/11/9 David Adam <david.adam.cnrs(a)gmail.com>: > Better, but there are still issues: + if( polygon ) polygon->lpVtbl->Release(polygon); + if( ppBuffer ) ID3DXBuffer_Release(ppBuffer); You aren't setting those pointers to NULL (and your test shows that D3DXCreatePolygon doesn't touch them when the call fails), so those ifs actually are protecting nothing. In patch 1/2, LockVertex/IndexBuffer should not fail in normal circumstances, so it's probably better to use ERR instead of TRACE there. Also, please, try to fixup the code style. E.g. the preferred style for 'if's and loops is to have a whitespace between the keyword and the '(' and no whitespace between the parentheses and the condition. Stick with that. Don't use hungarian notation (ppBuffer ...), fix whitespaces around operators, etc

2 1

Strange window manager bug
by Alex Henrie 09 Nov '11

09 Nov '11

Does anyone have an idea of what could be causing http://bugs.winehq.org/show_bug.cgi?id=29027 ? -Alex

1 0

Re: [1/2] Revert "msi: Use MsgWaitForMultipleObjectsEx to do waits."
by Alexandre Julliard 09 Nov '11

09 Nov '11

Hans Leidekker <hans(a)codeweavers.com> writes: > This reverts commit 2556173f20ba9583044aaf31b16cbb2214d2b907. > It causes a regression in the Quicken 2011 installer. Does it really break because we are processing messages, or just because we don't wait properly? If so fixing the wait would seem a better choice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] winhttp: Convert string data to UTF-8 and add a corresponding content type header.
by Marvin 09 Nov '11

09 Nov '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=15333 Your paranoid android. === W2K3R2SESP2 (32 bit winhttp) === winhttp.c:2158: Test failed: got 80072f78

1 0

Re: [PATCH 1/5] wined3d: Don't print FIXMEs for misaligned surface maps.
by Stefan Dösinger 09 Nov '11

09 Nov '11

On Tuesday 08 November 2011 20:48:55 Henri Verbeet wrote: > - FIXME("Partial block lock with %s\n", > debug_d3dpool(surface->resource.pool)); I added this fixme because we have to tests for the offset that is returned in this case. Do you have an application that triggers this fixme, or do you want to suppress the fixmes in the tests?

2 3