- wine-devel - winehq.org

Re: Winelib and C++ static initialization
by Luke Dunstan 27 Aug '15

27 Aug '15

On Thu, 27 Aug 2015 at 00:44 Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > You dropped the wine-devel CC. Was that intentional? There are people > who have more clues about winelib than I do. > No, it was accidental, sorry. > > >> I found that OutputDebugStringA doesn't write anything here, > >> even if successful. I replaced it with printf calls to get > >> actual output. > > > > OK, but why exactly is this necessary? This is just an artificial > > example to demonstrate the general problem. > I looked into the source code of OutputDebugStringA, but I couldn't find > an obvious answer. It certainly does a lot more than just write a string > to STDOUT. I didn't really understand what it was doing. > Yes, it sends the message to the attached debugger if any, not to stdout. On Windows or Wine you can run SysInternals DbgView.exe to see it. It's just an example though, and many other APIs also crash when called from initialisers. >> Though it's not quite working here either: > > > > Any ideas why, or how it could be fixed? > Sorry, no idea :-( . > > > Yes. My hope was that Winelib could be used to help port a legacy > > Windows CE 4.x application to Linux (ARM, though I am testing on > > x86 right now). Initially I could try compiling on Windows and > > running it on Linux, but the real goal would be to port the > > application in stages, so changing a few modules at a time to use > > Linux APIs while leaving some parts using the Win32 (and MFC) APIs. > > Eventually there would be no need for Winelib but I'd expect that > > porting all of the code at once would resulting in a lot more > > debugging effort because changes would not be localised. > Hmm yeah, that sounds like a task where you need winelib. Unfortunately > winelib isn't something that gets used a lot, and even less so with C++. > > Also keep in mind that Wine doesn't target Windows CE applications, so > you'll have to invest a lot of time into bridging Windows CE <-> Win32 > differences. > Yes I understand, but fortunately most of the application also runs on normal Win32. You'll also have to compile MFC with Winelib to target ARM. It should > be possible to compile MFC (or at least parts of it) with winelib, but > I don't expect this to be easy either. > That's true, and that was actually the first thing I tried to do. I tried both static and dynamic libraries but it crashes before it gets to WinMain(), hence my question. GDB can trap the crash but the stack trace gives no function names or other useful information. (gdb) bt #0 0x00000000 in ?? () #1 0x7ec4b7c0 in ?? () #2 0x7ec4b77e in ?? () #3 0x7ec4b79e in ?? () #4 0xb7febd77 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Winedbg cannot even get that far. But I will try 1.7... Luke

2 1

Re: [2/4] comdlg32: Implement open dropdown menu.
by Alexandre Julliard 27 Aug '15

27 Aug '15

Vincent Povirk <madewokherd(a)gmail.com> writes: > This implements the open dropdown button as a separate button, rather > than using BS_SPLITBUTTON, which is unimplemented in Wine. This adds > some complexity, but I don't think it changes things enough to get in > the way of other work on this component. > > I have an implementation using BS_SPLITBUTTON that works on Windows, > and could theoretically be used once we have support for window class > redirection and BS_SPLITBUTTON. I will send that to wine-devel so you > can see how much complexity this approach adds, and what the correct > approach will look like. It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M comdlg32.dll -p comdlg32_test.exe.so itemdlg && touch itemdlg.ok itemdlg.c:2088: Test succeeded inside todo block: got 0x00000000. itemdlg.c:2089: Test succeeded inside todo block: got 0. Makefile:270: recipe for target 'itemdlg.ok' failed make: *** [itemdlg.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] dxgi/tests: Add a Test presentation parameter combinations.
by Marvin 26 Aug '15

26 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16348 Your paranoid android. === wvistau64 (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 24. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 25. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 27. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 28. device.c:1173: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 29. device.c:1173: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 40. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 41. device.c:1173: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42. === w2008s64 (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42. === w7u (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 24. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 25. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 27. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 28. device.c:1173: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 29. device.c:1173: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 35. device.c:1173: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 36. device.c:1173: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 40. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 41. device.c:1173: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 42. device.c:1173: Test failed: Got usage 160, expected 60, test 42, buffer 15. === w8 (32 bit device) === device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 24. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 25. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 27. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 28. device.c:1173: Test failed: Got usage 160, expected 60, test 28, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 29. device.c:1173: Test failed: Got usage 160, expected 60, test 29, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 35. device.c:1173: Test failed: Got usage 160, expected 60, test 35, buffer 1. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 36. device.c:1173: Test failed: Got usage 160, expected 60, test 36, buffer 2. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 40. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 41. device.c:1173: Test failed: Got usage 160, expected 60, test 41, buffer 15. device.c:1128: Test failed: Got unexpected hr 0x87a0001, test 42. device.c:1173: Test failed: Got usage 160, expected 60, test 42, buffer 15. === wvistau64 (64 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42. === w2008s64 (64 bit device) === device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 12. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 13. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 19. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 35. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 36. device.c:1128: Test failed: Got unexpected hr 0x887a0001, test 42.

1 0

Re: [PATCH 4/5] d3d8/tests: Test presentation parameter combinations.
by Marvin 26 Aug '15

26 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16347 Your paranoid android. === w8 (32 bit device) === device.c:1216: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1261: Test failed: Reset failed, hr 0x88760868. device.c:1263: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1267: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1274: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1275: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1276: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1277: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1278: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1279: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1284: Test failed: Screen width is 640, expected 800. device.c:1285: Test failed: Screen height is 480, expected 600. device.c:1291: Test failed: Back buffer width is 640, expected 800. device.c:1293: Test failed: Back buffer height is 480, expected 600. device.c:1323: Test failed: Screen width is 640, expected 1024. device.c:1324: Test failed: Screen height is 480, expected 768. device.c:2571: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2576: Test failed: The focus window is active. device.c:2584: Test failed: Got unexpected hr 0x88760869. device.c:2590: Test failed: Got unexpect screen size 800x600. device.c:2605: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2614: Test failed: Got unexpect screen size 800x600. device.c:2627: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2635: Test failed: Got unexpect width 640. device.c:2636: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 5/5] dxgi/tests: Add a Test presentation parameter combinations.
by Henri Verbeet 26 Aug '15

26 Aug '15

On 26 August 2015 at 21:50, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + wc.lpfnWndProc = DefWindowProcA; > + wc.lpszClassName = "dxgi_test_wc"; > + RegisterClassA(&wc); Do we really need that?

1 0

Winelib and C++ static initialization
by Luke Dunstan 26 Aug '15

26 Aug '15

Hi, I am new to Winelib and I have crashes with very basic C++ code. Consider the following code: #include <windows.h> struct MyInit { MyInit() { OutputDebugStringA("Init ctor\n"); } }; MyInit InitObj; extern "C" int CALLBACK WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { OutputDebugStringA("WinMain()\n"); return 0; } If I compile it on Ubuntu 32-bit with wine-1.6.2 with: wineg++ -c -mno-cygwin -o hello.o hello.cpp wineg++ -mwindows -mno-cygwin -o hellocpp.exe hello.o The result is: $ ./hellocpp.exe Segmentation fault (core dumped) On Windows this program obviously outputs "Init ctor\n" followed by "WinMain()\n", as viewed in DbgView. Removing the call to OutputDebugStringA from the static constructor prevents the crash in Winelib. How do I get C++ static initialization to work properly in Winelib? Thanks, Luke

2 1

Re: [1/2] msi: Don't add the same environment string more than once.
by Marvin 26 Aug '15

26 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16331 Your paranoid android. === w7u (32 bit action) === The test timed out === w8 (32 bit action) === The test timed out === wvistau64 (64 bit action) === The test timed out

1 0

Re: [PATCH 3/3] kernel32/tests: Add tests for Invariant
by Alexandre Julliard 26 Aug '15

26 Aug '15

Daniel Lehman <dlehman(a)esri.com> writes: > + { X(LOCALE_SNATIVEDIGITS), "0123456789" }, > + { X(LOCALE_SCURRENCY), "" }, Please avoid non-ASCII characters in source code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] reg: simplify root key search
by Stefan Dösinger 26 Aug '15

26 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Something is still wrong with the submission: $ git am ~/Desktop/\[PATCH\ 1_2\]\ reg\:\ simplify\ root\ key\ search\ -\ Michel\ Zou\ \<xantares09\(a)hotmail.com\>\ -\ 2015-08-25\ 2150.eml Applying: reg: simplify root key search /home/stefan/src/wine/.git/rebase-apply/patch:33: trailing whitespace. static const WCHAR short_hklm[] = {'H','K','L','M',0}; /home/stefan/src/wine/.git/rebase-apply/patch:34: trailing whitespace. static const WCHAR short_hkcu[] = {'H','K','C','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:35: trailing whitespace. static const WCHAR short_hkcr[] = {'H','K','C','R',0}; /home/stefan/src/wine/.git/rebase-apply/patch:36: trailing whitespace. static const WCHAR short_hku[] = {'H','K','U',0}; /home/stefan/src/wine/.git/rebase-apply/patch:37: trailing whitespace. static const WCHAR short_hkcc[] = {'H','K','C','C',0}; error: patch failed: programs/reg/reg.c:22 error: programs/reg/reg.c: patch does not apply Patch failed at 0001 reg: simplify root key search It looks like the patch has Windows line endings, but AFAIK that shouldn't break git am. I strongly recommend to use git send-email to make git send the patches directly to the SMTP server instead of going through text files and MUAs. That avoids issues like that pretty reliably. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3as6AAoJEN0/YqbEcdMwEfYP/1ibDcxPQ9VF6tKyfQKVeuVW cC1rFbAbbXdWPxALIiJa/qEz/3DKV4j1tIvU68GA6SE5gh4XLsVfH1Li66PX3KQy 6ytqG263r677dDxjTPIJHOTsl4ncFvCVHkVz3cn9zBLM3G6V8BLeL4rCVFq1Wso0 pNS5abhVQNzDTY+gLG2oh9XqtLuI2oAmF6YO/VklVKF8pVwN50RX7FXJuGwlhScn +6GvzOLrkirbTL1jKW+v+4BZ22CjzGRZPVMGPlmgGIdyexVjoG8nAlfvLoH6+Qds 6WQatGcHFNnJjE275Snl9EjnspfedMLcYWspbbC7IsWDvdMrt8LawUGDOyZsqxzC yUYnMHNaotC7K0FpqHG+OKTRgrJy8dX10xSkTAhj6FtLj49BFhNb7hWsqc3T//g6 GlcmCYxWXNmseOt5t5E/v4eb9XowBab9Mv4zNU8sFZWlfUvbv3vMnhfzjslZnHNY h+yBR9OQZiKInPsHxW3wsuIIt0xBjPE1RHUac9vfPc031PvjqYulQ2PfQkUyljo2 vHwqCU6i9S8Y2INd7PwOggoHqE9SKMFvaRg9Tf5vOiG9YQHtaTWHj+xgQsb5DRxd QWV+uK0gZW2UX0ozxzrCK2Kd5mEhTRd/dVZK75/ALoprf2r7aqU7gS+4aQYActlL LIk5K82tvISRR7QdN0KN =cTjQ -----END PGP SIGNATURE-----

2 1

Re: [PATCH v2 2/2] ucrtbase: Hook up some functions with new names to existing implementations
by Alexandre Julliard 26 Aug '15

26 Aug '15

Martin Storsjo <martin(a)martin.st> writes: > These are some functions that on a first glance seem to have a > matching signature even though the exact symbol name isn't the > same as in msvcr120. It would be better to create a separate function, unless there is strong evidence that they are doing the exact same thing. For example, I expect that there's a reason for having both malloc and malloc_base; mapping them to the same function would make any difference hard to spot. -- Alexandre Julliard julliard(a)winehq.org

2 2

FW: [PATCH 2/2] kernel32: add Invariant string table wrc: add support for LANG_INVARIANT
by Daniel Lehman 25 Aug '15

25 Aug '15

-----Original Message----- From: wine-patches [mailto:wine-patches-bounces@winehq.org] On Behalf Of Daniel Lehman Sent: Monday, August 24, 2015 12:27 PM To: 'wine-patches(a)winehq.org' Subject: [PATCH 2/2] kernel32: add Invariant string table wrc: add support for LANG_INVARIANT I noticed this was marked as "Superseded". What is it superseded by? https://source.winehq.org/patches/data/113923 (I also noticed the subject got messed up, so I can resubmit if needed) thanks daniel

2 1

Re: user32: Fix error handling in {Begin,End,}DeferWindowPos() to match Windows behavior (resend)
by Sebastian Lackner 25 Aug '15

25 Aug '15

I also think moving the tests to an existing test file would be better, but here a few additional comments: On 25.08.2015 15:08, Rodrigo Rivas wrote: > diff --git a/dlls/user32/tests/Makefile.in b/dlls/user32/tests/Makefile.in > index 7149dc8..982b0fe 100644 > --- a/dlls/user32/tests/Makefile.in > +++ b/dlls/user32/tests/Makefile.in > @@ -9,6 +9,7 @@ C_SRCS = \ > cursoricon.c \ > dce.c \ > dde.c \ > + defer.c \ > dialog.c \ > edit.c \ > generated.c \ > diff --git a/dlls/user32/tests/defer.c b/dlls/user32/tests/defer.c > new file mode 100644 > index 0000000..eb63384 > --- /dev/null > +++ b/dlls/user32/tests/defer.c > @@ -0,0 +1,168 @@ > +/* > + * Unit tests for DeferWindowPos > + * > + * Copyright 2015 Rodrigo Rivas Costa > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "windows.h" > + > +#include "wine/test.h" > + > + > +#define WIDTH_CHILDREN 50 > +#define NCHILDREN 3 > +#define IDX_FAIL 1 > + > +static HINSTANCE g_hInstance; This is not a DLL, so theoretically no need to use a static variable for that. The overhead of calling GetModuleHandle multiple times should be very small. > +static HWND hChildren[NCHILDREN]; > + > +static void ExpectY(HWND hwnd, int y) > +{ > + RECT r; > + POINT p; > + GetWindowRect(hwnd, &r); > + p.x = r.left; > + p.y = r.top; > + MapWindowPoints(NULL, GetParent(hwnd), &p, 1); > + ok(p.y == y, "Window has not been properly moved: %d != %d\n", (int)p.y, y); I didn't test it, but there should be no need to explicitly cast here. > +} Such a helper function will make it complicated to track down test failures. In this case the code doesn't look too long, so you could directly duplicate it into the individual test functions. The alternative would be to pass the line number to the function, and then use ok_(...) instead. You can take a look at existing tests how to do that. > + > +static void TestDeferWindowPos(int posY) You could split each test function into a separate patch (failing tests marked with "todo_wine"), and then send the fix as a forth patch at the end. It is not strictly necessary, but it would probably be easier for reviewing. > +{ > + int i; > + BOOL res; > + HDWP hdwp; > + > + hdwp = BeginDeferWindowPos(1); > + ok(hdwp != NULL, "BeginDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + HWND h = hChildren[i]; > + hdwp = DeferWindowPos(hdwp, h, NULL, i*WIDTH_CHILDREN, posY, 0, 0, SWP_NOZORDER|SWP_NOSIZE|SWP_NOACTIVATE); > + ok(hdwp != NULL, "DeferWindowPos failed\n"); > + } > + res = EndDeferWindowPos(hdwp); > + ok(res, "EndDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + ExpectY(hChildren[i], posY); > +} > + > +static void TestBogusDeferWindowPos(int posY) > +{ > + int i; > + BOOL res; > + HDWP hdwp; > + > + hdwp = BeginDeferWindowPos(1); > + ok(hdwp != NULL, "BeginDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + HDWP hnext; > + HWND h = hChildren[i]; > + if (i==IDX_FAIL) The style (missing spaces inbetween) is a bit inconsistent here, and also at a couple of places below. > + h = (HWND)0; //Insert an error. This is not a valid HWND. C++ Style comments are not allowed in Wine source. Also, you can use NULL instead of casting 0 to a HWND. > + hnext = DeferWindowPos(hdwp, h, NULL, i*WIDTH_CHILDREN, posY, 0, 0, SWP_NOZORDER|SWP_NOSIZE|SWP_NOACTIVATE); > + if (i==IDX_FAIL) > + { > + DWORD err = GetLastError(); > + ok(hnext == NULL, "DeferWindowPos accepted a bogus HWND\n"); > + ok(err == ERROR_INVALID_WINDOW_HANDLE, "Bogus HWND should return ERROR_INVALID_WINDOW_HANDLE, got %d\n", (int)err); Also no need to explicitly cast here. > + } > + else > + { > + ok(hnext != NULL, "DeferWindowPos failed\n"); > + hdwp = hnext; > + } > + } > + res = EndDeferWindowPos(hdwp); > + ok(res, "EndDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + if (i != IDX_FAIL) > + ExpectY(hChildren[i], posY); > + } > +} > + > +static void TestDestroyDeferWindowPos(int posY) > +{ > + int i; > + BOOL res; > + HDWP hdwp; > + > + hdwp = BeginDeferWindowPos(1); > + ok(hdwp != NULL, "BeginDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + HWND h = hChildren[i]; > + hdwp = DeferWindowPos(hdwp, h, NULL, i*WIDTH_CHILDREN, posY, 0, 0, SWP_NOZORDER|SWP_NOSIZE|SWP_NOACTIVATE); > + ok(hdwp != NULL, "DeferWindowPos failed\n"); > + /* Destroying a window after DeferWindowPos but before EndDeferWindowPos should be silently ignored */ > + if (i == IDX_FAIL) > + DestroyWindow(h); > + } > + res = EndDeferWindowPos(hdwp); > + ok(res, "EndDeferWindowPos failed\n"); > + for (i = 0; i < NCHILDREN; ++i) > + { > + if (i != IDX_FAIL) > + ExpectY(hChildren[i], posY); > + } > +} > + > +static LRESULT CALLBACK TestWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) > +{ > + switch (msg) > + { > + case WM_CREATE: > + { > + int i; > + int posY = 0; > + for (i=0; i < NCHILDREN; ++i) > + { > + hChildren[i] = CreateWindowExA(0, "Button", NULL, WS_CHILD|WS_VISIBLE, > + i*WIDTH_CHILDREN, posY, WIDTH_CHILDREN, WIDTH_CHILDREN, > + hWnd, NULL, g_hInstance, NULL); > + } > + > + TestDeferWindowPos(++posY); > + TestBogusDeferWindowPos(++posY); > + TestDestroyDeferWindowPos(++posY); If possible you should move those calls outside of the TestWndProc. > + } > + break; > + } > + return DefWindowProcA(hWnd, msg, wParam, lParam); > +} > + > +START_TEST(defer) > +{ > + WNDCLASSEXA cls; > + ATOM acls; > + > + g_hInstance = GetModuleHandleA(NULL); > + memset(&cls, 0, sizeof(cls)); > + cls.cbSize = sizeof(cls); > + cls.lpfnWndProc = TestWndProc; > + cls.hInstance = g_hInstance; > + cls.lpszClassName = "TestWnd"; > + > + acls = RegisterClassExA(&cls); > + > + HWND hWnd = CreateWindowExA(0, MAKEINTRESOURCEA(acls), "TestWnd", WS_OVERLAPPEDWINDOW, You can't declare a variable in the middle of a function (should give you a warning while compiling). > + CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, > + NULL, NULL, g_hInstance, NULL); > + ok(hWnd != NULL, "CreateWindowEx failed\n"); > +} > diff --git a/dlls/user32/winpos.c b/dlls/user32/winpos.c > index f92a3dc..7cb3a4f 100644 > --- a/dlls/user32/winpos.c > +++ b/dlls/user32/winpos.c > @@ -2349,6 +2349,11 @@ HDWP WINAPI DeferWindowPos( HDWP hdwp, HWND hwnd, HWND hwndAfter, > > hwnd = WIN_GetFullHandle( hwnd ); > if (is_desktop_window( hwnd )) return 0; > + if (!IsWindow( hwnd )) > + { > + SetLastError( ERROR_INVALID_WINDOW_HANDLE ); > + return 0; > + } > > if (!(pDWP = get_user_handle_ptr( hdwp, USER_DWP ))) return 0; > if (pDWP == OBJ_OTHER_PROCESS) > @@ -2418,7 +2423,6 @@ BOOL WINAPI EndDeferWindowPos( HDWP hdwp ) > { > DWP *pDWP; > WINDOWPOS *winpos; > - BOOL res = TRUE; > int i; > > TRACE("%p\n", hdwp); > @@ -2430,20 +2434,20 @@ BOOL WINAPI EndDeferWindowPos( HDWP hdwp ) > return FALSE; > } > > - for (i = 0, winpos = pDWP->winPos; res && i < pDWP->actualCount; i++, winpos++) > + for (i = 0, winpos = pDWP->winPos; i < pDWP->actualCount; i++, winpos++) > { > TRACE("hwnd %p, after %p, %d,%d (%dx%d), flags %08x\n", > winpos->hwnd, winpos->hwndInsertAfter, winpos->x, winpos->y, > winpos->cx, winpos->cy, winpos->flags); > > if (WIN_IsCurrentThread( winpos->hwnd )) > - res = USER_SetWindowPos( winpos ); > + USER_SetWindowPos( winpos ); > else > - res = SendMessageW( winpos->hwnd, WM_WINE_SETWINDOWPOS, 0, (LPARAM)winpos ); > + SendMessageW( winpos->hwnd, WM_WINE_SETWINDOWPOS, 0, (LPARAM)winpos ); > } > HeapFree( GetProcessHeap(), 0, pDWP->winPos ); > HeapFree( GetProcessHeap(), 0, pDWP ); > - return res; > + return TRUE; > }

2 1

comdlg32: itemdlg split button implementation
by Vincent Povirk 25 Aug '15

25 Aug '15

These patches apply on top of my series that implements the open dropdown menu in the common item dialog, based on BS_SPLITBUTTON. They work in my testing on Windows, but they do not yet work on Wine because BS_SPLITBUTTON is unimplemented. This is mostly to show how to do this properly (and hopefully make the case that the deficiency won't hinder development in the mean time), but if I'm not around when BS_SPLITBUTTON is implemented, I consider this a contribution to Wine under the LGPL just like anything I send to wine-patches. I'm interested in feedback in terms of whether this is as correct and clean as it could be, but it's sort of academic until Wine has the necessary architecture to support it.

1 0

Re: [3/3] ddraw: Implement DDENUMSURFACES_CANBECREATED flag in ddraw7_EnumSurfaces.
by Stefan Dösinger 25 Aug '15

25 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-25 um 11:17 schrieb Sebastian Lackner: > + if (match_flags != DDENUMSURFACES_MATCH) > + return DDERR_INVALIDPARAMS; Personally I prefer if the code writes WARN messages if it returns an error. > + memcpy(&testdesc, DDSD, sizeof(testdesc)); Technically you should honor DDSD.dwSize. Most likely the correct behavior is to return an error if the size doesn't match sizeof(DDSURFACEDESC) in IDirectDraw and IDirectDraw2 or sizeof(DDSURFACEDESC2) in IDirectDraw4 and 7. > + if (!(testdesc.dwFlags & DDSD_WIDTH)) > + { > + testdesc.dwFlags |= DDSD_WIDTH; > + testdesc.dwWidth = 512; > + } > + if (!(testdesc.dwFlags & DDSD_HEIGHT)) > + { > + testdesc.dwFlags |= DDSD_HEIGHT; > + testdesc.dwHeight = 512; > + } Does it inject any caps or pixelformat if they aren't set? Does it fall back to DDSCAPS_SYSTEMMEMORY if you don't request a location and whatever pixel format or size you request isn't supported? > + hr = IDirectDraw7_CreateSurface(iface, &testdesc, &surface, NULL); > + if (SUCCEEDED(hr)) > { > ... > + surf = unsafe_impl_from_IDirectDrawSurface7(surface); > + Callback(NULL, &surf->surface_desc, Context); > + IDirectDrawSurface7_Release(surface); > } > + else > + ERR("Failed to create surface, hr %#x.\n", hr); I don't think that's an ERR. It may be a legitimate case where the surface requested by the application isn't supported. A question that should be answered by the tests is if EnumSurfaces just enumerates 0 descs with success, or if it returns a failure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3NFlAAoJEN0/YqbEcdMwRm0P/jajJLkLdEd4gjVCm/siaccO UmNvomXKOhkrh9kLI7LWZQ2B4fvuc5pma0K6klngRhaoa3+ZIAC59q9eTGzQieWB ibE9LXRU9FHFNThjprkGyHZtYu0MHRTTrYfgsRtOVhpfBTkxPYtKPsxJqEDqi9ug xyRNzuRxz+bsG+4DFocwKXHQtbq/dXndHC5i2VyWh3uUX7HI1QJ1klIbaNf8kBGn w+Hm09qzWU0uudNKNRUTqvulUgd/OPn133h1/IkB27OhdDe0jexVl5hFc+7fyQFG dZ6kdQEimJ1jz9eRIItfOWLYvOKC0J3x7H8kQnQeoeDNJVnoK0rYS5mAz+p4gWLY 3eeuhKeq2iQ1P6851x9KnywZ/wEwSabg6ZqgCrQUCVdIVQNb+s6b5e5BEip/C3BG oSXgO/7ONj682c3S0GoiYFx6eMUPPGS7xbMqhHDJqfQneUEGUXU8VGgT+snTxsS/ JJ0NzQOlmwZm0wx7zCPwjs9173Vz25tCMuAm18CvkRLoXygZeUzU7PbfXE2qqO6j iNsfkUCP7rA+XhCV/vMFdzThI8j0YEDFPliZumQCJ5qN/Yz/6dhls+3J0IHMZexa iGjHFsTlI/yXc01+865tZZQaFEFZEJ0rfE7RChMFsY9LTGe2bzc6P49gdjuhm1em zLhWBw58Jqx2LoY/wAFR =1rMk -----END PGP SIGNATURE-----

1 0

Re: [1/3] ddraw/tests: Add more tests for IDirectDraw7::EnumSurfaces.
by Stefan Dösinger 25 Aug '15

25 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-08-25 um 11:15 schrieb Sebastian Lackner: > dlls/ddraw/ddraw.c | 3 > dlls/ddraw/tests/d3d.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++--- Please add the test to ddraw{1-7}.c, testing each interface version. This is the preferred place for new tests. Feel free to remove the lone EnumSurfaces test from CreateDirect3D. Arguably it's poorly placed there because CreateDirect3D is more of a helper function than a real test function. > +typedef struct > +{ > + int found; > + int surfaces; > +} EnumSurfaceTest; You shouldn't need the typedef, and the counters can be unsigned. In ddraw*.c enum_surfaces_test matches the naming convention. > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 256; > + ddsd2.dwHeight = 256; The test will be more meaningful if there are more than 2 surfaces that can be enumerated, and if they have different sizes. > + count.found = count.surfaces = 0; > + rc = IDirectDraw7_EnumSurfaces(lpDD, DDENUMSURFACES_CANBECREATED | DDENUMSURFACES_MATCH, > + &ddsd, &count, SurfaceCounter); > + ok(rc == DD_OK, "Expected DD_OK, got %x\n", rc); > + todo_wine ok(count.found == 1, "Has %d surface descriptions, expected 1\n", count.found); > + ok(count.surfaces == 0, "Has %d surfaces, expected 0\n", count.surfaces); What does the enumerated surface description look like? Is it just your input description, or does ddraw set additional flags like DDSCAPS_OFFSCREENPLAIN? If it looks like it is your surface desc you can try to set some nonsense fields before the call, e.g. set lpSurface = (void *)0xdeadbeef without setting DDSD_LPSURFACE. If ddraw adds extra flags please check for them. If you call CreateSurface inside the callback with the enumerated desc, does it successfully create a surface? Another thing to test is DDSCAPS_PRIMARYSURFACE, both without an existing primary and without one that's already created. This should show if calling CreateSurface to try to create a test surface is the right solution. There are a few more things you could check to satisfy my curiosity, but I don't think we necessarily need this: In your implementation calling EnumSurfaces with DDENUMSURFACES_ALL | DDENUMSURFACES_DOESEXIST from the enumeration callback will find the temporary surface and you could e.g. AddRef it and keep it. I doubt this is the case with Microsoft's implementation, otherwise they could give you their test surface in the callback. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3M6jAAoJEN0/YqbEcdMw4BcP/Rc/D6f3d2KoEG9mqftIxsGO TaO7KAeclV2ctUUYCXQ9kuUamDblNtyFebhb6p/zr7i1I9dymiN1EMgpUs7DUU2Y IJB3QJVvG1csFporvAkqNm1ERN12YbNPcmCL7nSuT8/X0uP3c4Mcjr2MQphz6Ng5 CyZPp5fKah7xrQrfEqQ7FGTpuXPickkTm710JerjZr4UNP+LrW38WTMxgH3a/McW ucuvRF+D2qc/Ml+fbHMBrO0gUlmLCKWvyPAAM5LU9b4lpMSBvVM0avbDP1BfV68e W18pj3ZBjGsbPCIGQWV4YqyiEtdQgvJPYvmbLTwSWxfOn1hXDdqgzOX6xtuGw93G jVu7D8FZduLDwlG8k3KWWZVQKZ6Cd0RuaGUOztNXXkFIzyH57MWGaJOsAr7RVB1T 81JANe7pq4wcs6eA2yJo7vEoGqdR13waV13Em44aR7sp8hNZod05vlAlS//zViNU 0zkisY70ceaQNug22BlyFxdJ67mLHxNduseQ2oAZLQj3c/W2kpu9sAG09bJTaj3p FfgW1+oCq4bIt2lkdTewuPHcIylhvBc46EGpSmU6Tq4Rip4MmVZEsK8bFXQyZUrL Dn+oGMdOwTPIvv1bKIx36SXGqr3Q7wV4k8Ai10eHVjygWj1cnX5BSBH3zf2ZRSa5 A4YR+nFRZkEdr8rvO37C =jk68 -----END PGP SIGNATURE-----

1 0

Re: wevtapi: implement EvtClose()
by Nikolay Sivov 25 Aug '15

25 Aug '15

On 25.08.2015 21:20, Austin English wrote: > +BOOL WINAPI EvtClose(EVT_HANDLE handle) > +{ > + BOOL ret; > + > + TRACE("(%p)\n", handle); > + ret = HeapFree(GetProcessHeap(), 0, handle); > + return ret; > +} It makes no sense to free it like that.

1 0

Re: mscoree: Implement semi-stub for _CorValidateImage.
by Vincent Povirk 25 Aug '15

25 Aug '15

Why do we set the entry point to 0 on 64-bit and _CorDllMain or _CorExeMain on 32-bit?

2 1

Re: user32: Fix error handling in {Begin,End,}DeferWindowPos() to match Windows behavior (resend)
by Nikolay Sivov 25 Aug '15

25 Aug '15

On 25.08.2015 17:01, Rodrigo Rivas wrote: > [Sorry for the double post, I forgot to reply to the list] > > On Tue, Aug 25, 2015 at 3:35 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> On 25.08.2015 16:08, Rodrigo Rivas wrote: >>> >>> I sent this on July 15th, but it went through the cracks. Maybe the >>> mail text was not detailed enough, so I will try and explain it better >>> this time. >>> >>> The error behaviour of functions BeginDeferWindowPos(), >>> DeferWindowPos() and EndDeferWindowPos() in Wine is different than in >>> Windows. >>> >>> In Windows, when DeferWindowPos() is used with an invalid HWND, this >>> function fails, but the eventual EndDeferWindowPos() will succeed and >>> move all the other windows in the set. >>> In Wine, however, DeferWindowPos() does not check the HWND, so it >>> never fails. But then, it fails in EndDeferWindowPos(), moving only >>> the windows passed before the invalid HWND and leaving the windows >>> after the invalid HWND unmoved. >>> >>> The Windows behaviour is consistent in every version I tested (XP and 7). >>> >>> The attached patch makes the Wine error behaviour the same as the Windows >>> one. >>> It also considers the case where the HWND is valid when calling >>> DeferWindowPos() but is destroyed before calling EndDeferWindowPos(): >>> The error is simply ignored. >>> >>> It fixes bug #23187. >>> >>> --- >>> dlls/user32/tests/Makefile.in | 1 + >>> dlls/user32/tests/defer.c | 168 >>> ++++++++++++++++++++++++++++++++++++++++++ >>> dlls/user32/winpos.c | 14 ++-- >>> 3 files changed, 178 insertions(+), 5 deletions(-) >>> create mode 100644 dlls/user32/tests/defer.c >>> >> >> I don't think you need a new file for that, how about moving this to win.c? > > It may make sense in win.c. I assumed that user32/tests/win.c is > related to user32/win.c. And since the affected functions are in > user32/winpos.c... maybe I should have named it user32/tests/winpos.c? > But I don't have a strong preference > If you really want it, would you like me to do the merge and resend > the patch? Or is it not necessary? > We try to avoid adding new files for every new test, to keep number of files under reasonable limit. So yes, I think it's better to have that moved to win.c, and no, renaming it is not necessary. >> Regarding fix itself, it's probably better to split it to two - fix >> DeferWindowPos() in first + related tests, and End* one in the second. > > In this I disagree. Changing DeferWindowPos() without changing > EndDeferWindowPos() would make little sense, because the error > checking is moving from EDWP to DWP. > The special case of the window being destroyed between DWP and EDWP is > just a consequence of EDWP not having any error checking left. > You could have one patch that adds the check to DWP and another that > removes it from EDWP, but what's the point? The intermediate step will > not even pass the test case, it will fail at > TestDestroyDeferWindowPos(). > > So to fair you would have to split in: a) fix DWP + tess1+test2; b) > fix EDWP + test3. > Sure, that's what I meant, to have one fix + its tests in first patch, followed by second fix + its own tests. But let's see if someone else has anything to add to this, it might be okay to have it they way you did.

1 0

Re: user32: Fix error handling in {Begin,End,}DeferWindowPos() to match Windows behavior (resend)
by Nikolay Sivov 25 Aug '15

25 Aug '15

On 25.08.2015 16:08, Rodrigo Rivas wrote: > I sent this on July 15th, but it went through the cracks. Maybe the > mail text was not detailed enough, so I will try and explain it better > this time. > > The error behaviour of functions BeginDeferWindowPos(), > DeferWindowPos() and EndDeferWindowPos() in Wine is different than in > Windows. > > In Windows, when DeferWindowPos() is used with an invalid HWND, this > function fails, but the eventual EndDeferWindowPos() will succeed and > move all the other windows in the set. > In Wine, however, DeferWindowPos() does not check the HWND, so it > never fails. But then, it fails in EndDeferWindowPos(), moving only > the windows passed before the invalid HWND and leaving the windows > after the invalid HWND unmoved. > > The Windows behaviour is consistent in every version I tested (XP and 7). > > The attached patch makes the Wine error behaviour the same as the Windows one. > It also considers the case where the HWND is valid when calling > DeferWindowPos() but is destroyed before calling EndDeferWindowPos(): > The error is simply ignored. > > It fixes bug #23187. > > --- > dlls/user32/tests/Makefile.in | 1 + > dlls/user32/tests/defer.c | 168 ++++++++++++++++++++++++++++++++++++++++++ > dlls/user32/winpos.c | 14 ++-- > 3 files changed, 178 insertions(+), 5 deletions(-) > create mode 100644 dlls/user32/tests/defer.c > I don't think you need a new file for that, how about moving this to win.c? Regarding fix itself, it's probably better to split it to two - fix DeferWindowPos() in first + related tests, and End* one in the second.

1 0

Re: [PATCH 4/6] d3drm: Fix spelling mistake in Set/GetDecalTransparentColor macros.
by Stefan Dösinger 25 Aug '15

25 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I noticed that Microsoft's headers don't define these C interface macros at all. Technically we should remove them from our headers (and write obj->lpVtbl->Method(obj, param1, param2) in the code). However, given that it's quite unlikely that anyone wants to compile a d3drm application against our headers I don't think this needs to be a priorit y. This also means our tests (and implementation) won't compile against Microsoft's headers, but this is also something that is nice to have but not generally supported (e.g. Microsoft's d3d9ex C interfaces are broken, so our d3d9ex tests only compile with our header). Stefan Am 2015-08-24 um 15:58 schrieb Aaryaman Vasishta: > --- include/d3drmobj.h | 12 ++++++------ 1 file changed, 6 > insertions(+), 6 deletions(-) > > diff --git a/include/d3drmobj.h b/include/d3drmobj.h index > 942c69a..28340fb 100644 --- a/include/d3drmobj.h +++ > b/include/d3drmobj.h @@ -3284,7 +3284,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture, IDirect3DRMVisual) #define > IDirect3DRMTexture_SetDecalOrigin(p,a,b) (p)->SetDecalOrigin(a,b) > #define IDirect3DRMTexture_SetDecalScale(p,a) (p)->SetDecalScale(a) > #define IDirect3DRMTexture_SetDecalTransparency(p,a) > (p)->SetDecalTransparency(a) -#define > IDirect3DRMTexture_SetDecalTransparencyColor(p,a) > (p)->SetDecalTransparentColor(a) +#define > IDirect3DRMTexture_SetDecalTransparentColor(p,a) > (p)->SetDecalTransparentColor(a) #define > IDirect3DRMTexture_GetDecalSize(p,a,b) (p)->GetDecalSize(a,b) > #define IDirect3DRMTexture_GetDecalOrigin(p,a,b) > (p)->GetDecalOrigin(a,b) #define IDirect3DRMTexture_GetImage(p) > (p)->GetImage() @@ -3292,7 +3292,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture, IDirect3DRMVisual) #define > IDirect3DRMTexture_GetColors(p) (p)->GetColors() #define > IDirect3DRMTexture_GetDecalScale(p) (p)->GetDecalScale() #define > IDirect3DRMTexture_GetDecalTransparency(p) > (p)->GetDecalTransparency() -#define > IDirect3DRMTexture_GetDecalTransparencyColor(p) > (p)->GetDecalTransparencyColor() +#define > IDirect3DRMTexture_GetDecalTransparentColor(p) > (p)->GetDecalTransparentColor() #endif > > /********************************************************************* ******** > > > @@ -3404,7 +3404,7 @@ DECLARE_INTERFACE_(IDirect3DRMTexture2, IDirect3DRMTexture) > #define IDirect3DRMTexture2_SetDecalOrigin(p,a,b) > (p)->SetDecalOrigin(a,b) #define > IDirect3DRMTexture2_SetDecalScale(p,a) (p)->SetDecalScale(a) > #define IDirect3DRMTexture2_SetDecalTransparency(p,a) > (p)->SetDecalTransparency(a) -#define > IDirect3DRMTexture2_SetDecalTransparencyColor(p,a) > (p)->SetDecalTransparentColor(a) +#define > IDirect3DRMTexture2_SetDecalTransparentColor(p,a) > (p)->SetDecalTransparentColor(a) #define > IDirect3DRMTexture2_GetDecalSize(p,a,b) (p)->GetDecalSize(a,b) > #define IDirect3DRMTexture2_GetDecalOrigin(p,a,b) > (p)->GetDecalOrigin(a,b) #define IDirect3DRMTexture2_GetImage(p) > (p)->GetImage() @@ -3412,7 +3412,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture2, IDirect3DRMTexture) > #define IDirect3DRMTexture2_GetColors(p) (p)->GetColors() #define > IDirect3DRMTexture2_GetDecalScale(p) (p)->GetDecalScale() #define > IDirect3DRMTexture2_GetDecalTransparency(p) > (p)->GetDecalTransparency() -#define > IDirect3DRMTexture2_GetDecalTransparencyColor(p) > (p)->GetDecalTransparencyColor() +#define > IDirect3DRMTexture2_GetDecalTransparentColor(p) > (p)->GetDecalTransparentColor() /*** IDirect3DRMTexture2 methods > ***/ #define IDirect3DRMTexture2_InitFromImage(p,a) > (p)->InitFromImage(a) #define > IDirect3DRMTexture2_InitFromResource2(p,a,b,c) > (p)->InitFromResource2(a,b,c) @@ -3494,7 +3494,7 @@ > DECLARE_INTERFACE_(IDirect3DRMTexture3, IDirect3DRMVisual) #define > IDirect3DRMTexture3_SetDecalOrigin(p,a,b) > (p)->lpVtbl->SetDecalOrigin(p,a,b) #define > IDirect3DRMTexture3_SetDecalScale(p,a) > (p)->lpVtbl->SetDecalScale(p,a) #define > IDirect3DRMTexture3_SetDecalTransparency(p,a) > (p)->lpVtbl->SetDecalTransparency(p,a) -#define > IDirect3DRMTexture3_SetDecalTransparencyColor(p,a) > (p)->lpVtbl->SetDecalTransparentColor(p,a) +#define > IDirect3DRMTexture3_SetDecalTransparentColor(p,a) > (p)->lpVtbl->SetDecalTransparentColor(p,a) #define > IDirect3DRMTexture3_GetDecalSize(p,a,b) > (p)->lpVtbl->GetDecalSize(p,a,b) #define > IDirect3DRMTexture3_GetDecalOrigin(p,a,b) > (p)->lpVtbl->GetDecalOrigin(p,a,b) #define > IDirect3DRMTexture3_GetImage(p) (p)->lpVtbl->GetImage(p) @@ -3502,7 > +3502,7 @@ DECLARE_INTERFACE_(IDirect3DRMTexture3, > IDirect3DRMVisual) #define IDirect3DRMTexture3_GetColors(p) > (p)->lpVtbl->GetColors(p) #define > IDirect3DRMTexture3_GetDecalScale(p) (p)->lpVtbl->GetDecalScale(p) > #define IDirect3DRMTexture3_GetDecalTransparency(p) > (p)->lpVtbl->GetDecalTransparency(p) -#define > IDirect3DRMTexture3_GetDecalTransparencyColor(p) > (p)->lpVtbl->GetDecalTransparencyColor(p) +#define > IDirect3DRMTexture3_GetDecalTransparentColor(p) > (p)->lpVtbl->GetDecalTransparentColor(p) #define > IDirect3DRMTexture3_InitFromImage(p,a) > (p)->lpVtbl->InitFromImage(p,a) #define > IDirect3DRMTexture3_InitFromResource2(p,a,b,c) > (p)->lpVtbl->InitFromResource2(p,a,b,c) #define > IDirect3DRMTexture3_GenerateMIPMap(p,a) > (p)->lpVtbl->GenerateMIPMap(p,a) > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJV3EhqAAoJEN0/YqbEcdMw2R8QAJMTA2LoM42LSV4mZUNH1oe/ TrErVK3o2VRiRlBlQL1CLrv6178p01GmIoRmlkXyYgrvmM7Z7mGIEFfhD7g4irVr Cw1M6WnrTFyWgu0DfOw6qaYqknjLcGJTukQ97R1nd8wgQ0/dfDVmB8SWl7V6KWO9 F0UyY3P05B20hbeKhUouoxfhdEO0pkVDgvFffe9A5+01uP/uTzFFYWVhacmoY9nl VYhyDFhCM+Fut/I8RhDzZfRA+VmvxRBTQyEdlH93GMhov4Tf50bSdu41pd3WZL6g bf2WW/vIAhwsIpoSe6GUPEkqjq9hc4a5TXVyUZhStergGeEiy3USuSbXSRRbLc+w yu/jLr/BLm/nVOicP/BmWVspEt1z9ksjfcVYdXgpQEoeS7NLn0gyihLn7lnbl2dv pSVgfVLUMsWcO0IzlTruARHEelEZV9DFKnLkQpe1U1nKqw27M9J7L+bE5euWHj9L ZSXjip4Yf9wSENVNqyeZK9I+kXpOs1i3TVquY9tvFgwjoXtj+F3ZyGCETRFXcPti dCX0xmIl9M1jwxdJn9rSlVr8w0ZSuYZHGjsxGBZDFWPVMDUNql5HTD5Tbe47iTXg 8ZiB6qzrcuTdXS4DaQjVvKVmiv0lqvrKPaKWg7u2Q5wBlUr0ITXSfq5vam4uMHIf C36Co9yOt+tapC7y73gU =1Eea -----END PGP SIGNATURE-----

2 1

Re: [PATCH 5/5] d3d11: Add ID3D11Texture2D stub interface.
by Henri Verbeet 24 Aug '15

24 Aug '15

On 24 August 2015 at 01:04, Józef Kucia <jkucia(a)codeweavers.com> wrote: > struct d3d10_texture2d > { > ID3D10Texture2D ID3D10Texture2D_iface; > + ID3D11Texture2D ID3D11Texture2D_iface; We usually put the newest interface version first. > +static HRESULT texture2d_query_interface(struct d3d10_texture2d *texture, REFIID riid, void **object) > { > - struct d3d10_texture2d *This = impl_from_ID3D10Texture2D(iface); > - > - TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), object); > - > if (IsEqualGUID(riid, &IID_ID3D10Texture2D) > || IsEqualGUID(riid, &IID_ID3D10Resource) > || IsEqualGUID(riid, &IID_ID3D10DeviceChild) > || IsEqualGUID(riid, &IID_IUnknown)) > { > - IUnknown_AddRef(iface); > - *object = iface; > + *object = &texture->ID3D10Texture2D_iface; > + IUnknown_AddRef((IUnknown *)*object); > + return S_OK; > + } > + else if (IsEqualGUID(riid, &IID_ID3D11Texture2D) > + || IsEqualGUID(riid, &IID_ID3D11Resource) > + || IsEqualGUID(riid, &IID_ID3D11DeviceChild)) > + { > + *object = &texture->ID3D11Texture2D_iface; > + IUnknown_AddRef((IUnknown *)*object); > return S_OK; > } > Here too. > +static HRESULT STDMETHODCALLTYPE d3d10_texture2d_QueryInterface(ID3D10Texture2D *iface, REFIID riid, void **object) > +{ > + struct d3d10_texture2d *This = impl_from_ID3D10Texture2D(iface); > + > + TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), object); > + > + return texture2d_query_interface(This, riid, object); > +} There's something to say for this approach, but what we usually do is to just forward to the newest interface version (where possible, practical, etc.) I.e. "return d3d11_texture2d_queryInterface(&texture->ID3D11Texture2d_iface, iid, out);". > +HRESULT STDMETHODCALLTYPE d3d11_texture2d_QueryInterface(ID3D11Texture2D *iface, REFIID riid, void **object) These should be static.

1 0

IDirect3DRMTexture stub patches.
by Aaryaman Vasishta 24 Aug '15

24 Aug '15

These patches will be needed before I can add tests for, and implement version 1 of Create/LoadTexture. Please provide feedback on any modifications required. (Patches 0000-0006 are already in wine-patches but not committed yet). Cheers, Jam

2 2

Re: [PATCH] ucrtbase: Add the new universal CRT DLL.
by Alexandre Julliard 24 Aug '15

24 Aug '15

Martin Storsjo <martin(a)martin.st> writes: > +@ stub -arch=win32 ?_set_new_handler@@YAP6AHI@ZH@Z # int(__cdecl*__cdecl _set_new_handler(int))(unsigned int) > +@ stub -arch=win64 ?_set_new_handler@@YAP6AH_K@ZH@Z # int(__cdecl*__cdecl _set_new_handler(int))(unsigned __int64) > +@ stub _set_new_mode > +@ cdecl _set_printf_count_output(long) MSVCRT__set_printf_count_output > +@ cdecl _set_purecall_handler(ptr) > +@ stub -arch=win32 ?_set_se_translator@@YAP6AXIPAU_EXCEPTION_POINTERS@@@ZH@Z # void(__cdecl*__cdecl _set_se_translator(int))(unsigned int,struct _EXCEPTION_POINTERS *) > +@ stub -arch=win64 ?_set_se_translator@@YAP6AXIPEAU_EXCEPTION_POINTERS@@@ZH@Z # void(__cdecl*__cdecl _set_se_translator(int))(unsigned int,struct _EXCEPTION_POINTERS * __ptr64) I don't see any mangled names in my version. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winhttp: Add support for WinHttpRequestOption_URLCodePage.
by Hans Leidekker 24 Aug '15

24 Aug '15

On Mon, 2015-08-24 at 15:03 +0800, Dmitry Timoshkov wrote: > @@ -3071,6 +3072,7 @@ static void initialize_request( struct winhttp_request *request ) > request->connect_timeout = 60000; > request->send_timeout = 30000; > request->receive_timeout = 30000; > + request->url_codepage = CP_ACP; MSDN says that it defaults to CP_UTF8 and my tests confirm that.

1 0

Re: ieframe: Added more test traces to diagnose some test failures.
by Marvin 23 Aug '15

23 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16243 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2971: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2976: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2971: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2976: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2971: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2976: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE

1 0

Re: [3/4] ntdll/tests: Add additional tests for calling NtOpenFile with file object as RootDirectory.
by Marvin 23 Aug '15

23 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16238 Your paranoid android. === w8 (32 bit file) === file.c:410: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: gdi32/tests: 64 bit GetFontFileInfo may fail with error ERROR_NOACCESS.
by Marvin 22 Aug '15

22 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16214 Your paranoid android. === wvistau64 (32 bit font) === The test timed out

1 0

Re: different behaviors of mixed-mode assembly under .net/wine-mono/native mono.
by Hin-Tak Leung 22 Aug '15

22 Aug '15

------------------------------ On Sat, Aug 22, 2015 5:07 PM BST Vincent Povirk wrote: >> Is it possible to enable win32 mono's mixed mode support at runtime, >> or does it requires a re-compile? > >I'm not sure, but I think there is a switch to mono.exe. > Hmm, I just read the linux mono man pages... don't know where the win32-specfic features of mono might be documented. I'll try to find out. >> The two ldarg.s look invalid to me, but it is possible that Cecil is getting >> confused in the same way as mono. > >The solution is probably to modify the JIT compiler in wine-mono to >accept this code. If you feel like looking into this issue, the application concerned is Microsoft's font validator: https://www.microsoft.com/typography/FontValidator.mspx The LTSH and hdmx, vdmx table tests and the rasterization test (on a different tab) throws illegal IL code exception captured in its report. You can de-select the other tests which don't matter. To use, click "add font" under the options, load up any truetype font, and click the 'tick" symbol to start. The XML viewer doesn't work under wine - COM/ActiveX and IE - so you probably want to save the report and read it as text. The exceptions are thrown in the truetype.dll as: Invalid IL code in Avalon.Media.Text.TrueType.RasterInterf:CalcDevMetrics (int,int,int,uint16,byte[],uint16,byte,byte,uint16[],uint16[],uint16,Avalon.Media.Text.TrueType.RasterInterf/UpdateProgressDelegate): IL_039a: ldarg.s Invalid IL code in Avalon.Media.Text.TrueType.RasterInterf:RastTest (int,int,int[],single,single,single,single,single[2],Avalon.Media.Text.TrueType.RasterInterf/RastTestErrorDelegate,Avalon.Media.Text.TrueType.RasterInterf/UpdateProgressDelegate): IL_0098: ldarg.s if you don't even want to run it :-). As I said it works correctly under wine + .net 2, and throws the "correct" error under linux mono and win32 mono about not being able to initialize the constructor of an object around native code, so both behaviors are "expected". I have a command-line wrapper around the Font Validator to make batch testing easier, though I don't expect it is of any use for looking at the IL code issue?

1 2

Re: [3/3] ntdll: Implement FileRenameInformation support. (try 2)
by Marvin 22 Aug '15

22 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16212 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: different behaviors of mixed-mode assembly under .net/wine-mono/native mono.
by Hin-Tak Leung 22 Aug '15

22 Aug '15

------------------------------ On Fri, Aug 21, 2015 8:20 PM BST Vincent Povirk wrote: >> So I have a specific question - how do I go about finding >> out how the IL code exception comes about? >> (I have had a couple of patches in either camp so >> I am not against patching wine or mono, or wine-mono for that matter) > >You can set the WINE_MONO_VERBOSE environment variable to a single >digit greater than 0 to get debugging information related to JIT >compilation. This should at least tell you exactly which method's IL >is being rejected. > Actually I don't need that - the applicatin itself records the stack trace in its normal xml output as: Invalid IL code in method1 (int,int,int,uint16,byte[],uint16,byte,byte,uint16[],uint16[],uint16, delegate type1): IL_039a: ldarg.s 12

 and Invalid IL code in method2 (int,int,int[],single,single,single,single,single[2],delegate type1, delegate2): IL_0098: ldarg.s 8

 The first one is doing "ldarg.s <the delegate>", while the other is doing "ldarg.s <the single[2]>". I just noticed one anomaly - the single[2] type should be a single[,] type; These are according to monodevelop's assembly browser. >Setting MONO_VERBOSE_METHOD will show debugging information for the >JIT compilation of a specific method, unfortunately Mono crashes >trying to parse many of the mangled names that appear in Managed C++ >assemblies, so often this approach does not work for me. I've often >had to hack the code that checks MONO_VERBOSE_METHOD to special-case a >specific method name. > monodis somehow doesn't show either of those. >> And a general question: are mixed mode assemblies supposed >> to work under win32 mono at all, or wine-mono definitely needed? >> I saw some wine + mono discussions a while ago and >> I got the impression that mixed mode assemblies are supposed to >> work with win32 mono somewhat? > >There is some support for mixed-mode in win32 mono, but it is disabled >by default. They are different enough that I would not use win32 mono >on Windows to learn anything about how well wine-mono "should" work. > Is it possible to enable win32 mono's mixed mode support at runtime, or does it requires a re-compile? >> The application itself is available as a public download in binary form. >> But since it mostly works - correctly under .net, and even the >> illegal IL exception was caught, just not the null constructor. >> Editing the IL code to put a try+catch around the constructor >> makes it largely operational too under linux mono, so there is >> not much of a bug to file; mostly a curiosity why >> wine-mono doesn't behave like it support mixed-mode fully, or >> not at all, but something between. > >Microsoft's managed C++ compiler has been known to generate IL that >technically violates ecma 335, or otherwise gives Mono trouble. We >have hacks in wine-mono for a few of these cases, but it's likely we >have not addressed all of them. > >There are also features used by managed C++, such as "thiscall" >reverse-pinvokes, which are technically independent of mixed-mode, but >which are not implemented in wine-mono. The two ldarg.s look invalid to me, but it is possible that Cecil is getting confused in the same way as mono.

2 1

Re: [2/4] ntdll/tests: Add additional tests for FileRenameInformation.
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16200 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

different behaviors of mixed-mode assembly under .net/wine-mono/native mono.
by Hin-Tak Leung 21 Aug '15

21 Aug '15

Hi, I am trying to look into a somewhat curious issue about mixed mode assembly under wine-mono. The application works correctly under wine + MS .net 2. With native mono on the explicit command line, either win32 mono + wine, or x86_64 linux mono on x86_64 linux, the win32 native constructor of a class returns a null. That's fair enough. But with wine-mono, the application does not behave either like .net 2 or win32 mono on the command line. It throws illegal IL code exception. So I have a specific question - how do I go about finding out how the IL code exception comes about? (I have had a couple of patches in either camp so I am not against patching wine or mono, or wine-mono for that matter) And a general question: are mixed mode assemblies supposed to work under win32 mono at all, or wine-mono definitely needed? I saw some wine + mono discussions a while ago and I got the impression that mixed mode assemblies are supposed to work with win32 mono somewhat? The application itself is available as a public download in binary form. But since it mostly works - correctly under .net, and even the illegal IL exception was caught, just not the null constructor. Editing the IL code to put a try+catch around the constructor makes it largely operational too under linux mono, so there is not much of a bug to file; mostly a curiosity why wine-mono doesn't behave like it support mixed-mode fully, or not at all, but something between. Hin-Tak

2 1

Re: [PATCH 7/7] d3d11/tests: Add test for device interfaces.
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16187 Your paranoid android. === wvistau64 (32 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 00401721 === w2008s64 (32 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 00401721 === wvistau64 (64 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 000000000040168C === w2008s64 (64 bit d3d11) === d3d11.c:80: Test failed: Device should implement ID3D10Multithread interface, hr 0x80004002. d3d11: unhandled exception c0000005 at 000000000040168C

1 0

Re: [PATCH 2/3] xaudio2: Add stub IXAudio2MasteringVoice implementation
by Henri Verbeet 21 Aug '15

21 Aug '15

On 20 August 2015 at 22:06, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > +struct IXAudio2MasteringVoiceVtbl XAudio2MasteringVoice_Vtbl = { Should that have been "static const"?

2 1

Re: [PATCH 2/3] xaudio2: Implement IXAudio2::GetDeviceDetails
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16244 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] po: Update Finnish translation.
by Nikolay Sivov 21 Aug '15

21 Aug '15

On 21.08.2015 16:02, Lauri Kenttä wrote: > #: uninstaller.rc:33 > -#, fuzzy > -#| msgid "Error: Invalid option '%c'.\n" > msgid "uninstaller: Invalid option [%1]\n" > -msgstr "Virhe: Viallinen vaihtoehto '%c'.\n" > +msgstr "unistaller: Virheellinen valitsin [%1]\n" Hi, Lauri. Is this a typo in "uninstaller" ?

1 0

Re: [3/3] server: Do not permit FileDispositionInformation to delete a file without write access.
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16154 Your paranoid android. === w8 (32 bit file) === file.c:408: Test failed: mismatched file size for L"WindowsUpdate.log"

1 0

Re: [PATCH] gdi32: unlock critsection on error exit (Coverity)
by Nikolay Sivov 21 Aug '15

21 Aug '15

On Friday, August 21, 2015, Marcus Meissner <marcus(a)jet.franken.de> wrote: > 713131 Missing unlock > --- > dlls/gdi32/freetype.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > > I think enum_face_charsets() unlocks it internally, is it not a case sometimes?

1 0

Re: [2/3] server: Add support for setting file disposition information.
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16152 Your paranoid android. === wvistau64 (32 bit file) === file.c:450: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:450: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [PATCH 4/5] d3d11/tests: Add test for device interfaces. (try 2)
by Henri Verbeet 21 Aug '15

21 Aug '15

On 21 August 2015 at 00:07, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Try 2: > * Add missing "implement" in a test failure message. > * It seems that ID3D10Multithread is not available on Windows Vista. Odd. (Although perhaps more so the fact that it is available on the other Windows versions while e.g. ID3D10Device1 isn't.) > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, 0, &feature_level, 1, D3D11_SDK_VERSION, > + &device, NULL, NULL))) I think the indentation here is a bit weird. Strictly speaking I suppose it's correct because the D3D11CreateDevice() call is inside a SUCCEEDED(), but I'd prefer just 8 space indent.

1 0

Re: msvcirt: Add a more accurate implementation of streambuf::pbackfail
by Piotr Caban 21 Aug '15

21 Aug '15

On 08/19/15 19:04, Iván Matellanes wrote: > +/* ?pbackfail@streambuf@@UAEHH@Z */ > +/* ?pbackfail@streambuf@@UEAAHH@Z */ > +DEFINE_THISCALL_WRAPPER(streambuf_pbackfail, 8) > +#define call_streambuf_pbackfail(this, c) CALL_VTBL_FUNC(this, 36, int, (streambuf*, int), (this, c)) > +int __thiscall streambuf_pbackfail(streambuf *this, int c) > +{ > + TRACE("(%p %d)\n", this, c); > + if (this->gptr > this->eback) > + return *--this->gptr = c; > + if (call_streambuf_seekoff(this, -1, SEEKDIR_cur, OPENMODE_in) == EOF) > + return EOF; > + return c; > +} If seekoff is used the buffers needs to be updated. Otherwise next read will return incorrect data. You will need to make space for put back character and place it in the buffer. Thanks, Piotr

1 0

Re: [1/2] kernel32/tests: Fix compilation with PSDK.
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16143 Your paranoid android. === w7u (32 bit process) === process.c:2663: Test failed: WaitForSingleObject returned 258 process.c:2680: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH] mshtml: Add IHTMLXMLHttpRequest::abort() method implementation.
by Marvin 21 Aug '15

21 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16139 Your paranoid android. === w2000pro (32 bit xmlhttprequest) === xmlhttprequest: unhandled exception c0000005 at 00475F35

1 0

Re: [1/3] comdlg32: Implement SetControlItemState for menu controls.
by Marvin 20 Aug '15

20 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16136 Your paranoid android. === w7u (32 bit itemdlg) === itemdlg: unhandled exception c0000005 at 76A81EA3 === wvistau64 (64 bit itemdlg) === No test summary line found

1 0

Re: [PATCH 4/5] d3d11/tests: Add test for device interfaces. (try 2)
by Marvin 20 Aug '15

20 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16232 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [PATCH 14/16] msvcp110: Add tr2_sys__Stat_wchar and tr2_sys__Lstat_wchar implementation and test.(resend)
by Marvin 20 Aug '15

20 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16129 Your paranoid android. === w2008s64 (64 bit msvcp120) === msvcp120.c:176: Test failed: Export '?_Lstat@sys@tr2@std@@YA?AW4file_type@123@PB_WAAH@Z' not found msvcp120: unhandled exception c0000005 at 0000000000000000

1 0

CreateDeviceFromD3D implementations, device QI tests and some other patches.
by Aaryaman Vasishta 20 Aug '15

20 Aug '15

Hello! Attached are patches related to implementations of CreateDeviceFromD3D and device QI tests along with fixes to return values for GetDirect3DDevice2 and device QueryInterface. Cheers, Jam

2 5

Re: [PATCH 3/4] wined3d: Add a slop for color keying.
by Henri Verbeet 20 Aug '15

20 Aug '15

On 20 August 2015 at 10:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -6332,7 +6332,8 @@ static GLuint shader_glsl_generate_ffp_fragment_shader(struct shader_glsl_priv * > } > > if (settings->color_key_enabled) > - shader_addline(buffer, "if (all(equal(tex0, color_key))) discard;\n"); > + shader_addline(buffer, "if (all(lessThan(abs(tex0 - color_key), vec4(%s)))) discard;\n", > + wined3d_color_key_precision); > ... > +/* Normalization of B5G6R5_UNORM textures is horribly imprecise if we don't have > + * GL_RGB_565 support. 1 / 256 (~0.0039) works in practice, but is awfully close > + * to the next possible value in 8 bit formats. 1 / 384 is too precise for some > + * 5 and 6 bit channel values at least on Nvidia. > + * > + * An exact comparison isn't reliable for any format, except for the normalized > + * values 0.0 and 1.0. */ > +const char *wined3d_color_key_precision = "0.003"; > Shouldn't you just pass the color key as a range to the shader instead? E.g. in a 6 bpc format anything between 0.484f and 0.500f would get quantized to 0x1f. (Which, other floating point issues aside, would correspond to about 0.008 slop here. For a 5 bpc format you'd even have 0.016.)

2 3

Re: [PATCH 02/16] msvcp110: Add tr2_sys__Rename_wchar implementation and test.(try 2)
by Marvin 20 Aug '15

20 Aug '15

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 https://testbot.winehq.org/JobDetails.pl?Key=16121 Your paranoid android. === w2000pro (32 bit msvcp120) === The test timed out

1 0

Re: [PATCH 6/7] d3d10core: Implement D3D10CoreCreateDevice using D3D11CoreCreateDevice.
by Henri Verbeet 20 Aug '15

20 Aug '15

On 20 August 2015 at 01:47, Józef Kucia <jkucia(a)codeweavers.com> wrote: > DXGID3D10* functions will be dropped once IDXGIDevice is moved to d3d11. > > D3D10CoreRegisterLayers returns E_NOTIMPL on modern Windows systems. > --- I think the general idea of this patchset works (I haven't looked at all the details yet), but I don't think you can use d3d11 source files in d3d10core like that. If there's really no better way you can probably temporarily use PARENTSRC (look at e.g. d3dcompiler_47 for an example of how to use that), but it may be better to reorder things a bit so that you can essentially merge this patch with the one moving the files.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel