- wine-devel - winehq.org

Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution
by Mark Harmstone 23 Nov '14

23 Nov '14

Oops, sorry, yes I did. How about the attached patch? It only calls XRRSetScreenSize if there's only one active CRTC. I've managed to scrounge another monitor now, and it works for me with both single and multiple monitors. On 20/11/14 13:19, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Did you accidentally drop the wine-devel CC, or was this on purpose? > I'd like to CC wine-devel on my reply but don't want to forward your > mail without your consent. > > Stefan > > On 11/20/14 14:03, Mark Harmstone wrote: >> Hi, >> >> I tested this with KDE 4.14.3 and kwin 4.11.14, and it worked fine >> - if there's a KDE bug, it must have been fixed in the latest >> versions. I only have a single monitor to test with, though. >> >> Setting crtc_info->x and crtc_info->y to 0 in XRRSetCrtcConfig >> does stop it from failing outright, but in my experience these are >> only non-zero when panning is already on. For the first resolution >> change, it won't prevent the drivers from going into panning mode, >> and won't (for instance) stop Icewind Dale from failing on startup >> on low resolutions. >> >> Plus all this patch is doing is what xrandr is doing already - >> does that mean that xrandr also messes up multi-monitor setups, or >> would you need to pass it different arguments? And I'm not sure >> what the official Wine line is on this, but it seems to me sensible >> to prioritize simple common setups over complicated rare ones - I'm >> sure far more people use nvidia-drivers than have two monitors. >> >> Mark >> >> >> On 20/11/14 12:48, Stefan Dösinger wrote: On 11/20/14 13:11, Mark >> Harmstone wrote: >>>>> This changes xrandr12_set_current_mode so it behaves the same >>>>> way as xrandr does in 1.2 mode (e.g, `xrandr --output HDMI-0 >>>>> --crtc 0 --mode 640x480`). Before XRRSetCrtcConfig is called, >>>>> the CRTC is temporarily disabled, then XRRSetScreenSize is >>>>> called. (XRRSetCrtcConfig will fail if the CRTC isn't >>>>> disabled first.) >> I've experimented with this a few weeks ago, and it drastically >> improves the usability of fullscreen applications on >> Metacity-based window managers. Unfortunately I'm afraid it is not >> quite that simple. It breaks KDE (may be a bug) and it breaks >> multi-monitor setups. >> >> Testing on Windows (sorry, I did not write formal tests) shows that >> in single monitor setups the virtual screen size is adjusted to >> match the monitor's resolution when the resolution is changed. So >> the change is correct in single monitor setups, but needs tests. >> >> In multi-monitor setups the virtual screen size is changed too, but >> it still takes both monitors into account. E.g. you had two >> monitors at 1920x1080, where one is to the right of the other. So >> you have a virtual screen of 3840x1080. If you change the res of >> the left monitor to 640x480 you get a virtual screen size of >> 2560x1080. >> >> I hackily "fixed" the Nvidia panning bug by replacing crtc_info->x >> and crtc_info->y in pXRRSetCrtcConfig with 0, 0. That way the mode >> set succeeds and the CRTC is positioned correctly. The direct3d >> mouse grab takes care of the mouse moving outside the window, but >> only after clicking in the window once. The d3d grab is incorrect >> though as far as I can see. Windows doesn't grab the mouse in >> fullscreen d3d games in dual monitor setups. >> >> Passing an offset of 0, 0 to pXRRSetCrtcConfig may be the correct >> thing to do. It seems that the content of crtc_info->x and >> crtc_info->y depends on the mouse pointer location, which would be >> an odd thing for a mode change to depend on. May be an Nvidia bug. >> >> Finally, there is a bug in all window managers forked from >> Metacity. If the new resolution is smaller in width or height than >> half the virtual screen size (= old resolution for single-monitor >> setups) then the WM places the window incorrectly. xwininfo reports >> where the window *should* be - at 0x0-WxH. But the real display >> location is something different, depending on the exact incarnation >> of the WM. In Unity it is shifted by 64x64 (unity bar I guess) and >> stretched to the virtual screen size. In MATE I think the window is >> centered. I suspect this is caused by the window positioning logic >> breaking. I have not been able to isolate the bug in the window >> manager code yet. >> >> All in all I'm afraid we have a number of different bugs to fix in >> all Metacity forks, Wine, the Nvidia driver and maybe KDE. >> >> Fwiw, KDE and FVWM place fullscreen windows properly. MATE and >> Unity also adjust their title bars and window maximization to match >> the new CRTC size, not the screen size. >> >>> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJUbepaAAoJEN0/YqbEcdMwl0YP/2/QPABqbt3awjNBqQjAV7eA > 0nH8AqvoaSCJ6Ecy3allYa8MC21RmyhK5mCa7e4yWnqTkOaOFCqgjnwPf7C1p7MO > g/aGKsEFpHEM1YL1uvraKDVMeZGVXnSnE08eTrovNBvNvAhZn4Q/y6DZlOVjsJ44 > djJA98/cYoditLcOVSmnqPv9hY85jQYTT2jduvZ7oMbRMhdjU5KZkyEMiCN83F/t > iaY3IQfDzuoGBgH9/f+cSlNlNE8AJvXocJwOVfoW7FD/VU81N9jl5yMzujqEznos > UquZ0CzBlyEWH7i0nxtjL/rfbc4giyF8aKByhSl9PS3k+DaKNsPtt6FWl4a/5+/i > LJU4DQwdWFyQMtyR84kLvskPtNFB7ZNtzmPFvMtVBSziu0NvTGCEPTKKdPX+GgdP > MiX3hSZFhkHzmoEEzfEGI0+j2Azj1RLi7xdVW/z/XIwhsPEd3dAytMaYWe8T05qI > +ysOMuUGRz0tNVPSFiiO7FYcvsj4/o5la/fa0DbIh77GJvZqm8xHCHI6+Lf+Gx5N > EurAoLaH+m8FTA5YRUoTKbxtVY/j+/B7LiTW5x53QcQH/Cb/B9Q2dcH5g/UGugDo > eNm2ZFVqHkIRBa695sm4uTWZHj6RQUblBmLi2tIIdfIihiinZVDBci1CFua+Obsu > p7VTdlbDMVuomwzPL7FA > =DLsp > -----END PGP SIGNATURE----- >

2 2

Re: fusion: Remove unused IAssemblyCacheItem (Clang)
by Nikolay Sivov 22 Nov '14

22 Nov '14

On 21.11.2014 22:58, André Hentschel wrote: > --- > dlls/fusion/asmcache.c | 94 -------------------------------------------------- > 1 file changed, 94 deletions(-) > I guess the idea was to create some instance with CreateAssemblyCacheItem(), it's trivial and I think we should do that instead of removing item code (even if it's a stub).

1 0

Re: dwrite/tests: Remove unused functions (Clang)
by Nikolay Sivov 22 Nov '14

22 Nov '14

On 21.11.2014 22:58, André Hentschel wrote: > --- > dlls/dwrite/tests/analyzer.c | 7 ------- > dlls/dwrite/tests/layout.c | 7 ------- > 2 files changed, 14 deletions(-) I'll send a patch to use those helpers, don't remove them for now.

1 0

Re: dwrite: Remove unused code (Clang)
by Nikolay Sivov 22 Nov '14

22 Nov '14

On 21.11.2014 22:58, André Hentschel wrote: > --- > dlls/dwrite/bidi.c | 6 ------ > dlls/dwrite/shape.c | 2 -- > 2 files changed, 8 deletions(-) > I don't mind, let's remove that. Looks like iso_previousChar() could be removed from usp10 too then.

1 0

Re: wined3d: Add NVIDIA Geforce GT 750M to supported device list.
by Jonas Maebe 21 Nov '14

21 Nov '14

FWIW, I have such an NVIDIA Geforce GT 750M card (under OS X 10.9.5) and Crossover 13.2 returned 768MB of vram for it. Crossover 14/14.0.1 returns 128MB instead, which resulted in a number of games suddenly crashing because they ran out of VRAM. This issue was quickly diagnosed by the helpful Codeweavers support person, and resolved by adding the registry entry to override the video memory size. Looking at the current source code, I assume that's because shader_arb_get_caps() can set the shader_caps->vs_version maximally to 3, while d3d_level_from_caps() will only return WINED3D_D3D_LEVEL_10 for shader_caps->vs_version==4. As a result, d3d_level_from_caps now returns WINED3D_D3D_LEVEL_9_SM3, which is translated for an unknown NVidia card into CARD_NVIDIA_GEFORCE_6800. That one is indeed defined as having 128MB of VRAM.

5 13

Re: [PATCH 5/5] d3d8: Only one fullscreen swapchain is allowed.
by Marvin 21 Nov '14

21 Nov '14

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=10398 Your paranoid android. === w8 (32 bit device) === device.c:1222: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1267: Test failed: Reset failed, hr 0x88760868. device.c:1269: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1273: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1280: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1281: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1282: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1283: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1284: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1285: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1290: Test failed: Screen width is 640, expected 800. device.c:1291: Test failed: Screen height is 480, expected 600. device.c:1297: Test failed: Back buffer width is 640, expected 800. device.c:1299: Test failed: Back buffer height is 480, expected 600. device.c:1329: Test failed: Screen width is 640, expected 1024. device.c:1330: Test failed: Screen height is 480, expected 768. device.c:2517: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2522: Test failed: The focus window is active. device.c:2530: Test failed: Got unexpected hr 0x88760869. device.c:2536: Test failed: Got unexpect screen size 800x600. device.c:2551: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2560: Test failed: Got unexpect screen size 800x600. device.c:2573: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2580: Test failed: Got unexpect width 640. device.c:2581: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 4/5] d3d8/tests: Fix test_cursor().
by Marvin 21 Nov '14

21 Nov '14

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=10397 Your paranoid android. === w8 (32 bit device) === device.c:1186: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1231: Test failed: Reset failed, hr 0x88760868. device.c:1233: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1237: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1244: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1245: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1246: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1247: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1248: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1249: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1254: Test failed: Screen width is 640, expected 800. device.c:1255: Test failed: Screen height is 480, expected 600. device.c:1261: Test failed: Back buffer width is 640, expected 800. device.c:1263: Test failed: Back buffer height is 480, expected 600. device.c:1293: Test failed: Screen width is 640, expected 1024. device.c:1294: Test failed: Screen height is 480, expected 768. device.c:2481: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2486: Test failed: The focus window is active. device.c:2494: Test failed: Got unexpected hr 0x88760869. device.c:2500: Test failed: Got unexpect screen size 800x600. device.c:2515: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2524: Test failed: Got unexpect screen size 800x600. device.c:2537: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2544: Test failed: Got unexpect width 640. device.c:2545: Test failed: Got unexpect height 480.

1 0

Re: gdiplus:GdipDrawImagePointsRect has a nosie vertical line output after resampled
by Vincent Povirk 21 Nov '14

21 Nov '14

This will break in cases where the destination area (defined by points) is not a rectangle. On Fri, Nov 21, 2014 at 8:32 AM, 刘昌辉 <liuchanghui(a)linuxdeepin.com> wrote: > > > >

1 0

Re: [PATCH 4/5] wined3d: Don't minimize hidden Windows.
by Henri Verbeet 21 Nov '14

21 Nov '14

On 19 November 2014 20:13, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2189,6 +2189,13 @@ static LRESULT CALLBACK test_proc(HWND hwnd, UINT message, WPARAM wparam, LPARAM > } > } > > + if (unexpected_messages) > + { > + const struct message *i; > + for (i = unexpected_messages; i->message; i++) > + ok(i->message != message, "Got unexpected message %x on window %p.\n", message, hwnd); Note that putting the ok() in test_proc() makes it hard to find the actual test that failed.

2 1

Re: shell32/tests: Fix a copy and paste error (PVS-Studio)
by Marvin 20 Nov '14

20 Nov '14

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=10373 Your paranoid android. === wvistau64 (32 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR === wvistau64 (64 bit shlfileop) === shlfileop.c:815: Test failed: Expected ERROR_CANCELLED or DE_DIFFDIR

2 1

Re: [2/2] ws2_32: Implement returning the proper time with SO_CONNECT_TIME.
by Bruno Jesus 20 Nov '14

20 Nov '14

On Thu, Nov 20, 2014 at 10:27 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Based on a patch by Erich Hoover. > > To avoid calculations on the client-side, the server sends the connect time as relative (negative) value. > Needs tools/make_requests. Hi, Sebastian. Thanks for taking care of this, but actually I'm thinking by doing this in a different way. I'm thinking about moving SO_CONNECT_TIME, SO_SNDBUF and SO_RECVBUF to the server with some new server message or the one Erich created for the WSAIoctl. By doing it this way we can fix not only this bug but also https://bugs.winehq.org/show_bug.cgi?id=8606 where we can store the pretended SO_SNDBUF value and return to the client when asked. Some other messages could also be done there like SO_EXCLUSIVEADDR, SO_DEBUG and others that require only memory to store/retrieve the value. This would also help for SO_ACCEPTCONN which is bugged in OSX due to a kernel problem. Not sure if my approach would be accepted anyway. Best wishes, Bruno

2 6

Re: [PATCH 1/2] Add tests for calling ShowWindow(SW_HIDE) on a hidden window.
by Marvin 20 Nov '14

20 Nov '14

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=10364 Your paranoid android. === w7u (32 bit msg) === msg.c:12217: Test failed: unexpected hwnd 0014013C msg.c:12239: Test failed: bad time 309c0/309cf

2 1

Re: [PATCH] explorer: Fix copy_path_string() when an unnecessary \ follow the path.
by Huw Davies 20 Nov '14

20 Nov '14

On Thu, Nov 20, 2014 at 08:29:17PM +0800, Jactry Zeng wrote: > @@ -639,6 +640,11 @@ static int copy_path_string(LPWSTR target, LPWSTR source) > while (*source && *source != ',') target[i++] = *source++; > target[i] = 0; > } > + > + last = strlenW(target) - 1; > + if (target[0] && target[last] == '\\') > + target[last] = 0; > + > return i; > } You probably want PathRemoveBackslashW() Huw.

2 1

Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution
by Stefan Dösinger 20 Nov '14

20 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/20/14 13:11, Mark Harmstone wrote: > This changes xrandr12_set_current_mode so it behaves the same way > as xrandr does in 1.2 mode (e.g, `xrandr --output HDMI-0 --crtc 0 > --mode 640x480`). Before XRRSetCrtcConfig is called, the CRTC is > temporarily disabled, then XRRSetScreenSize is called. > (XRRSetCrtcConfig will fail if the CRTC isn't disabled first.) I've experimented with this a few weeks ago, and it drastically improves the usability of fullscreen applications on Metacity-based window managers. Unfortunately I'm afraid it is not quite that simple. It breaks KDE (may be a bug) and it breaks multi-monitor setups. Testing on Windows (sorry, I did not write formal tests) shows that in single monitor setups the virtual screen size is adjusted to match the monitor's resolution when the resolution is changed. So the change is correct in single monitor setups, but needs tests. In multi-monitor setups the virtual screen size is changed too, but it still takes both monitors into account. E.g. you had two monitors at 1920x1080, where one is to the right of the other. So you have a virtual screen of 3840x1080. If you change the res of the left monitor to 640x480 you get a virtual screen size of 2560x1080. I hackily "fixed" the Nvidia panning bug by replacing crtc_info->x and crtc_info->y in pXRRSetCrtcConfig with 0, 0. That way the mode set succeeds and the CRTC is positioned correctly. The direct3d mouse grab takes care of the mouse moving outside the window, but only after clicking in the window once. The d3d grab is incorrect though as far as I can see. Windows doesn't grab the mouse in fullscreen d3d games in dual monitor setups. Passing an offset of 0, 0 to pXRRSetCrtcConfig may be the correct thing to do. It seems that the content of crtc_info->x and crtc_info->y depends on the mouse pointer location, which would be an odd thing for a mode change to depend on. May be an Nvidia bug. Finally, there is a bug in all window managers forked from Metacity. If the new resolution is smaller in width or height than half the virtual screen size (= old resolution for single-monitor setups) then the WM places the window incorrectly. xwininfo reports where the window *should* be - at 0x0-WxH. But the real display location is something different, depending on the exact incarnation of the WM. In Unity it is shifted by 64x64 (unity bar I guess) and stretched to the virtual screen size. In MATE I think the window is centered. I suspect this is caused by the window positioning logic breaking. I have not been able to isolate the bug in the window manager code yet. All in all I'm afraid we have a number of different bugs to fix in all Metacity forks, Wine, the Nvidia driver and maybe KDE. Fwiw, KDE and FVWM place fullscreen windows properly. MATE and Unity also adjust their title bars and window maximization to match the new CRTC size, not the screen size. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUbeMbAAoJEN0/YqbEcdMwutAP/jWwKCaDNL0OzaWoQhVM8+XN fmshL9cSYha3jVnJ8TJU92ch/7NcFsnGFL0dAEFz1bZqpM9lHwqapdjhqP7PUI0r yIpRNoBR+UjeX46zQ1oIbcib2UpXhm0YZQ0x45DaaUGvVDFGSs0d2Oo4nulDJFx+ DkEdSxe9p403rc6S2nfWHROaUmT3v/stYs9nN+A+YuBleYZwJz+e+MknElTBiboo RcIWnOICDksJ08oEhWaMxNDLtQstMYp0cuRtPNeB3jCWxRP00xsgXgZ2uAigSrrI OPcLgQ5jq3MFDdHorgz7pM3aOa5YvouFxt1OsCsbyekSovBJMj4WaB0QHmqOxPUQ 2LQzS9TMsR0CJYl6hdsykB6c8Gdqdcc8Gv+SoLUn7FjUckvXi6cgnN+XnXTFBQT2 ah6S59gVYxwvb4IVdvYuAL/AvN3tlfR6rOkw/U3Z16u0KHa2C0SQRSK8ohuFabzS SMq2VEq4Cspub3nYCSOSSFZvmUKxlHdyQPPfXEpFEfBQaM40CnsfqN/7vfchj0dQ jAExC4Z1PGvFJFqVnTFaxZ3eIOPBDIBOTgkDK14gWaxrZoGySTJtDe6513iLBsQv 75JZxcfl5VZbzIfYuUcVjvXoWyr4gqeOSJhe/oEITpd5UwEAZabcvJ/yIH8s3u0T tliUU3UuYOfzLsP7jLP2 =eGIQ -----END PGP SIGNATURE-----

1 0

Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution
by Henri Verbeet 20 Nov '14

20 Nov '14

On 20 November 2014 13:11, Mark Harmstone <hellas(a)burntcomma.com> wrote: > This changes xrandr12_set_current_mode so it behaves the same way as xrandr > does in 1.2 mode (e.g, `xrandr --output HDMI-0 --crtc 0 --mode 640x480`). > Before XRRSetCrtcConfig is called, the CRTC is temporarily disabled, then > XRRSetScreenSize is called. (XRRSetCrtcConfig will fail if the CRTC isn't > disabled first.) > Stefan did tests for this a while back so he'll know the details, but I'm pretty sure this will do the wrong thing on multihead systems.

1 0

Re: Update dmFormName when changing paper size in print ui.(resend, try2)
by Dmitry Timoshkov 20 Nov '14

20 Nov '14

Ralf Habacker <ralf.habacker(a)freenet.de> wrote: > + GetDlgItemTextA(hDlg, cmb2, lpdm->dmFormName, sizeof(lpdm->dmFormName)); Please use CCHFORMNAME instead of sizeof(). > + GetDlgItemTextW(hDlg, cmb2, lpdm->dmFormName, sizeof(lpdm->dmFormName)/sizeof(WCHAR)); Same here. -- Dmitry.

1 0

Re: [PATCH 2/2] Do not call SendMessage() to hide a window that is already hidden (try 3)
by Marvin 20 Nov '14

20 Nov '14

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=10365 Your paranoid android. === w7u (32 bit msg) === msg.c:12214: Test failed: unexpected hwnd 00080150 msg.c:12236: Test failed: bad time 30b26/30b36

1 0

Re: Update dmFormName when changing paper size in print ui. (resend)
by Nikolay Sivov 20 Nov '14

20 Nov '14

On 20.11.2014 10:42, Ralf Habacker wrote: > - if(Sel != CB_ERR) > + if(Sel != CB_ERR) { > lpdm->u1.s1.dmPaperSize = SendDlgItemMessageW(hDlg, cmb2, > CB_GETITEMDATA, > Sel, 0); > + GetDlgItemTextW(hDlg, cmb2, lpdm->dmFormName, sizeof(lpdm->dmFormName)); > + } This looks wrong, this function takes character length, not byte length.

1 0

Re: [PATCH 4/5] wined3d: Don't minimize hidden Windows.
by Marvin 20 Nov '14

20 Nov '14

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=10357 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2476: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2481: Test failed: The focus window is active. device.c:2489: Test failed: Got unexpected hr 0x88760869. device.c:2495: Test failed: Got unexpect screen size 800x600. device.c:2510: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2519: Test failed: Got unexpect screen size 800x600. device.c:2532: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2539: Test failed: Got unexpect width 640. device.c:2540: Test failed: Got unexpect height 480.

1 0

Re: [PATCH 2/5] wined3d: Set the device window size on focus window activation.
by Marvin 20 Nov '14

20 Nov '14

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=10354 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2454: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2459: Test failed: The focus window is active. device.c:2467: Test failed: Got unexpected hr 0x88760869. device.c:2473: Test failed: Got unexpect screen size 800x600. device.c:2488: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2497: Test failed: Got unexpect screen size 800x600. device.c:2633: Test failed: Expected foreground window 000500F6, got 0002004C. device.c:3009: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3013: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3036: Test failed: Failed to reset device, hr 0x88760868. device.c:3040: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3044: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3058: Test failed: Failed to set foreground window. device.c:3062: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:3066: Test failed: Expected device window extended style 0x108, got 0x100.

1 0

Re: d3dcompiler_43: Remove a no-op statement (PVS-Studio)
by Matteo Bruni 19 Nov '14

19 Nov '14

2014-11-19 9:10 GMT+01:00 Michael Stefaniuc <mstefani(a)redhat.de>: > D3DSRO_POSITION is 0. Yes, it is 0, but I still feel like it should stay there for consistency with the other cases. What I mean is that if that line is removed I'm pretty sure I'd be like "oh wow, this is clearly broken" every time I happen to look at that piece of code. But maybe that's just me. > --- > dlls/d3dcompiler_43/bytecodewriter.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/dlls/d3dcompiler_43/bytecodewriter.c b/dlls/d3dcompiler_43/bytecodewriter.c > index 46187f9..71ee6c1 100644 > --- a/dlls/d3dcompiler_43/bytecodewriter.c > +++ b/dlls/d3dcompiler_43/bytecodewriter.c > @@ -855,7 +855,6 @@ static DWORD map_vs_output(struct bc_writer *This, DWORD regnum, DWORD mask, DWO > *has_components = TRUE; > if(regnum == This->oPos_regnum) { > token |= (D3DSPR_RASTOUT << D3DSP_REGTYPE_SHIFT) & D3DSP_REGTYPE_MASK; > - token |= D3DSRO_POSITION & D3DSP_REGNUM_MASK; /* No shift */ > return token; > } > if(regnum == This->oFog_regnum && mask == This->oFog_mask) { > -- > 1.9.3 Cheers, Matteo.

3 2

Re: [PATCH 1/2] mmdevapi: allow GetPropValue function in audio drivers (try 2)
by Andrew Eikum 19 Nov '14

19 Nov '14

Looks good, just one small note below. On Wed, Nov 19, 2014 at 02:35:14PM +0000, Mark Harmstone wrote: > + if (!drvs.pGetPropValue) > + { > + TRACE("Driver does not implement GetPropValue\n"); > + return E_NOTIMPL; > + } > + This makes the drivers without GetPropValue pretty noisy during loading. I don't think anything needs to be printed, since we'll see the TRACEs from the driver if the function is present. Andrew

1 0

Re: [PATCH 2/2] winealsa: implement GetPropValue and return device path (try 2)
by Andrew Eikum 19 Nov '14

19 Nov '14

Looking pretty good. Couple notes below. On Wed, Nov 19, 2014 at 02:35:39PM +0000, Mark Harmstone wrote: > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index 5ad72f9..c21fd0c 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -3823,3 +3823,107 @@ HRESULT WINAPI AUDDRV_GetAudioSessionManager(IMMDevice *device, > > return S_OK; > } > + > +enum AudioDeviceConnectionType { > + AudioDeviceConnectionType_Unknown = 0, > + AudioDeviceConnectionType_PCI, > + AudioDeviceConnectionType_USB > +}; > + > +HRESULT WINAPI AUDDRV_GetPropValue(GUID *guid, const PROPERTYKEY *prop, PROPVARIANT *out) > +{ > + static const PROPERTYKEY devicepath_key = { /* undocumented? - {b3f8fa53-0004-438e-9003-51a46e139bfc},2 */ > + {0xb3f8fa53, 0x0004, 0x438e, {0x90, 0x03, 0x51, 0xa4, 0x6e, 0x13, 0x9b, 0xfc}}, 2 > + }; > + > + static const char dev_info[] = "/sys/class/sound/card%u/device/uevent"; > + I'd prefer "const char *" and actually, is there any reason not to just put this string straight in the sprintf? > + TRACE("%s, (%s,%u), %p\n", wine_dbgstr_guid(guid), wine_dbgstr_guid(&prop->fmtid), prop->pid, out); > + > + if(IsEqualGUID(&prop->fmtid, &devicepath_key.fmtid) && prop->pid == devicepath_key.pid) > + { I think you can use IsEqualPropertyKey here. > + char name[256], uevent[MAX_PATH]; > + EDataFlow flow; > + FILE *fuevent; > + int card, device; > + > + if(!get_alsa_name_by_guid(guid, name, sizeof(name), &flow)) > + { > + WARN("Unknown interface %s\n", debugstr_guid(guid)); > + return E_NOINTERFACE; > + } > + > + /* only implemented for identifiable devices, i.e. not "default" */ > + if(!sscanf(name, "plughw:%u,%u", &card, &device)) > + return E_NOTIMPL; > + > + sprintf(uevent, dev_info, card); > + fuevent = fopen(uevent, "r"); > + > + if(fuevent){ > + enum AudioDeviceConnectionType connection = AudioDeviceConnectionType_Unknown; > + USHORT vendor_id = 0, product_id = 0; > + char *line = NULL; > + > + while (!feof(fuevent)) { > + char *val; > + size_t val_len, len = 0; > + > + getline(&line, &len, fuevent); > + We should probably break on failure here. > + if((val = strchr(line, '='))) { > + val[0] = 0; > + val++; > + > + val_len = strlen(val); > + if (val_len > 0 && val[val_len - 1] == '\n') { val[val_len - 1] = 0; } > + > + if(!strcmp(line, "PCI_ID")){ > + connection = AudioDeviceConnectionType_PCI; > + sscanf(val, "%hX:%hX", &vendor_id, &product_id); > + }else if (!strcmp(line, "DEVTYPE") && !strcmp(val,"usb_interface")) > + connection = AudioDeviceConnectionType_USB; > + else if (!strcmp(line, "PRODUCT")) > + sscanf(val, "%hx/%hx/", &vendor_id, &product_id); > + } > + } Can we do anything sane on sscanf failure here? Maybe dump a WARN and revert back to AudioDeviceConnectionType_Unknown. Is that preferable to falling back on 0 for one or more of the IDs? Andrew

1 0

Re: [2/2] vssapi: Add stub implementations for a couple of functions.
by Alexandre Julliard 19 Nov '14

19 Nov '14

Hans Leidekker <hans(a)codeweavers.com> writes: > --- > dlls/vssapi/main.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/vssapi/vssapi.spec | 10 +++--- > include/Makefile.in | 1 + > include/vss.idl | 31 ++++++++++++++++++ > include/vswriter.h | 47 ++++++++++++++++++++++++++++ > 5 files changed, 167 insertions(+), 5 deletions(-) > create mode 100644 include/vss.idl > create mode 100644 include/vswriter.h It doesn't build on Mingw: ../../../wine/dlls/vssapi/main.c:33:0: warning: "__thiscall" redefined [enabled by default] <built-in>:0:0: note: this is the location of the previous definition main.o:main.c:(.text+0x14): undefined reference to `_VSSAPI_CVssWriter_Initialize@36' collect2: ld returned 1 exit status winegcc: i686-w64-mingw32-gcc failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/2] wined3d: Take abs() of vertex z coordinate as FFP fog coordinate (try 7)
by Stefan Dösinger 19 Nov '14

19 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-14 22:40, schrieb Joachim Priesner: > Take the absolute value of vertex.z as fog coordinate instead of > just the z coordinate. This fixes e.g. fog for applications that > use right-handed projection matrices. > > Also test the clamp behavior of the oFog vertex shader output. Fwiw, the start / end tests look good to me, and the results match what I expected. However I think Henri still disagrees with this patch. Henri, I'd appreciate if you would say what you want. Without that I can offer Joachim only guesswork. My guess is that the test is too complex. There are some parts that are technically not required to demonstrate the correctness of the abs(), but I see some value in the additional checks: *) The "interrupted" quad with extra vertices at z = 0. It shows that the fully fogged other quad is not a result of the interpolation failing entirely and producing INF or NaN. *) The foggy shader test: It shows how negative values coming from vertex shaders are treated. It's just logical to test this considering the behavior of the fixed function pipeline. *) The manual fog coord / unfogged shader tests: Those could be removed I guess, although at least the manual fog coord test shows that there isn't some unexpected interference with negative depth values. Joachim, I can offer you that I try to simplify those tests. If you're still motivated to work on this I'm happy to leave this up to you though. Some ideas for simplifying the test, but I don't know yet if they'll work: *) Split the shader and fixed function tests into separate tests. *) Remove the interpolation tests from the fixed function tests. fog_interpolation_test shows that the fog equation is evaluated in the vertex pipeline in the affected cases, and the fogstart = -1, fogend = 0 test shows that the abs() happens before the fog equation. So I think removing this part of the test for the fixed function part is safe. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUbK/nAAoJEN0/YqbEcdMworwP/2OytnoHiSrHWoFK9YPUvEGQ XIyIDZhe/PoMKaBGRdgqFWd4EjoVr9haUmCcPWb1BK/0R2MVSTIK0TS88RlotiMx ZIBcJJWCiiBvhNrydAW5Qqg/80h5UOgaumkWdi2qF4SfkvP/A3jLXvulXZaOU88k rmnlWXxiQun0EIMzShzms0OZmKxmyKkhm84CXAAr3hIh3k9anXVsr0Nsgi2UXTBl ey55rNaE/NBZdNMP/in/5kEq76f0WA7bx1CV2zfCds5p34thQPQLjuvYQ0mqz3Qg zo24W/J52m70W1GmqD/J2+4g5XPO2Gf3xIjV0NyJW988hsCoHIyQHFXZbRkZQpbQ ULdhBq6VgW6O9d1f9H1hy18HxVwlGPFjnu7gniMTWqtBLzyC3b6pppSqQfg1zRhj X/Njp/JBhSUWe8is4sP2R7sHl2fqMi5ROWQyXVpca/rUdoiu6dAH8zYo3IqepGDW P1RoSiwQXXDEh0tV/gzW7pVnk7nNRtcL6el0R5C7aqrytWi3xLXYfdsug6sluKK6 onN/Iz0PpBDsokaTFUMua1JgZ8fx7+Av/S/2xfPvMpSFyrp+q/Q4fw5HdQEKfCIb +JtA03sG0ZfKLjCWL3JRW2kt3G3TxQTOdaJ+Dic5S50xMjs04Ze2Ie3BzbY4FEn0 ZqXciJ+kIVCN4+LD5aJp =RHD+ -----END PGP SIGNATURE-----

1 0

Re: [PATCH 6/6] wined3d: Restore the display mode on focus change.
by Henri Verbeet 19 Nov '14

19 Nov '14

On 18 November 2014 21:26, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if(!EnumDisplaySettingsW(adapter->DeviceName, ENUM_REGISTRY_SETTINGS, &new_mode)) Formatting. > + else if (current_mode.dmPelsWidth == new_mode.dmPelsWidth > + && current_mode.dmPelsHeight == new_mode.dmPelsHeight > + && current_mode.dmBitsPerPel == new_mode.dmBitsPerPel > + && (current_mode.dmDisplayFrequency == new_mode.dmDisplayFrequency > + || !(new_mode.dmFields & DM_DISPLAYFREQUENCY)) > + && (current_mode.u2.dmDisplayFlags == new_mode.u2.dmDisplayFlags > + || new_mode.dmFields & DM_DISPLAYFLAGS)) Shouldn't that be "!(new_mode.dmFields & DM_DISPLAYFLAGS)"? > - struct wined3d_display_mode original_mode; > + struct wined3d_display_mode original_mode, d3d_mode; I might have just gone for "mode", but I don't care strongly.

1 0

Re: [PATCH 1/2] ole32/tests: Release() doesn't return HRESULT code
by Marvin 19 Nov '14

19 Nov '14

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=10342 Your paranoid android. === wvistau64 (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === w8 (32 bit moniker) === moniker: unhandled exception c0000005 at 00425FC9 === wvistau64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004209EA === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 00000000004209EA

2 1

Re: ole32: Simplify a function by removing no-op code (PVS-Studio).
by Sebastian Lackner 19 Nov '14

19 Nov '14

On 19.11.2014 09:26, Michael Stefaniuc wrote: > MSHLFLAGS_NORMAL is 0. > --- > dlls/ole32/stubmanager.c | 19 +------------------ > 1 file changed, 1 insertion(+), 18 deletions(-) > > diff --git a/dlls/ole32/stubmanager.c b/dlls/ole32/stubmanager.c > index 96d710d..1aca924 100644 > --- a/dlls/ole32/stubmanager.c > +++ b/dlls/ole32/stubmanager.c > @@ -536,7 +536,6 @@ HRESULT ipid_get_dispatch_params(const IPID *ipid, APARTMENT **stub_apt, > /* returns TRUE if it is possible to unmarshal, FALSE otherwise. */ > BOOL stub_manager_notify_unmarshal(struct stub_manager *m, const IPID *ipid) > { > - BOOL ret = TRUE; > struct ifstub *ifstub; > > if (!(ifstub = stub_manager_ipid_to_ifstub(m, ipid))) > @@ -545,23 +544,7 @@ BOOL stub_manager_notify_unmarshal(struct stub_manager *m, const IPID *ipid) > return FALSE; > } > > - EnterCriticalSection(&m->lock); > - > - /* track normal marshals so we can enforce rules whilst in-process */ > - if (ifstub->flags & MSHLFLAGS_NORMAL) > - { > - if (m->norm_refs) > - m->norm_refs--; > - else > - { > - ERR("attempted invalid normal unmarshal, norm_refs is zero\n"); > - ret = FALSE; > - } > - } > - > - LeaveCriticalSection(&m->lock); > - > - return ret; > + return TRUE; > } > > /* handles refcounting for CoReleaseMarshalData */ > Although logically correct, I am not sure if this is what it should look like. In ole32/marshal for example there is also: --- snip --- if (flags & MSHLFLAGS_TABLEWEAK) TRACE(" MSHLFLAGS_TABLEWEAK"); if (!(flags & (MSHLFLAGS_TABLESTRONG|MSHLFLAGS_TABLEWEAK))) TRACE(" MSHLFLAGS_NORMAL"); if (flags & MSHLFLAGS_NOPING) TRACE(" MSHLFLAGS_NOPING"); --- snip --- This could probably mean that fixing the if condition is a more correct solution, but I don't know that part well enough.

2 1

Re: [PATCH 1/2] mmdevapi: allow GetPropValue function in audio drivers
by Nikolay Sivov 19 Nov '14

19 Nov '14

On 18.11.2014 20:59, Mark Harmstone wrote: > + if (SUCCEEDED(hr)) > + { > + MMDevice_SetPropValue(id, flow, prop, &pv); > + > + if (pv.vt == VT_LPWSTR) > + HeapFree(GetProcessHeap(), 0, pv.u.pwszVal); > + } > + out->vt = VT_LPWSTR; > + out->u.pwszVal = HeapAlloc(GetProcessHeap(), 0, 256 * sizeof(WCHAR)); This is a wrong way dealing with PROPVARIANT, you need to use PropVariantClear() and InitPropVariantFromString() - PROPVARIANT implies CoTaskMemAlloc/CoTaskMemFree memory management.

1 0

Re: [PATCH 6/6] wined3d: Restore the display mode on focus change.
by Marvin 19 Nov '14

19 Nov '14

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=10336 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2446: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2451: Test failed: The focus window is active. device.c:2459: Test failed: Got unexpected hr 0x88760869. device.c:2465: Test failed: Got unexpect screen size 800x600. device.c:2485: Test failed: Got unexpect screen size 800x600. device.c:2621: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:2997: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3001: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3024: Test failed: Failed to reset device, hr 0x88760868. device.c:3028: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3032: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3046: Test failed: Failed to set foreground window. device.c:3050: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:3054: Test failed: Expected device window extended style 0x108, got 0x100.

1 0

Re: [PATCH 4/6] d3d8/tests: Test mode restoration on focus loss.
by Marvin 19 Nov '14

19 Nov '14

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=10334 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2446: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2451: Test failed: The focus window is active. device.c:2459: Test failed: Got unexpected hr 0x88760869. device.c:2465: Test failed: Got unexpect screen size 800x600. device.c:2485: Test failed: Got unexpect screen size 800x600. device.c:2621: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:2997: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3001: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3024: Test failed: Failed to reset device, hr 0x88760868. device.c:3028: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:3032: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3046: Test failed: Failed to set foreground window. device.c:3050: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:3054: Test failed: Expected device window extended style 0x108, got 0x100.

1 0

Re: [PATCH 2/2] winealsa: implement GetPropValue and return device path
by Nikolay Sivov 18 Nov '14

18 Nov '14

On 18.11.2014 20:59, Mark Harmstone wrote: > --- a/dlls/winealsa.drv/Makefile.in > +++ b/dlls/winealsa.drv/Makefile.in > @@ -1,5 +1,5 @@ > MODULE = winealsa.drv > -IMPORTS = uuid ole32 advapi32 > +IMPORTS = uuid ole32 advapi32 user32 > DELAYIMPORTS = winmm > EXTRALIBS = $(ALSA_LIBS) If you need this only for wsprintfW() you could try sprintfW() from include/wine/unicode.h.

1 0

Re: [PATCH 1/2] mshtml: Added support for IHTMLFrameBase::put_src call on detached element.
by Marvin 18 Nov '14

18 Nov '14

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=10324 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: [PATCH 5/6] ddraw/tests: Test messages on focus loss (v2).
by Henri Verbeet 18 Nov '14

18 Nov '14

On 17 November 2014 21:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -2291,6 +2320,18 @@ static void test_coop_level_mode_set(void) > user32_rect.left, user32_rect.top, user32_rect.right, user32_rect.bottom, > r.left, r.top, r.right, r.bottom); > > + expect_messages = exclusive_focus_loss_messages; > + SetForegroundWindow(GetDesktopWindow()); > + ok(!expect_messages->message, "Expected message %#x, but didn't receive it.\n", expect_messages->message); This fails for me on Windows: ddraw1.c:2295: Test failed: Expected message 0x46, but didn't receive it.

1 0

Re: [3/6] user32/tests: Reenable test function for WM_GETTEXT.
by Marvin 18 Nov '14

18 Nov '14

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=10317 Your paranoid android. === w2008s64 (64 bit win) === win.c:3367: Test failed: hwnd 00000000000100F4 message 0118

2 1

Re: configure: Fix detection of gnutls on Ubuntu 14.10.
by Nicolas Le Cam 18 Nov '14

18 Nov '14

2014-11-17 9:37 GMT+01:00 Sebastian Lackner <sebastian(a)fds-team.de>: > Someone asked me to submit this, although its very Ubuntu specific. > > On some Ubuntu versions there only exists a package where libgnutls was renamed to libgnutls-deb0. As an effect ./configure fails to detect it properly because it compares the exact soname. > > http://packages.ubuntu.com/precise/amd64/libgnutls28/filelist > http://packages.ubuntu.com/utopic/amd64/libgnutls-deb0-28/filelist > > --- > configure.ac | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > Hi Sebastian, This also fixes libgnutls detection on Debian testing (and futur Jessie) and derivatives. What about [[libgnutls\$-deb[[0-9]]\$\\{0,1\\}]] or [[libgnutls\$-[[0-9A-Za-z]]\+\$\\{0,1\\}]] instead. I don't think the debian specific soname will bump too often but it could avoid the need for another patch. -- Nicolas Le Cam

2 1

Re: [PATCH 4/6] d3d8/tests: Test style changes on focus loss.
by Marvin 17 Nov '14

17 Nov '14

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=10310 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2364: Test failed: Expected message 0x46 for window 0, but didn't receive it. device.c:2369: Test failed: The focus window is active. device.c:2373: Test failed: Got unexpected hr 0. device.c:2379: Test failed: Got unexpected hr 0. device.c:2393: Test failed: Got unexpected hr 0. device.c:2523: Test failed: Expected foreground window 000501B8, got 0002004C. device.c:2899: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2903: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2926: Test failed: Failed to reset device, hr 0x88760868. device.c:2930: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2934: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2948: Test failed: Failed to set foreground window. device.c:2952: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:2956: Test failed: Expected device window extended style 0x108, got 0x100.

1 0

Re: [PATCH 3/6] d3d8/tests: Test messages on focus loss (v2).
by Marvin 17 Nov '14

17 Nov '14

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=10309 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2364: Test failed: Expected message 0x46 for window 0, but didn't receive it. device.c:2369: Test failed: The focus window is active. device.c:2373: Test failed: Got unexpected hr 0. device.c:2379: Test failed: Got unexpected hr 0. device.c:2393: Test failed: Got unexpected hr 0. device.c:2523: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:2898: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2902: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2925: Test failed: Failed to reset device, hr 0x88760868. device.c:2929: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2933: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3301: Test failed: Failed to reset device. device.c:3308: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 512, 384}. device.c:3316: Test failed: Expected wndproc != 0x411620.

1 0

Re: cryptext: add stubs for CryptExtAddPFX/CryptExtAddPFXW
by Nikolay Sivov 17 Nov '14

17 Nov '14

On 17.11.2014 22:21, Austin English wrote: > +HRESULT WINAPI CryptExtAddPFX(LPCSTR filename) > +{ > + FIXME("stub: %s\n", debugstr_a(filename)); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} Return type and error code don't match here. If it should be HRESULT use E_NOTIMPL, otherwise return type should be DWORD or similar.

1 0

Re: [PATCH 2/2] mshtml: Added IHTMLStyleSheet::cssText tests.
by Marvin 17 Nov '14

17 Nov '14

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=10298 Your paranoid android. === w2000pro (32 bit dom) === dom: unhandled exception c0000005 at 780104AC

1 0

Re: [PATCH 2/7] d3d9/tests: Test messages on focus loss.
by Alexandre Julliard 17 Nov '14

17 Nov '14

Stefan Dösinger <stefan(a)codeweavers.com> writes: > Resolution changing behavior will be tested in a separate patch. > --- > dlls/d3d9/tests/d3d9ex.c | 277 ++++++++++++++++++++++++++++---------------- > dlls/d3d9/tests/device.c | 293 +++++++++++++++++++++++++++++++---------------- > 2 files changed, 375 insertions(+), 195 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M d3d9.dll -p d3d9_test.exe.so d3d9ex && touch d3d9ex.ok d3d9ex.c:1656: Tests skipped: This GPU supports SM3, skipping unsupported shader test. d3d9ex.c:1942: Test failed: Expected message 0x6 for window 0x1, but didn't receive it, i=0. d3d9ex.c:1964: Test failed: Got unexpected hr 0x8760878, i=0. d3d9ex.c:1942: Test failed: Expected message 0x6 for window 0x1, but didn't receive it, i=1. d3d9ex.c:1964: Test failed: Got unexpected hr 0x8760878, i=1. make: *** [d3d9ex.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [PATCH 5/5] d3d10core/tests: Port alpha_test() to d3d10core.
by Marvin 17 Nov '14

17 Nov '14

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=10295 Your paranoid android. === w8 (32 bit visual) === visual.c:2635: Test failed: unexpected colortable on offscreen surface

1 0

Re: Update on MSNet
by Susan Cragin 14 Nov '14

14 Nov '14

You can now ask that or any other question. I just asked about the licenses, Page 6. http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.a…

2 1

Update on MSNet
by Susan Cragin 14 Nov '14

14 Nov '14

I'm sure you know this, but thought I would pass this along. MSNet framework is open-source. http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-source.a… An article I read said that MS has committed to developing linux and mac versions, but I don't see where MS has committed money to it. Keep up the good work! Susan

3 2

Re: [2/2] ntdll: Implement Rtl[Add|Remove]VectoredContinueHandler semi-stubs.
by Marvin 14 Nov '14

14 Nov '14

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=10262 Your paranoid android. === w2000pro (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:486: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:486: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:486: Test failed: 42: Wrong exception address 7751ED97/003C0001 === w2008s64 (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 002C0000/002C0001 exception: unhandled exception 80000004 at 002C0000 exception.c:486: Test failed: 42: Wrong exception address 77E5ED97/002C0001 === w7u (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 002F0000/002F0001 exception: unhandled exception 80000004 at 002F0000 exception.c:486: Test failed: 42: Wrong exception address 77CDE34F/002F0001 === w8 (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 003E0000/003E0001 exception: unhandled exception 80000004 at 003E0000 exception.c:486: Test failed: 42: Wrong exception address 77174D17/003E0001

1 0

Re: [1/2] ntdll/tests: Add basic tests for Rtl[Add|Remove]VectoredContinueHandler.
by Marvin 14 Nov '14

14 Nov '14

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=10261 Your paranoid android. === w2000pro (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 00950000/00950001 exception: unhandled exception 80000004 at 00950000 exception.c:486: Test failed: 42: Wrong exception address 7C5C20B0/00950001 === wxppro (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 00A30000/00A30001 exception: unhandled exception 80000004 at 00A30000 exception.c:486: Test failed: 42: Wrong exception address 7C80DF3C/00A30001 === wvistau64 (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 00350000/00350001 exception: unhandled exception 80000004 at 00350000 exception.c:486: Test failed: 42: Wrong exception address 7751ED97/00350001 === w2008s64 (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 003D0000/003D0001 exception: unhandled exception 80000004 at 003D0000 exception.c:486: Test failed: 42: Wrong exception address 77E5ED97/003D0001 === w7u (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 003C0000/003C0001 exception: unhandled exception 80000004 at 003C0000 exception.c:486: Test failed: 42: Wrong exception address 77CDE34F/003C0001 === w8 (32 bit exception) === exception.c:486: Test failed: 42: Wrong exception address 003E0000/003E0001 exception: unhandled exception 80000004 at 003E0000 exception.c:486: Test failed: 42: Wrong exception address 77174D17/003E0001

1 0

Re: [PATCH 5/7] d3d8/tests: Test style changes on focus loss.
by Marvin 14 Nov '14

14 Nov '14

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=10250 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2361: Test failed: Expected message 0x6 for window 0x1, but didn't receive it. device.c:2366: Test failed: The focus window is active. device.c:2370: Test failed: Got unexpected hr 0. device.c:2372: Test failed: Got unexpected hr 0. device.c:2383: Test failed: Got unexpected hr 0. device.c:2513: Test failed: Expected foreground window 000B00CA, got 0002004C. device.c:2889: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2893: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2916: Test failed: Failed to reset device, hr 0x88760868. device.c:2920: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2924: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2938: Test failed: Failed to set foreground window. device.c:2942: Test failed: Expected device window style 0x34cf0000, got 0x4cf0000. device.c:2946: Test failed: Expected device window extended style 0x108, got 0x100.

1 0

Re: [PATCH 4/7] d3d8/tests: Test messages on focus loss.
by Marvin 14 Nov '14

14 Nov '14

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=10249 Your paranoid android. === w8 (32 bit device) === device.c:1181: Test failed: TestCooperativeLevel failed, hr 0x88760868. device.c:1226: Test failed: Reset failed, hr 0x88760868. device.c:1228: Test failed: TestCooperativeLevel failed, hr 0x88760869. device.c:1232: Test failed: Got unexpected value 0 for D3DRS_LIGHTING. device.c:1239: Test failed: D3DVIEWPORT->X = 10, expected 0. device.c:1240: Test failed: D3DVIEWPORT->Y = 20, expected 0. device.c:1241: Test failed: D3DVIEWPORT->Width = 400, expected 800. device.c:1242: Test failed: D3DVIEWPORT->Height = 300, expected 600. device.c:1243: Test failed: D3DVIEWPORT->MinZ = 2.00000003e-001, expected 0. device.c:1244: Test failed: D3DVIEWPORT->MaxZ = 3.00000012e-001, expected 1. device.c:1249: Test failed: Screen width is 640, expected 800. device.c:1250: Test failed: Screen height is 480, expected 600. device.c:1256: Test failed: Back buffer width is 640, expected 800. device.c:1258: Test failed: Back buffer height is 480, expected 600. device.c:1288: Test failed: Screen width is 640, expected 1024. device.c:1289: Test failed: Screen height is 480, expected 768. device.c:2361: Test failed: Expected message 0x6 for window 0x1, but didn't receive it. device.c:2366: Test failed: The focus window is active. device.c:2370: Test failed: Got unexpected hr 0. device.c:2372: Test failed: Got unexpected hr 0. device.c:2383: Test failed: Got unexpected hr 0. device.c:2513: Test failed: Expected foreground window 000301BA, got 0002004C. device.c:2888: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2892: Test failed: Expected device window extended style 0x108, got 0x100. device.c:2915: Test failed: Failed to reset device, hr 0x88760868. device.c:2919: Test failed: Expected device window style 0x14cf0000, got 0x4cf0000. device.c:2923: Test failed: Expected device window extended style 0x108, got 0x100. device.c:3291: Test failed: Failed to reset device. device.c:3298: Test failed: Expected {0, 0, 1024, 768}, got {0, 0, 512, 384}. device.c:3306: Test failed: Expected wndproc != 0x413100.

1 0

Re: winemac: WS_EX_DLGMODALFRAME shouldn't prevent the window being resizeable.
by Ken Thomases 13 Nov '14

13 Nov '14

Hi, On Nov 13, 2014, at 3:26 AM, Huw Davies <huw(a)codeweavers.com> wrote: > --- > dlls/winemac.drv/window.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winemac.drv/window.c b/dlls/winemac.drv/window.c > index e61a517..54bd56e 100644 > --- a/dlls/winemac.drv/window.c > +++ b/dlls/winemac.drv/window.c > @@ -72,12 +72,12 @@ static void get_cocoa_window_features(struct macdrv_win_data *data, > if (ex_style & WS_EX_TOOLWINDOW) wf->utility = TRUE; > } > } > - if (ex_style & WS_EX_DLGMODALFRAME) wf->shadow = TRUE; > - else if (style & WS_THICKFRAME) > + if (style & WS_THICKFRAME) > { > wf->shadow = TRUE; > if (!data->shaped) wf->resizable = TRUE; > } > + else if (ex_style & WS_EX_DLGMODALFRAME) wf->shadow = TRUE; > else if ((style & (WS_DLGFRAME|WS_BORDER)) == WS_DLGFRAME) wf->shadow = TRUE; > } I think that's the correct logic, but it would be better to separate out setting resizable and shadow. The shadow stuff can be a single "if" with the conditions ORed together. Resizable can be a single "if" or even a simple assignment of a boolean expression. Thanks, Ken

1 1

RE: [PATCH] reg.exe: Modernise print functions
by Hugh McMaster 13 Nov '14

13 Nov '14

On Monday, 10 November 2014, Jonathan Vollebregt wrote: >> WCHAR msg_buffer[1024]; >No easy way to get the expected size and dynamically allocate the output I take it? >I looked into it before but besides _vscprintf (In msvcrt, which we're >not allowed to use) there doesn't seem to be a way to get the expected >output size besides perhaps growing the buffer over and over again until >it fits (Which seems inefficient for a simple printing function) One possible way would be to avoid using vsnprintfW() and pass everything through to output_vprintf(). static void __cdecl reg_printfW(const WCHAR* msg, ...) { __ms_va_list va_args; __ms_va_start(va_args, msg); output_vprintf(msg, va_args); __ms_va_end(va_args); } This would have the advantage of using FormatMessage() to allocate memory. But we would have to replace all format specifiers (four or five?) with their FormatMessage() equivalents. static const WCHAR unhandled[] = {'U','n','h','a','n','d','l','e','d',' ','T','y','p','e',' ','0','x','%','x',' ',' ','d','a','t','a',' ','%','s','\n',0}; becomes static const WCHAR unhandled[] = {'U','n','h','a','n','d','l','e','d',' ','T','y','p','e',' ','0','x','%','1','!','x','!',' ',' ','d','a','t','a',' ','%','2','\n',0};

3 4

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