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

Re: [PATCH 2/5] d3d10: Add a stub ID3D10StateBlock implementation.
by Nikolay Sivov Nov. 15, 2011

Nov. 15, 2011

On 11/14/2011 23:11, Henri Verbeet wrote: > +static ULONG STDMETHODCALLTYPE d3d10_stateblock_Release(ID3D10StateBlock *iface) > +{ > + struct d3d10_stateblock *stateblock = impl_from_ID3D10StateBlock(iface); > + ULONG refcount = InterlockedIncrement(&stateblock->refcount); > + > + TRACE("%p decreasing refcount to %u.\n", stateblock, refcount); > + > + if (!refcount) > + HeapFree(GetProcessHeap(), 0, stateblock); > + > + return refcount; > +} Decrement maybe?

1 0

Vista/w2k8/w7 users, please test mmdevapi with exclusive mode disabled
by Joerg-Cyril.Hoehle＠t-systems.com Nov. 14, 2011

Nov. 14, 2011

Hi, Please test mmdevapi again using testbot job #15369 with exclusive mode disabled. Brian, it seems like you had some other app use audio while performing the tests. This would explain the DEVICE_IN_USE error: render.c:427: Test failed: Initialize(exclus., 8000x 8x1) returns 8889000a and the subsequent crash. My new version of the tests should prevent crashes in such a situation. Saulius, you need not perform many tests because of random GetPosition/Padding failures. I've not yet changed that part of the tests. Thank you for repeated testing, Jörg Höhle

2 1

Re: winemaker: Be less picky when detecting the target type
by Francois Gouget Nov. 14, 2011

Nov. 14, 2011

On Fri, 11 Nov 2011, André Hentschel wrote: > seen some "broken" project files which still worked with msvc but not with winemaker > --- > tools/winemaker | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/tools/winemaker b/tools/winemaker > index 2ee79ea..921f8ef 100755 > --- a/tools/winemaker > +++ b/tools/winemaker > @@ -589,16 +589,16 @@ sub source_scan_project_file($$$) > #print $prj_name; > next; > } elsif (/^# TARGTYPE/) { > - if (/[[:space:]]0x0101$/) { > + if (/0x.*101$/) { The various .* worry me a bit. Would something like [0-9a-fA-F]* be permissive enough? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

2 1

Re: [1/5]usp10: break with a better understanding on the handling of bidi strengths
by Alexandre Julliard Nov. 14, 2011

Nov. 14, 2011

Aric Stewart <aric(a)codeweavers.com> writes: > + if (strength) > + { > + str = strength[cnt]; > + if (pwcInChars[cnt] == Numeric_space) > + str_space = TRUE; > + else > + str_space = FALSE; > + } str_space is not used for anything. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: taskmgr: Give a name and statically initialize PerfDataCriticalSection.
by Francois Gouget Nov. 14, 2011

Nov. 14, 2011

On Mon, 14 Nov 2011, Francois Gouget wrote: [...] > static CRITICAL_SECTION PerfDataCriticalSection; > +static CRITICAL_SECTION_DEBUG PerfDataCriticalSection_debug = > +{ > + 0, 0, &PerfDataCriticalSection, > + { &PerfDataCriticalSection_debug.ProcessLocksList, &PerfDataCriticalSection_debug.ProcessLocksList }, > + 0, 0, { (DWORD_PTR)(__FILE__ ": PerfDataCriticalSection") } > +}; [...] > + PerfDataCriticalSection.DebugInfo->Spare[0] = 0; > DeleteCriticalSection(&PerfDataCriticalSection); Actually I think unsetting Spare[0] is wrong for statically initialized critical sections because it causes RtlDeleteCriticalSection() to do an RtlFreeHeap() on DebugInfo which happens to also be statically allocated. So I'll rework this patch and some of my previous patches. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Re: dlls: Remove unneeded include directives in resource files.
by Marvin Nov. 14, 2011

Nov. 14, 2011

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=15373 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

re: [PATCH] ntdll: Use VALGRIND_RESIZEINPLACE_BLOCK when available
by Dan Kegel Nov. 12, 2011

Nov. 12, 2011

You might want to compare with Bart's patch for the same thing, http://www.winehq.org/pipermail/wine-patches/2011-April/100570.html Bart asked for comments on it, but didn't get much feedback: http://www.winehq.org/pipermail/wine-devel/2011-May/090029.html My guess is changes like this are really hard to get in unless you can get Alexandre's full attention somehow. Maybe if it was demonstrated to find interesting bugs in wine...

1 0

Re: Include math.h in d3dx9math.inl as it uses sqrt().
by Henri Verbeet Nov. 12, 2011

Nov. 12, 2011

Does the Microsoft header include math.h?

4 4

Re: d3dx9 [patch 1/2, try 4]: Implement D3DXCreatePolygon
by Rico Schüller Nov. 11, 2011

Nov. 11, 2011

Am 10.11.2011 10:59, schrieb David Adam: > Hello, > > I tried to fix the remaining issues pointed by Matteo and Rico. > I kept the style of Misha Koshelev who already implemented many shapes in > the mesh.c file. > > Any more suggestions? > > David > > > Hi David, I still have some suggestions. Please review all TRACE and ok messages. I think they should mostly end with '\n' and they should not contain "useless" chars like ':' and spaces where not needed. Also you may save the ref value from the call before you compare it: + IDirect3DDevice9_Release(device); + ok(ref == 0, "Expected refcount = 0, received %d", ref); I think it is pretty useful to check the reference count in general for all release calls. Please review that part, so that it does what it should do! It's not only the line I mentioned as an example here! If you don't understand some parts and don't know exactly what to do, please ask. I'd prefer if the comparison would be within the if, otherwise you could compare to an uninitialized value, which could get bogus results (even if that only happens when other test fail, I think it's better than comparing uninitialized values): + if (polygon) ref = polygon->lpVtbl->Release(polygon); + ok(ref == 0, "Expected refcount = 0, received %d", ref); Please see my points as a suggestion. I think the answers to the patches showed a lot of issues, so please review the whole patch before sending it again, you may find some other not mentioned things. Note: Not the fastest sent patch will get in, but the "best" working solution. Cheers Rico

1 0

Re: Add dxerr.h
by Henri Verbeet Nov. 10, 2011

Nov. 10, 2011

On 10 November 2011 02:27, Daniel Scharrer <dscharrer(a)gmail.com> wrote: > +#include <dxerr9.h> > + > +#define DXGetErrorStringA DXGetErrorString9A > +#define DXGetErrorStringW DXGetErrorString9W > +#define DXGetErrorString WINELIB_NAME_AW(DXGetErrorString) > + > +#define DXGetErrorDescriptionA DXGetErrorDescription9A > +#define DXGetErrorDescriptionW DXGetErrorDescription9W > +#define DXGetErrorDescription WINELIB_NAME_AW(DXGetErrorDescription) Which SDK version does this match?

2 1

Antw.: RFC: depending on getifaddrs in iphlpapi
by André Hentschel Nov. 10, 2011

Nov. 10, 2011

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 Nov. 10, 2011

Nov. 10, 2011

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 Nov. 10, 2011

Nov. 10, 2011

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 Nov. 10, 2011

Nov. 10, 2011

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 Nov. 10, 2011

Nov. 10, 2011

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 Nov. 9, 2011

Nov. 9, 2011

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 Nov. 9, 2011

Nov. 9, 2011

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 Nov. 9, 2011

Nov. 9, 2011

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 Nov. 9, 2011

Nov. 9, 2011

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 Nov. 9, 2011

Nov. 9, 2011

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

Re: mscoree: Implement ICorDebug CreateProcess (try 2)
by Alexandre Julliard Nov. 9, 2011

Nov. 9, 2011

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Move DuplicateHandle to Create_Process. > Added Makefile.in (missing from first patch) > > Changelog: > mscoree: Implement ICorDebug CreateProcess You should put everything in cordebug.c, there's no need to have a separate file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/4] ddraw/tests: Add a test for YV12 partial block locks and lock offsets
by Marvin Nov. 9, 2011

Nov. 9, 2011

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=15324 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [4/4] ddraw: Set correct HEL and HAL color models
by Marvin Nov. 9, 2011

Nov. 9, 2011

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=15327 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [3/4] ddraw: Add more tests and fixes for SetSurfaceDesc
by Marvin Nov. 9, 2011

Nov. 9, 2011

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=15326 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Adopt a patch?
by Michael Ost Nov. 8, 2011

Nov. 8, 2011

I have a patch for a bug that I won't be able to shepherd through the patch submission process for some time. The bug is that GetFileVersionInfoSize doesn't work for files with path names longer than 128 characters. The patch includes an untried unit test. And I've confirmed the behavior in Windows Vista. We use an older version of Wine, and my boss won't let me take the time right now to rework the patch for the newest Wine sources. If someone wants to they can take this patch, tweak it for the new wine, update it to wine-patch requirements and push it through the system. Otherwise I'll submit as soon as I can. Cheers, Michael Ost

2 1

Re: apphelp: add a stub for ApphelpCheckShellObject
by Dmitry Timoshkov Nov. 8, 2011

Nov. 8, 2011

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI ApphelpCheckShellObject(REFCLSID ObjectCLSID, BOOL ShimIfNecessary, ULONGLONG *pullFlags) > +{ > + FIXME("stub: %s %p\n", debugstr_guid(ObjectCLSID), pullFlags ); > + return TRUE; > +} It's a common convention in Wine to avoid hungarian notation by all means. In this case naming variables something like 'clsid, shim, flags' woud be better. -- Dmitry.

1 0

Fwd: d3dx9_36 [patch 1/2, resent]: Implement D3DXCreatePolygon
by David Adam Nov. 8, 2011

Nov. 8, 2011

Hello, any problem with this patch http://source.winehq.org/patches/data/80433 and this one http://source.winehq.org/patches/data/80434 Thanks in advance David ---------- Forwarded message ---------- From: David Adam <david.adam.cnrs(a)gmail.com> Date: 2011/10/30 Subject: d3dx9_36 [patch 1/2, resent]: Implement D3DXCreatePolygon To: wine-patches <wine-patches(a)winehq.org> Fix a possible crash when calling D3DXCreateMeshFVF. A+ David

3 2

Re: [10/11] ddraw/tests: Add assorted D3D3 DrawPrimitive/visual tests.
by Stefan Dösinger Nov. 8, 2011

Nov. 8, 2011

On Tuesday 08 November 2011 01:14:22 Octavian Voicu wrote: > The idea behind using triangles was to fit everything in one screen so > I could debug it visually very easily. I'm thinking I can still have > that if I draw full-screen quads in a loop, like you suggest, then > blit one small rectangle to the primary surface, in different > positions for each test. I don't think that's necessary, I found those one-quad screens easier to debug than multi-quads, although that may be a matter of taste. > I think > we should cover special error cases if there are any (that is, if > D3DERR_INVALIDVERTEXTYPE is not returned for D3DVT_ constants). Well, you can't test them. D3DVT_LVERTEX is 2, and D3DFVF_XYZ is 2. The number 2 doesn't have any tags attached, so what you'd be testing is how drawPrimitive responds to D3DFVF_RESERVED0, not what it does with D3DVT_* enums. The statement in the SDK doesn't make sense with that in mind. > About the ddraw/visual tests: I think we need one structure for each > of d3d, d3d2, d3d3, d3d7, where to have most of the things we store > globally or in local vars now, and make the create/release functions > work with that. Yes, I was about to write something like that as a response to the cleanup patches. PS: You forgot to CC wine-devel, I assume this was by accident so I've added it to the reply again. You may want to resend your original mail to wine- devel.

2 2

Re: [01/11] ddraw/tests: Fix a couple of copy-paste typos in test messages.
by Stefan Dösinger Nov. 8, 2011

Nov. 8, 2011

This patch is OK, the others need some discussion and work.

1 0

Re: [3/3] ddraw/tests: Add a partial block lock test
by Alexandre Julliard Nov. 8, 2011

Nov. 8, 2011

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -4,7 +4,7 @@ > * Copyright (C) 2005 Antoine Chavasse (a.chavasse(a)gmail.com) > * Copyright (C) 2005 Christian Costa > * Copyright 2005 Ivan Leo Puoti > - * Copyright (C) 2007 Stefan Dösinger > + * Copyright (C) 2007-2011 Stefan Dösinger for CodeWeavers Adding a range of years in a copyright notice is usually discouraged, because it's only valid if you have actually made significant changes every year, which doesn't seem to be the case here. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 3/7] ntoskrnl: intialze unknown fields of the irp with 0xce in IoInitializeIrp
by Alexandre Julliard Nov. 8, 2011

Nov. 8, 2011

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -864,6 +873,10 @@ VOID WINAPI IoCompleteRequest( IRP *irp, UCHAR priority_boost ) > > iosb = irp->UserIosb; > status = irp->IoStatus.u.Status; > + > + assert( status != STATUS_PENDING ); > + assert( status != 0xdeafbeef ); > + You can't assert on things that are set by the caller. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32/tests: add tests for GetDllDirectory (try 2)
by Alexandre Julliard Nov. 8, 2011

Nov. 8, 2011

Thomas Faber <thfabba(a)gmx.de> writes: > + /* no buffer, determine length */ > + SetLastError(0xdeadbeef); > + ret = pGetDllDirectoryA(0, NULL); > + error = GetLastError(); > + ok(ret == length + 1, "Expected %u, got %u\n", length + 1, ret); > + ok(error == 0xdeadbeef, "Error is %u\n", error); Testing last error on success is generally not useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/11] ddraw/tests: Add assorted D3D3 DrawPrimitive/visual tests.
by Stefan Dösinger Nov. 8, 2011

Nov. 8, 2011

Hi, Design-wise I think the 8 triangles and readback grid make the test fairly difficult to read. You could set up a structure that contains the d3d parameters you're changing between the tests and the expected color and then loop over the table. Something like this: const struct { BOOL d3drs_lighting; DWORD dp_flags; <- for things like D3DP_DONOTLIGHT DWORD fvf; void *vertices; DWORD expected_color; } test_data[] = { ... }; You can also think about sharing this control table between d3d2, d3d3 and d3d7 by having different color fields for that, but I don't know how well this will work. On Monday 07 November 2011 23:27:13 Octavian Voicu wrote: > + DWORD expected[] = { GRAY, WHITE, YELLOW2, YELLOW, GREEN, GREEN, BLUE, BLUE }; Please make data const where you can. > + /* Note: IDirect3DDevice3::DrawPrimitive calls with D3DVT_ vertex > types should fail. */ + > + /* Triangle 0 -- D3DFVF_VERTEX (vertices with normals, but without > colors). */ + hr = IDirect3DDevice3_DrawPrimitive(Direct3DDevice3, > D3DPT_TRIANGLELIST, D3DVT_VERTEX, > + vertices, 3, D3DDP_WAIT); > + ok(hr != DDERR_INVALIDPARAMS, "DrawPrimitive returned: %08x\n", > hr); I don't think there's a point in testing this, both D3DVT_* and D3DFVF_* are defines / enums that map to integers, and it is obvious that you get wrong behavior if you mix those. The ok condition looks strange. If you're trying to avoid a todo_wine, don't do that, just mark tests that show a difference between Wine and Windows as todo_wine. (I guess Wine currently returns DD_OK, and Windows returns D3DERR_INVALIDVERTEXFORMAT) > + /* Make sure getPixelColor works correctly. */ > + color = getPixelColor(device, 320, 240); > + ok(color == RED, "getPixelColor returned: %08x\n", color); We have some sanity checks for that in the main function Most of this applies to the d3d2 and d3d3 tests as well. I haven't looked over the cleanup patches yet.

2 1

Re: winscard/tests: Add the tests file (try 3)
by Bruno Jesus Nov. 7, 2011

Nov. 7, 2011

On Mon, Oct 31, 2011 at 23:27, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > try 3 - avoid magic constants by using winscard.h defines > try 2 - split the patches and fix win2000 error > > This is the starting point for the winscard implementation. I'll add > dozens of tests and I would like all of them to pass in windows before > we start using pcsclite. > Testbot will probably be useless since it does not have a smartcard > reader connected so I'll ensure all tests succeed in my local machine > before submitting them to wine (i'll append the test results on the patch email) > > In the next days I'll be updating the test file constantly by adding a > new tested function per patch. > Hi, I would like to know if there is anything wrong with this patch? It is currently working on testbot and introduces the tests file for the winscard dll. http://source.winehq.org/patches/data/80485 I really would like to get smart cards working until the wine l337 release. Thanks in advance, Bruno

1 0

Re: [PATCH 3/6] [UnInstall]: No longer use unix stdio functions, but the kernel32 equivalent
by Alexandre Julliard Nov. 7, 2011

Nov. 7, 2011

Eric Pouech <eric.pouech(a)orange.fr> writes: > #28185 > > A+ > --- > > programs/uninstaller/main.c | 65 ++++++++++++++++++++++++++++++------------- > 1 files changed, 46 insertions(+), 19 deletions(-) I'm not sure that's a good idea. The output of uninstaller is meant to be used by Unix apps, it's not something a user would want to display on the console. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: winealsa: Don't set ALSA's period time.
by Alexandre Julliard Nov. 7, 2011

Nov. 7, 2011

Joerg-Cyril.Hoehle(a)t-systems.com writes: > Hi, > > perhaps I shouldn't send this one day before release... > > I argue that Wine has no business setting ALSA's period size, > esp. not to a completely random value like duration/10. It doesn't work here: ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so capture.c && touch capture.ok capture.c:618: Test failed: Should not fail for 8 or 16 bits per sample capture.c:618: Test failed: Should not fail for 8 or 16 bits per sample make: *** [capture.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmd: Add helper for 'if' comparison operations evaluation (try 2)
by Octavian Voicu Nov. 7, 2011

Nov. 7, 2011

2011/11/7 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > + /* Note: '==' can't be returned by WCMD_parameter since '=' is a separator */ > + p = paramEnd + 1; > + while (*p == ' ' || *p == '\t') > + p++; > + > + if (!p || *p != '=' || !(p+1) || *(p+1) != '=') > + goto syntax_err; > + > + strcpyW(operator, eqeqW); > + p += strlenW(operator); Hi, This doesn't look general enough, I'm not sure how you want to handle the other operators. Wouldn't it be better to just find next space/tab (skip all non-whitespace chars) then assign the part of the string separated by whitespace to be the operator? With this approach you also don't need that syntax check there. Octavian

2 1

Re: [2/2] mscoree: Implement ICorDebug CreateProcess
by Alexandre Julliard Nov. 7, 2011

Nov. 7, 2011

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > + { > + HANDLE handle, thread; > + DuplicateHandle(GetCurrentProcess(), lpProcessInformation->hProcess, > + GetCurrentProcess(), &handle, 0, FALSE, DUPLICATE_SAME_ACCESS); > + DuplicateHandle(GetCurrentProcess(), lpProcessInformation->hThread, > + GetCurrentProcess(), &thread, 0, FALSE, DUPLICATE_SAME_ACCESS); > + hr = CorDebugProcess_Create(This, (IUnknown**)&pDebugProcess, > + lpProcessInformation->dwProcessId, handle, thread); It would be better to duplicate the handles in CorDebugProcess_Create, and of course check for error and return an appropriate failure. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] ntdll: Setting WRITECOPY protection on an image section is allowed.
by Alexandre Julliard Nov. 7, 2011

Nov. 7, 2011

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch should fix the regression reported in the bug 28994. This needs more test cases, in particular for normal file mappings, as well as for VirtualAlloc behavior. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/2] kernel32/tests: add tests for GetDllDirectoryA
by Vitaliy Margolen Nov. 6, 2011

Nov. 6, 2011

On 11/06/2011 09:14 AM, Thomas Faber wrote: > > + length = strlen(dll_directories[i]); > + assert(sizeof(buffer) > length + 1); Please don't do this. Tests shouldn't assert because programmer failed to pick the right buffer size of hard-coded strings. > + ok(GetLastError() == 0xdeadbeef, "Error is %u\n", GetLastError()); You should get value of GetLastError() before the ok check here. See all places that check values of GetLastError(). > + ok(buffer[length + 1] == 'A', "i=%d, Buffer overflow\n", i); > + ok(buffer[ret] == 0, "i=%d, Wrong length or not null terminated\n", i); > + ok(strcmp(buffer, dll_directories[i]) == 0, "i=%d, Wrong path returned: '%s'\n", i, buffer); You can do all these with one memcmp call. > > + ok(buffer[length + 1] == 'A', "i=%d, Buffer overflow\n", i); > + ok(buffer[ret] == 0, "i=%d, Wrong length or not null terminated\n", i); > + for (j = 0; buffer[j]; j++) > + if (buffer[j] != dll_directories[i][j]) > + { > + ok(0, "i=%d, Wrong path returned: %s\n", i, wine_dbgstr_w(buffer)); > + break; > + } Same for this. > + ok(buffer[0] == 0 || /* XP, 2003 */ > + buffer[0] == 'A', "i=%d, Buffer overflow\n", i); Please mark bad case with broke() to check for correct Wine behavior. Also please combine A & W tests. They do mostly the same things. Vitaliy.

2 1

Re: [1/2] kernel32/tests: add tests for GetDllDirectoryA
by Vincent Povirk Nov. 6, 2011

Nov. 6, 2011

I don't think you can rely on C:\Windows existing. On Sun, Nov 6, 2011 at 10:14 AM, Thomas Faber <thfabba(a)gmx.de> wrote: > > > >

3 2

Re: [2/2] mscoree: Implement ICorDebug CreateProcess
by Vincent Povirk Nov. 5, 2011

Nov. 5, 2011

I'm curious why you've chosen to work on this. Is there a program relying on this, or do you have some .NET debugging tools you'd like to use? Or are you thinking we'd implement our own debugging tool as well (perhaps extending winedbg)? Better debugging tools for wine/mono would definitely be nice, but there are a lot of things we need, and this is not the first one I'd pick. The current state of the art in Mono debugging is the soft debugger. >From what I've heard, all other debugger technologies in Mono have been deprecated. http://www.mono-project.com/Mono:Runtime:Documentation:SoftDebugger They have documentation on the wire protocol, which is probably what we'd end up using because .NET libraries are inconvenient to use. >From what I can tell, the soft debugger needs to be configured to listen for TCP connections on a particular port. Ideally, we would want to modify it by adding a new "transport" using something like a named pipe server named based on the process id (it looks straightforward to do so, but we'd have to modify the mono runtime). Otherwise, I'm not sure how we'd identify the socket server for the process we want, and having mono run a TCP server all the time seems like a bad idea. It may also be possible to configure mono to use the soft debugger in the "normal" way and attach to it with a Linux MonoDevelop, if you want a quicker solution. It seems like it's designed to remotely debug any mono process on any platform. If you figure out how to do this, wiki documentation would be appreciated.

2 1

Warning report for wine-1.3.32
by Jerome Leclanche Nov. 4, 2011

Nov. 4, 2011

warning: variable ‘_qzz_res’ set but not used [-Wunused-but-set-variable] That's valgrind stuff. Apparently I might need a valgrind update or something, I'm not 100% sure what's going on. A few more can be fixed with FIXME()s instead of comments. J. Leclanche

1 0

Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
by Jacek Caban Nov. 4, 2011

Nov. 4, 2011

Hi Nikolay, On 11/04/11 16:46, Nikolay Sivov wrote: > + if(This->data->vtbl&& This->data->vtbl->invoke) { > + hres = This->data->vtbl->invoke(This->outer, id, lcid, wFlags, pdp, pvarRes, pei); > + if (hres != E_NOTIMPL) return hres; > + } Using E_NOTIMPL for special meaning here seems wrong to me. DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move custom invoke implementation to be the last choice, after dynamic and typelib-based values, then you could simply return whatever invoke returns. Jacek

3 3

Re: [PATCH] userenv: GetUserProfileDirectoryW should fail with ERROR_INVALID_HANDLE if handle is NULL.
by Alexandre Julliard Nov. 4, 2011

Nov. 4, 2011

Christian Inci <chris.pcguy.inci(a)gmail.com> writes: > @@ -149,6 +149,12 @@ BOOL WINAPI GetUserProfileDirectoryW( HANDLE hToken, LPWSTR lpProfileDir, > > TRACE( "%p %p %p\n", hToken, lpProfileDir, lpcchSize ); > > + if (!hToken) > + { > + SetLastError( ERROR_INVALID_HANDLE ); > + return FALSE; > + } There's no reason to treat a 0 handle differently. Please stop adding such special cases just to satisfy the tests. Parameter checking needs to fall out of the implementation. -- Alexandre Julliard julliard(a)winehq.org

1 0

winedevice taking up 100% after wine cmd
by Hin-Tak Leung Nov. 4, 2011

Nov. 4, 2011

I just had a rather odd incident earlier today when I just launched "wine cmd", and saw that my process monitor max-out to 100% - and it continued, until I finished what I intended to do and exited cmd, minutes later. I wasn't doing anything else and no typing anything in the cmd console either, so that was curious. It was winedevice taking up 100%. I tried wine cmd later but couldn't get that odd behavior any more. But is there any reason why winedevice should go into a spin? This is fedora 15 x86_64 running 32-bit wine I built myself.

2 1

Re: [PATCH] shell32: IShellDispatch_NameSpace: Special-folder argument shouldn't be negative.
by Alexander Morozov Nov. 3, 2011

Nov. 3, 2011

-1 in this test is only a sample of a bad constant. Do you sure that S_OK should be returned for any positive argument?

3 2

Re: winealsa: Don't set ALSA's period time.
by Andrew Eikum Nov. 3, 2011

Nov. 3, 2011

On Thu, Nov 03, 2011 at 09:41:46AM +0100, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > perhaps I shouldn't send this one day before release... > > I argue that Wine has no business setting ALSA's period size, > esp. not to a completely random value like duration/10. > Better leave it complete freedom, as confirmed in > http://mailman.alsa-project.org/pipermail/alsa-devel/2011-August/042837.html > > What I think may be interesting is set min and/or max of the *buffer* time I completely agree, and have similar patches sitting in Bugs 28723 (don't set period time) and 28282 (request ALSA buffer time near requested MMDevice buffer time; needs more thought), although I was waiting for feedback from users before submitting. I have no problem with this patch getting in today, though it is late in the cycle, yeah ;) Andrew

1 0

Re: [2/3] ntdll: Use PAGE_READWRITE access when resolving DLL imports.
by Alexandre Julliard Nov. 3, 2011

Nov. 3, 2011

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 5ee7d0a..314813f 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -563,7 +563,7 @@ static WINE_MODREF *import_dll( HMODULE module, const IMAGE_IMPORT_DESCRIPTOR *d > protect_base = thunk_list; > protect_size *= sizeof(*thunk_list); > NtProtectVirtualMemory( NtCurrentProcess(), &protect_base, > - &protect_size, PAGE_WRITECOPY, &protect_old ); > + &protect_size, PAGE_READWRITE, &protect_old ); Restoring the permissions is not going to work if it was already writable. -- Alexandre Julliard julliard(a)winehq.org

2 4

RFC: wined3d: Implementing depth/stencil buffer locking
by Octavian Voicu Nov. 3, 2011

Nov. 3, 2011

Hi, Here is a first shot at implementing depth/stencil buffer locking in wined3d. Currently depth/stencil buffer locations are onscreen and offscreen, with transitions between the two states done in load_ds_location. I added another location, sysmem, and implemented transitions from offscreen to sysmem and from sysmem to offscreen. If buffer is onscreen, it will be moved offscreen first, then to sysmem. Some issues with this implementation: 1) make dsurface.ok in ddraw/tests crashes in context_acquire (wined3d/context.c:2456) called from surface_load_location (wined3d/surface.c:6323), I'm guessing in because there is no swapchain. How can I prevent this crash and still get a context? Loading from offscreen to sysmem shouldn't require a swapchain. 2) When running my test app [1] I also get this error: err:d3d_surface:surface_load_ds_location >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexSubImage2D @ ../../../../wine/dlls/wined3d/surface.c / 5877 3) There are other issues with my test app (looks like it's related to textures), so can't be sure if locking works correctly. There is an improvement over the unpatched version, but can't be sure until the other issue is resolved. Game uses pre-rendered backgrounds and probably loads the Z-buffer by locking the surface, so it can render 3D characters correctly over the pre-rendered backgrounds. It happens in the "if (surface->flags & SFLAG_DS_SYSMEM)" branch of the surface_load_ds_location function. Uploading happens on each frame, this error only happens for the first upload. I'm quite new to wined3d code so I might have missed some obvious things. Any comments and suggestions are welcome. Thanks. Octavian [1] The demo of The Longest Journey, available for download here (to reproduce, click on the Begin Journey, press ESC to skip intro movies; notice how rendered characters look): http://games.softpedia.com/get/Games-Demo/The-Longest-Journey-161-Demo.shtml

3 3