- wine-devel - winehq.org

Re: [PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 4).
by Stefan Dösinger 24 Jun '15

24 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, One I don't like here is the hardcoded DDSCAPS_SYSTEMEMORY for the Z buffer. You need it on Windows because of the RGB device and Wine doesn't check, so it kinda works. But I recommend to do something like this: BOOL use_sysmem_zbuffer; ... hr = IDirect3DRM2_CreateDeviceFromSurface(d3drm2, &driver, ddraw, surface, &device2); hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); hr = IDirect3DDevice2_GetRenderTarget(d3ddevice2, &d3drm_surface); hr = IDirectDrawSurface_GetAttachedSurface(d3drm_surface, &caps, &ds); hr = IDirectDrawSurface_GetSurfaceDesc(ds, &desc); use_sysmem_zbuffer = desc->ddsCaps.dwCaps & DDSCAPS_SYSTEMMEMORY; ... /* Release everything */ /* Create new sysmem surface */ when creating the new Z buffer set DDSCAPS_SYSTEMMEMORY only if use_sysmem_zbuffer is true. Another thing to test: After destroying the d3drm device is the Z buffer removed from the surface when (a) d3drm created it and (b) you created it? Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVicXHAAoJEN0/YqbEcdMw73gP/3wLEdptNIWr2IFNXJHoSZ15 2g3annULMUw++NvXuBXY1RJdUiR0UQxbGyRNJtFzl8KN66lbl2DOY9/ePkgahIbB 0XKedAtS8F5zoLwRHrbZ/VGSI5Kv8ClHSi0F+jZ5Og9TvwqYKC40vNaBC2WXlSHL KSmOzilln0xDFPecaqyIwbLNO7y1DBnQ7sncLgGCuyxrWM8lK0vmXcAxubS5JyJJ Hd0chD6+EpjxisVWZUVNLFV1HEN9zyL6VDSYcJnNNp9ufGKh6wAoFcywx1vyQTsX tiicEYlW90rvhM2dIZ/m6EcJsR/n6E4iMlj2S4yq9Kc4jySMaC0bYa0B4vPQbbaj YUcQ10qmuH/saROVPjjwjT5O1xISVZ2OOlk3PQYbwVSa1afOMU0ZZu5xNYmkRJ71 21r9cBqePMtIzWixxq+5DiYIRaSDelODlGD8P+LdfYu51DZK3oi1GK0vwX46wHmX M6S6i583uj//ZaZAVG/iCkZ9IPrnkqUnWe8WVGqy1KKJ/e/goq8eQhK9bUHz0GCM BCaklF368VarJWQ0S2ggtdZ006cnc+aqOlfJTRA4UoSfQGU6ACne/blCeJBIGMwv 4mwtvNQvZIvoO6sUW+kmU7T6vCsyxVGfVq96csPbqNvSlidLl8H8IN7f8DK65feW w4s6zvEsdURxeHfcOUNL =bY5s -----END PGP SIGNATURE-----

2 2

Re: [2/2] msimtf: Add stub implementation for IActiveIMMMessagePumpOwner.
by Nikolay Sivov 24 Jun '15

24 Jun '15

On 24.06.2015 0:48, Thomas Faber wrote: > +static HRESULT WINAPI ActiveIMMApp_IActiveIMMMessagePumpOwner_QueryInterface(IActiveIMMMessagePumpOwner* iface, > + REFIID iid, LPVOID *ppvOut) > +{ > + ActiveIMMApp *This = impl_from_IActiveIMMMessagePumpOwner(iface); > + return IActiveIMMApp_QueryInterface(&This->IActiveIMMApp_iface, iid, ppvOut); > +} It's usually up to author, but I'll still mention this - no need to prefix function names with ActiveIMMApp_ because there's no other IActiveIMMMessagePumpOwner implementation, so names won't collide. It would be nice to have a simple test too, to make sure QI supports this interface, but as we don't have tests dir at all for this module it could be a separate patch I guess.

2 1

Re: [1/2] dimm.idl: Add IActiveIMMMessagePumpOwner.
by Nikolay Sivov 24 Jun '15

24 Jun '15

What's a reason for having it declared like that: -- + HRESULT OnTranslateMessage([in] const struct tagMSG *pMsg); --- Why not use MSG*?

2 3

Re: d3dcompiler: Add D3DReadFileToBlob, D3DWriteBlobToFile, , D3DCompileFromFile, D3DCompile2 stubs
by Matteo Bruni 24 Jun '15

24 Jun '15

2015-06-23 10:41 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Currently the code for d3dcompiler_*dll's is in the _43 version. > > However these function belong in d3dcompiler_46+ > > So, > 1. Is it ok to use private functions? I don't know all the implications of that but it doesn't seem to be necessarily wrong. > If not, how should it be done? Keep in mind that d3d9, d3d10, x_input will > have the same issue at some point. Not sure what you mean with d3d9 here. Did you mean d3dx9? > 2. Could it be done like the msvrt* libraites? However since the structures > haven't changed between versions maybe this isn't the best way. There are / have been a few bugs reported for d3dx9 with applications failing to cope with forwarded functions (e.g. https://bugs.winehq.org/show_bug.cgi?id=21817) and I imagine similar problems might also happen with d3dcompiler so that would be a point in favor of this solution. Moreover, in general each native d3dcompiler_xx (AND each d3dx9_xx!) version has a separate copy of the HLSL compiler inside and each one has a different version of the compiler. That means you will get things like https://bugs.winehq.org/show_bug.cgi?id=33770#c7 unless we can generate different code for different d3dcompiler_xx.dll versions. Another one of those I know of is that functions inside ASCII effect files can be "overloaded" with multiple implementations for different shader versions. In older d3dx9 you specify the target version by spelling it out in the function definition, but that changed at some point and the older syntax just doesn't work on newer HLSL compiler versions. So I think this is the route we want to take eventually. Maybe your patch is fine for the time being though. > 3. Move the code the latest DLL. That would work but notice that the same thing might (will?) repeat after MS releases new versions of d3dcompiler_xx.dll with new exports. BTW, I should have asked this earlier: what do you need those newer d3dcompiler_xx.dlls for? AFAIU those versions > 43 are never installed in system32 and applications are supposed to just bring a copy in their application directory (e.g. see the "Redistribution" section in http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.a… or point 6c in https://msdn.microsoft.com/en-us/library/windows/desktop/ee663275%28v=vs.85…).

2 1

Re: [PATCH 1/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 4).
by Stefan Dösinger 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Looks pretty good, there are 2 minor issues left (see below) and 3 code style things: Am 2015-06-23 um 20:19 schrieb Aaryaman Vasishta: > +BOOL primary_surface_found = FALSE; Please make it static. Also no need to initialize global variables, they're set to zero by the compiler. (Same as static variables inside a function). > + if ((desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE) == DDSCAPS_PRIMARYSURFACE) desc->ddsCaps.dwCaps & DDSCAPS_PRIMARYSURFACE is enough in this case as there's only one flag. > + clipper = context; > + ok(clipper == d3drm_clipper, "Expected clipper returned == %p, got %p.\n", clipper, d3drm_clipper); > + IDirectDrawClipper_Release(d3drm_clipper); ok(clipper == context, "..."); should work, no need to have an extra variable for this. > +static void test_create_device_from_clipper(void) > +{ This function tests IDirect3DRM2 / IDirect3DRMDevice2. Think about how you want to add version 1 and 3 tests. Either add them in the same function or create 3 test functions. I prefer the latter case, but then you may want to name them test_create_device_from_clipper{1,2,3} or similar. > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, 300, 200, &device2); > + ok(hr == D3DRM_OK, "Cannot create IDirect3DRMDevice2 interface (hr = %x).\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + todo_wine ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %u , ref2 = %u.\n", ref1, ref2); > + todo_wine ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %u , cref2 = %u.\n", cref1, cref2); Please also show that the d3drm2 refcount is untouched. This also applies to patches 2 and 3. > + hr = IDirectDraw_SetDisplayMode(ddraw, 640, 480, 16); > + ok(hr == DD_OK, "Cannot set display mode to 16bpp (hr = %x).\n", hr); Please use the current desktop width and height here (i.e., what was returned from GetDisplayMode earlier). Setting a lower resolution has the tendency to screw up window and desktop icon positioning. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVib/vAAoJEN0/YqbEcdMw8UoP+gLjxDhe3SjrslH3I0h3cM0M W9KbODhgTmn+C2j3a2rOXvbllAXkjAI9oSnbKp3msE4uJw7GT5QOx+y1828xVF54 RhxoQsYJuXAptAzzlwOS9Dpj5f8sebfj8AG3KENEeMBaKPJFnuER2AHD7o0Bl9Td LVXbSWjvkhsGIRSW2JWKVFQIRdCKaeiRciA0ScH/yQxxL0h/1BOdoLqzc5+Nv6wW /drwTUVR0MQrqzNt3qKPnhNNe2CXS7DQvc4KA1s0WsNxTbrl1orKXDclls1UhL5L iIIJtVF0H7jPE5kF5yVsW0uyjojNI7EnEbVtQQHecFV1UfLQQhykIbw3Vc/tg8Up lpkaEtQvSUYsJMIWKyG9nTAsoz1ZAeb8k97YH8SS/HtG3dZzOThLkPjfbpOPRxeK 07d2P+I4FkyXdiDNZ/dzXIuJUGoBriXM/rPJFqnHWrOm3Lor6GqhKXE+SxOpPeOA rUcVYfd/XEJPT+7PIOdeu/C9ldUPjVmV3BpWze0oXaj9noLJUWojk4E0emsazaUB bXXcJfj0r65SnFUUbxmwjZK50OdF36iku3Oohgl7kpmatWF3IN1g9BmgoDnXuHi8 8xVAi+6OQm7+oU04kZi/4KHPAg41FcMBnxtuxYBASn0NZvaY002ZMWpfCAbdV6pX LouyQXU2ct2Y5h78u9FG =F7Cf -----END PGP SIGNATURE-----

2 1

Re: [PATCH 2/2] user32: Erase backgrounds of owner-drawn buttons with the default color.
by Alexandre Julliard 23 Jun '15

23 Jun '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -268,13 +268,7 @@ LRESULT ButtonWndProc_common(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, > { > HDC hdc = (HDC)wParam; > RECT rc; > - HBRUSH hBrush; > - HWND parent = GetParent(hWnd); > - if (!parent) parent = hWnd; > - hBrush = (HBRUSH)SendMessageW(parent, WM_CTLCOLORBTN, (WPARAM)hdc, (LPARAM)hWnd); > - if (!hBrush) /* did the app forget to call defwindowproc ? */ > - hBrush = (HBRUSH)DefWindowProcW(parent, WM_CTLCOLORBTN, > - (WPARAM)hdc, (LPARAM)hWnd); > + HBRUSH hBrush = GetSysColorBrush(COLOR_BTNFACE); This would need a more convincing test. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: shell32/tests: Don't leave behind open explorer windows.
by Marvin 23 Jun '15

23 Jun '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=14594 Your paranoid android. === w2003std (32 bit progman_dde) === progman_dde.c:377: Test failed: Window "C:\Documents and Settings\All Users\Start Menu\Programs\Group1" was not created in 45 seconds - assumed failure. [S_G:12] === w7u (32 bit progman_dde) === progman_dde.c:519: Test failed: DeleteGroup Group1: Expected Error DMLERR_NO_ERROR, received DMLERR_EXECACKTIMEOUT. [D_G:13] === wvistau64 (64 bit progman_dde) === progman_dde.c:571: Test failed: DeleteItem f2g1Name.lnk: Expected Error DMLERR_NO_ERROR, received DMLERR_EXECACKTIMEOUT. [D_I:5]

1 0

Re: [PATCH 1/2] user32: Send BM_SETCHECK before WM_CAPTURECHANGED and add tests.
by Marvin 23 Jun '15

23 Jun '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=14585 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:10547: Test failed: expected PeekMessage to return FALSE, got 1

1 0

Re: ntdll: Randomize security cookie when available
by Alexandre Julliard 23 Jun '15

23 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -3620,7 +3620,30 @@ typedef struct _FPO_DATA { > WORD cbFrame : 2; > } FPO_DATA, *PFPO_DATA; > > -typedef struct _IMAGE_LOAD_CONFIG_DIRECTORY { > +typedef struct _IMAGE_LOAD_CONFIG_DIRECTORY64 { > + DWORD Size; > + DWORD TimeDateStamp; > + WORD MajorVersion; > + WORD MinorVersion; > + DWORD GlobalFlagsClear; > + DWORD GlobalFlagsSet; > + DWORD CriticalSectionDefaultTimeout; > + ULONGLONG DeCommitFreeBlockThreshold; > + ULONGLONG DeCommitTotalFreeThreshold; > + ULONGLONG LockPrefixTable; > + ULONGLONG MaximumAllocationSize; > + ULONGLONG VirtualMemoryThreshold; > + ULONGLONG ProcessAffinityMask; > + DWORD ProcessHeapFlags; > + WORD CSDVersion; > + WORD Reserved1; > + ULONGLONG EditList; > + ULONGLONG SecurityCookie; > + ULONGLONG SEHandlerTable; > + ULONGLONG SEHandlerCount; > +} IMAGE_LOAD_CONFIG_DIRECTORY64, *PIMAGE_LOAD_CONFIG_DIRECTORY64; > + > +typedef struct _IMAGE_LOAD_CONFIG_DIRECTORY32 { > DWORD Size; > DWORD TimeDateStamp; > WORD MajorVersion; You'll need to update the generated tests: gcc -c -o generated.o ../../../../wine/dlls/ntdll/tests/generated.c -I. \ -I../../../../wine/dlls/ntdll/tests -I../../../include -I../../../../wine/include -D__WINESRC__ \ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body \ -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret ../../../../wine/dlls/ntdll/tests/generated.c: In function ‘test_pack_IMAGE_LOAD_CONFIG_DIRECTORY’: ../../../../wine/dlls/ntdll/tests/generated.c:842:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:865:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:866:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:868:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:869:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:870:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:873:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:874:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:875:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:876:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:877:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:878:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:879:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:882:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:883:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:884:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:885:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:888:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:891:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:894:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:895:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:896:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:897:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:898:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:899:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:900:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:901:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:902:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c:903:5: error: size of unnamed array is negative ../../../../wine/dlls/ntdll/tests/generated.c: In function ‘test_pack_PIMAGE_LOAD_CONFIG_DIRECTORY’: ../../../../wine/dlls/ntdll/tests/generated.c:2108:5: error: size of unnamed array is negative Makefile:348: recipe for target 'generated.o' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32: Fix RegEnumValueW when enumerating long values.
by Bernhard Übelacker 23 Jun '15

23 Jun '15

Hello, please ignore this patch for now. It seems that systemfontfileenumerator_GetCurrentFontFile uses RegEnumValueW in a way not supported on Windows - with giving NULL parameters for value and/or val_count [1]. When RegEnumValueW is called with proper value parameter the problem with not returning correct count would not happen already. So, as far as I see, first all uses of RegEnumValue with NULL parameters for value or val_count need a fix. Kind regards, Bernhard [1] https://testbot.winehq.org/JobDetails.pl?Key=14533

4 5

[7/11]hidclass.sys: Implement HID devices
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hidclass.sys/Makefile.in | 1 + dlls/hidclass.sys/device.c | 560 ++++++++++++++++++++++++++++++++++++++++++ dlls/hidclass.sys/hid.h | 86 +++++++ dlls/hidclass.sys/main.c | 4 + 4 files changed, 651 insertions(+) create mode 100644 dlls/hidclass.sys/device.c

2 2

[2/11]hidclass.sys: add a wine native hid device driver service
by Aric Stewart 22 Jun '15

22 Jun '15

Allow for Minidriver registration --- configure | 2 + configure.ac | 1 + dlls/hidclass.sys/Makefile.in | 8 ++++ dlls/hidclass.sys/hid.h | 53 +++++++++++++++++++++++++ dlls/hidclass.sys/hidclass.sys.spec | 2 + dlls/hidclass.sys/main.c | 78 +++++++++++++++++++++++++++++++++++++ loader/wine.inf.in | 13 +++++++ 7 files changed, 157 insertions(+) create mode 100644 dlls/hidclass.sys/Makefile.in create mode 100644 dlls/hidclass.sys/hid.h create mode 100644 dlls/hidclass.sys/hidclass.sys.spec create mode 100644 dlls/hidclass.sys/main.c

2 2

[9/11]hidclass.sys: Add Plug-and-play interfaces
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hidclass.sys/Makefile.in | 4 +- dlls/hidclass.sys/descriptor.c | 1092 ++++++++++++++++++++++++++++++++++++++++ dlls/hidclass.sys/hid.h | 8 + dlls/hidclass.sys/main.c | 1 + dlls/hidclass.sys/pnp.c | 301 +++++++++++ 5 files changed, 1405 insertions(+), 1 deletion(-) create mode 100644 dlls/hidclass.sys/descriptor.c create mode 100644 dlls/hidclass.sys/pnp.c

2 2

Re: [1/2] msi/tests: Fix test failures on win2k3.
by Marvin 22 Jun '15

22 Jun '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=14545 Your paranoid android. === wvistau64 (32 bit install) === Failure running script in VM: timed out waiting for the child process === w8 (32 bit install) === The test timed out

1 0

Re: [PATCH 3/5] wined3d: Remove ffp_proj_control flag from the GLSL shader backend.
by Henri Verbeet 22 Jun '15

22 Jun '15

On 19 June 2015 at 00:07, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Using the GLSL shader backend implies GLSL vp and fp replacements, An argument could perhaps be made that it should, but currently that's not true. You can still use the the GLSL shader backend with e.g. fixed function fragment processing with some level of success. The only reason it doesn't happen much in practice is the way select_vertex_implementation() and select_fragment_implementation() are implemented, but that's external to the shader backend.

3 2

[4/11]hidclass.sys: Implement a report ring buffer
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hidclass.sys/Makefile.in | 1 + dlls/hidclass.sys/buffer.c | 166 ++++++++++++++++++++++++++++++++++++++++++ dlls/hidclass.sys/hid.h | 13 ++++ 3 files changed, 180 insertions(+) create mode 100644 dlls/hidclass.sys/buffer.c

2 1

Re: gdi32/tests: Japanese Win 7 uses MS Shell Dlg as its default GUI font.
by Akihiro Sagawa 22 Jun '15

22 Jun '15

Hello Huw, Could you improve commit c81ff0f8cfc1a7b6fa7546d8ffb656e290ef5e7e? I know this fixes longstanding test failure on Windows 7 testbot running with Japanese locale. But, the change leads to test failures on my Japanese Windows 7: > font.c:5799: Test failed: 4(1): expected height 15, got 12 > font.c:5808: 4(1): default gui font is MS UI Gothic As both systems are running with Japanese locale, I compared my Windows 7 settings with testbot's one. And, I found that testbot returns different GetSystemDefaultUILanguage() value. In other words, testbot returns 0x0409 (English US)[1], but my PC returns 0x0411 (Japanese). [1] https://testbot.winehq.org/JobDetails.pl?Key=14511&log_206=1#k206 I'm not sure if the configuration is on purpose, or not. However, the test needs to be updated on that point. Akihiro Sagawa

3 4

Re: [PATCH (resend)] winealsa: Make string "Unknown sound card" translatable.
by Alexandre Julliard 22 Jun '15

22 Jun '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > --- > dlls/winealsa.drv/Makefile.in | 4 +++- > dlls/winealsa.drv/mmdevdrv.c | 9 +++++++-- > dlls/winealsa.drv/resource.h | 19 +++++++++++++++++++ > dlls/winealsa.drv/winealsa.rc | 29 +++++++++++++++++++++++++++++ > 4 files changed, 58 insertions(+), 3 deletions(-) > create mode 100644 dlls/winealsa.drv/resource.h > create mode 100644 dlls/winealsa.drv/winealsa.rc Adding translation in drivers doesn't work very well, it needs some more makefile support. It would be better to do this some other way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winetest: Add SystemDefaultUILanguage setting to OS info.
by Akihiro Sagawa 22 Jun '15

22 Jun '15

On Sun, 21 Jun 2015 14:15:15 +0900, Akihiro Sagawa wrote: > Some of testbots have a different value as expected. And, a certain GDI > function seems to be affected by this setting. So, it's worth to be > logging. > --- > programs/winetest/main.c | 1 + > 1 file changed, 1 insertion(+) Please ignore this patch. I confirmed SystemDefaultUILanguage doesn't affect GDI functions. Akihiro Sagawa

1 0

Re: winedbg: Avoid direct comparison of enum with -1 in packet_set_breakpoint.
by Michael Stefaniuc 22 Jun '15

22 Jun '15

Hello Gerald, On 06/19/2015 11:48 PM, Gerald Pfeifer wrote: > clang 3.4.1 complains as follows when compiling this: > > gdbproxy.c:2147:23: warning: comparison of constant -1 with > expression of type 'enum be_xpoint_type' is always false > > I see two ways to address this: adding a dummy set to -1 to the > enum, or casting the enum to int before comparing against -1. > > The patch below implements the first approach; if you prefer, > I'll provide a patch for the other approach. adding an element be_xpoint_free to the enum is better than a cast. > > Gerald > --- > programs/winedbg/gdbproxy.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c > index dd63f7d..181b32a 100644 > --- a/programs/winedbg/gdbproxy.c > +++ b/programs/winedbg/gdbproxy.c > @@ -2144,7 +2144,7 @@ static enum packet_return packet_set_breakpoint(struct gdb_context* gdbctx) > /* really set the Xpoint */ > for (xpt = &gdbctx->Xpoints[NUM_XPOINT - 1]; xpt >= gdbctx->Xpoints; xpt--) > { > - if (xpt->type == -1) > + if ((int)xpt->type == -1) > { > if (be_cpu->insert_Xpoint(gdbctx->process->handle, > gdbctx->process->process_io, &gdbctx->context, > bye michael

1 0

[11/11]hidclass.sys: Add os x minidriver
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hidclass.sys/Makefile.in | 1 + dlls/hidclass.sys/hid.h | 3 + dlls/hidclass.sys/main.c | 6 + dlls/hidclass.sys/minidriver_osx.c | 546 +++++++++++++++++++++++++++++++++++++ 4 files changed, 556 insertions(+) create mode 100644 dlls/hidclass.sys/minidriver_osx.c

1 0

[10/11]include: add HID_REVISION
by Aric Stewart 22 Jun '15

22 Jun '15

--- include/ddk/hidclass.h | 2 ++ 1 file changed, 2 insertions(+)

1 0

[8/11]include: add IRP_MJ_POWER minor function codes
by Aric Stewart 22 Jun '15

22 Jun '15

--- include/ddk/wdm.h | 5 +++++ 1 file changed, 5 insertions(+)

1 0

[6/11]include: HID_XFER_PACKET to hidclass.h
by Aric Stewart 22 Jun '15

22 Jun '15

--- include/ddk/hidclass.h | 6 ++++++ 1 file changed, 6 insertions(+)

1 0

[5/11]include: new ddk/hidtypes.h include file
by Aric Stewart 22 Jun '15

22 Jun '15

--- include/ddk/hidtypes.h | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 include/ddk/hidtypes.h

1 0

[3/11]hidclass.sys: Implement helper IoCallMinidriver
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hidclass.sys/hid.h | 1 + dlls/hidclass.sys/main.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+)

1 0

[1/11]loader: add Dev Class for HID devices
by Aric Stewart 22 Jun '15

22 Jun '15

--- loader/wine.inf.in | 2 ++ 1 file changed, 2 insertions(+)

1 0

[14/14]hid: Implement HidP_GetScaledUsageValue
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++------ include/ddk/hidpi.h | 1 + 3 files changed, 48 insertions(+), 7 deletions(-)

1 0

[13/14]hid: Implement HidP_MaxUsageListLength
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidpi.h | 2 +- 3 files changed, 55 insertions(+), 2 deletions(-)

1 0

[12/14]hid: Implement HidD_GetAttributes
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidd.c | 20 +++++++++++++++++++- include/ddk/hidsdi.h | 9 +++++++++ 3 files changed, 29 insertions(+), 2 deletions(-)

1 0

[11/14]hid: Implement HidD_GetInputReport
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidd.c | 8 ++++++++ include/ddk/hidsdi.h | 1 + 3 files changed, 10 insertions(+), 1 deletion(-)

1 0

[10/14]hid: Implement HidD_GetPreparsedData and HidD_FreePreparsedData
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 4 ++-- dlls/hid/hidd.c | 25 +++++++++++++++++++++++++ include/ddk/hidclass.h | 9 +++++++++ include/ddk/hidsdi.h | 2 ++ 4 files changed, 38 insertions(+), 2 deletions(-)

1 0

[9/14]hid: Implement HidP_InitializeReportForID
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidpi.h | 1 + 3 files changed, 63 insertions(+), 1 deletion(-)

1 0

[8/14]hid: Implement HidP_GetUsageValue
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidpi.h | 1 + 3 files changed, 64 insertions(+), 1 deletion(-)

1 0

[7/14]hid: Implement HidP_GetUsages
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidpi.h | 1 + 3 files changed, 125 insertions(+), 1 deletion(-)

1 0

[6/14]hid: Implement HidP_GetValueCaps
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidpi.h | 2 ++ 3 files changed, 62 insertions(+), 1 deletion(-)

1 0

[5/14]hid: Implement HidP_GetButtonCaps
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidpi.h | 1 + include/wine/hid.h | 2 +- 4 files changed, 58 insertions(+), 2 deletions(-)

1 0

[4/14]hid: Implement HidP_GetCaps
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/Makefile.in | 1 + dlls/hid/hid.spec | 2 +- dlls/hid/hidp.c | 53 ++++++++++++++++ include/ddk/hidpi.h | 168 +++++++++++++++++++++++++++++++++++++++++++++++++++ include/ddk/hidsdi.h | 2 +- include/wine/hid.h | 80 ++++++++++++++++++++++++ 6 files changed, 304 insertions(+), 2 deletions(-) create mode 100644 dlls/hid/hidp.c create mode 100644 include/ddk/hidpi.h create mode 100644 include/wine/hid.h

1 0

[3/14]hid: translated HidD_ functions to their IOCTLs
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/hidd.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-)

1 0

[2/14]hid: break HidD_ functions out into their own module
by Aric Stewart 22 Jun '15

22 Jun '15

--- dlls/hid/Makefile.in | 1 + dlls/hid/hidd.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++ dlls/hid/main.c | 40 +------------------------------- 3 files changed, 67 insertions(+), 39 deletions(-) create mode 100644 dlls/hid/hidd.c

1 0

[1/14]include: add ddk/hidclass.h
by Aric Stewart 22 Jun '15

22 Jun '15

--- include/ddk/hidclass.h | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 include/ddk/hidclass.h

1 0

HID work, two sets of patches
by Aric Stewart 22 Jun '15

22 Jun '15

Hi all, So I have been working on HID support for the last few months. I have something ready for public review. It is not quite in shape to submit but since this is such a huge bit of work with so many moving pieces I thought it would be useful to have people able to help me make sure it works right. Answer to question #1, This is only implemented for Mac right now. That is because I know the mac HID stuff well and could do it. There will of course be a need for a linux minidriver as well, (like the mac minidriver) but I am not qualified to write that. I would be more than happy to help someone write it. Answer to question #2, No, this is not hooked up anywhere yet. Ideally it will get hooked up to be the bases for the winejoystick.drv, dinput, xinput and RawInput. I have a very rough implementation for winejoystick.drv but it is so rough that I am not presenting it yet. Answer to question #3, yes it works. I both have written my own HID client as well as the Microsoft hclient.exe test application and they work using this code as expected. Answer to question #4, No, this will most likely NOT support windows minidrivers. Mostly because of the lack of any sort of real plug and play support. There are some architecture bits that may be tricky with windows native minidrivers in .sys format. It is not outside the realm of doable eventually but I do not expect it to work right now. Finally, this is only the start. It is not implementing output or feature reports and there are still a lot of things to improve and implement. But I feel like I need to start getting this out into the public. Yes I will be submitting these and going through the whole process, but the more eyes and people willing to help me make these correct the better. That is why they are going to wine-devel first. So all comments welcome, but be kind. this was a lot of work and I am sure I made some stupid mistakes somewhere. -aric

1 0

Re: gdi32/freetype: Properly handle loading of FT_Long-sized types (Valgrind)
by Marc Bessières 21 Jun '15

21 Jun '15

Hi Nicolay, May I ask you a question on your patch? Why is the last line of the below extract still using reg_load_dword, and not reg_load_ftlong, while the cast was removed? It doesn't seem good to me, or there is something special about the flags? Cheers, Marc @@ -1541,10 +1549,10 @@ static void load_face(HKEY hkey_face, WCHAR *face_name, Family *family, void *bu else face->FullName = NULL; - reg_load_dword(hkey_face, face_index_value, (DWORD*)&face- >face_index); + reg_load_ftlong(hkey_face, face_index_value, &face->face_index); reg_load_dword(hkey_face, face_ntmflags_value, &face->ntmFlags); - reg_load_dword(hkey_face, face_version_value, (DWORD*)&face- >font_version); - reg_load_dword(hkey_face, face_flags_value, (DWORD*)&face->flags); + reg_load_ftlong(hkey_face, face_version_value, &face->font_version); + reg_load_dword(hkey_face, face_flags_value, &face->flags);

2 2

Re: server: return NULL from device_open_file on failure to allocate fd
by Sebastian Lackner 19 Jun '15

19 Jun '15

On 20.06.2015 00:22, Daniel Lehman wrote: > > Does this patch address a real issue or is it just by looking at the source? &file->obj should not lead to an invalid memory access because its just a more convenient way to do a type conversion. If file == NULL, then &file->obj will also be NULL. Of course its a matter of taste what is easier to read. Regards, Sebastian

2 1

Re: DInput axis mapping explanation
by Michael Gardner 19 Jun '15

19 Jun '15

Thank you, Aric! I have a couple more questions, if you have time to answer them. 1) Is Wine affected by the joystick mapping that can be done via jscal (and if not, why)? 2) How would I see the list of values as returned by the device, so I know what mapping to construct?

1 0

Re: [PATCH 5/5] wined3d: Add a setting for requesting OpenGL core profile usage.
by Henri Verbeet 19 Jun '15

19 Jun '15

On 19 June 2015 at 00:07, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -199,6 +200,14 @@ static BOOL wined3d_dll_init(HINSTANCE hInstDLL) > > if (hkey || appkey) > { > + if (!get_config_key( hkey, appkey, "UseCore", buffer, size)) > + { > + if (!strcmp(buffer,"enabled")) > + { > + TRACE("Requested OpenGL Core profile.\n"); > + wined3d_settings.use_core = TRUE; > + } > + } > if ( !get_config_key( hkey, appkey, "UseGLSL", buffer, size) ) > { > if (!strcmp(buffer,"disabled")) Would it make sense to express this in terms of the maximum (desktop) GL version to use instead? I imagine that at some point we'll want to use GL versions beyond 3.2, at which point it may be useful to have something a bit more flexible than just core/classic. > @@ -1711,6 +1709,7 @@ struct wined3d_gl_limits > > struct wined3d_gl_info > { > + BOOL legacy_gl; > DWORD glsl_version; > struct wined3d_gl_limits limits; > DWORD reserved_glsl_constants, reserved_arb_constants; This could probably just be an entry in the wined3d_gl_extension enum, which I suppose might have advantages if we need this information for building e.g. state or format tables.

2 2

Re: [PATCH 1/8] kernel32: Implement GetVolumePathName.
by Nikolay Sivov 19 Jun '15

19 Jun '15

> + const WCHAR fallbackpathW[] = { 'C',':','\\',0 }; This doesn't look right, could we make it dynamic using actual system drive? Same goes for tests, where you got hardcoded C:\ drive. According to docs this function should follow symlinks, will it potentially work with this implementation? Was it tested? I think it makes sense to submit tests first, maybe combining them a little, to have 1 tests patch instead of 4.

2 1

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Theodore Dubois 19 Jun '15

19 Jun '15

> First, yes, we do have hacks in CrossOver, but I think 'a lot' is > unfair. We really try to avoid those hacks, and we work hard to > eliminate them. For example, I reviewed our tracker that lists our > hacks. We have about 100 outstanding; in the last 6 months, we removed > 4 with upstream fixes, and added 1 new one. Further, we have long felt > that our diff with winehq was tragically large. But nicely, I can now > compare it to wine-staging, and claim that it is relatively modest > <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files > for wine-staging [1]. May I suggest you eliminate those hacks by merging them into the Wine codebase? Right now I have a feeling that Wine is wonderful, but Codeweavers is evil. It seems that this feeling is shared by many non-Codeweavers Wine developers. Codeweavers has done a lot of work on Wine, which I really appreciate, but I wish they would be much more open. I think there should, at least, be a public database listing all the hacks that are in Crossover. That way, I would know what the heck was going on inside those windowless walls. This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks. Not the Crossover-only ones like sendwndcmd.exe. Or the ones that can't be released because of NDAs. I mean the ones that would improve the vanilla Wine distribution. It seems possible to me that you're not releasing these hacks because they would improve vanilla Wine to the point where nobody would be willing to pay for Crossover anymore. If that is true, it's the other reason that I think Codeweavers is evil. I mean, can't you make enough money on consulting for companies that think that Crossover/Codeweavers is better because it costs more money? If there's no openness about what Crossover is doing to Wine, I just can't trust them to develop it. ~Theodore

20 29

Re: gdi32/tests: Japanese Win 7 uses MS Shell Dlg as its default GUI font.
by Marvin 19 Jun '15

19 Jun '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=14490 Your paranoid android. === wvistau64 (32 bit font) === The test timed out === wvistau64 (64 bit font) === The test timed out

2 1

Re: [etags] repair make etags
by Alexandre Julliard 18 Jun '15

18 Jun '15

marc.bessieres(a)mykolab.com writes: > @@ -68,7 +68,7 @@ TAGSFLAGS = --langmap='c:+.idl.l.rh,make:(Make*.in)' > > TAGS etags: > $(RM) TAGS > - (test -d .git && git ls-files || find -L $(top_srcdir) -name '*.[ch]' -print) | xargs etags -a $(TAGSFLAGS) > + (test -d .git && git ls-files '*.[chly]' '*.idl' || find -L $(top_srcdir) -name '*.[ch]' -print) | xargs etags -a This will make the results less useful. You could add different commands based on the available etags, though installing exuberant-ctags may be an easier fix... -- Alexandre Julliard julliard(a)winehq.org

2 1

d3drm patch feedback
by Stefan Dösinger 18 Jun '15

18 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Here's the feedback for the patch you posted on IRC: > + GUID driver = IID_IDirect3DRGBDevice; Do you need this? Can't you just pass &IID_IDirect3DRGBDevice to CreateDeviceFromClipper? It may generate a const warning though. > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface (hr = %x).\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper (hr = %x).\n", hr); Can you pass a NULL clipper? If this crashes, just put a comment in the test. What if the clipper has no HWND and no clip list? Call GetClipper on the render target and see if the clipper is assigned. > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, 300, 200, &device2); For the sake of completeness pass 0 width and height. I expect one of the two results: Either it returns an error, or d3drm starts to use the window dimensions for the render target now. > + todo_wine ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d , ref2 = %d\n", ref1, ref2); Minor detail: Use %u for unsigned. > + ok((surface_desc.dwWidth == 300) && (surface_desc.dwHeight == 200), "Expected surface dimentions = 300, 200, got %d, %d.\n", > + surface_desc.dwWidth, surface_desc.dwHeight); > + ok((surface_desc.ddsCaps.dwCaps & (DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE)) == (DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE), > + "Expected caps containing %x, got %x.\n", DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE, surface_desc.ddsCaps.dwCaps); > + expected_flags = DDSD_PIXELFORMAT | DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PITCH; > + ok(surface_desc.dwFlags == expected_flags, "Expected %x for flags, got %x.\n", expected_flags, surface_desc.dwFlags); Test the pixel format here. First query the current bpp with EnumDisplaySettings and check that the pixel format matches the screen properties. > + /* Check if ddraw supports change of display mode */ The comment is somewhat outdated. Either remove it or say something like "Test if the render target format follows the screen format". > + ok(surface_desc.ddpfPixelFormat.dwRGBBitCount == 16, "Expected 16bpp, got %dbpp.\n", > + surface_desc.ddpfPixelFormat.dwRGBBitCount); Similar to the %u -> %u above Once these are fixed the patch can go to wine-patches as far as I'm concerned. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVgt8QAAoJEN0/YqbEcdMwOTYP/jXwDY+gUs/zmAyqB5hJp8by FO0YSZsi0Z3QMMzfqenCy9+/PmqjMHyRPQvhM8CFpcdWsUi8bH6PzTiooAYOcvzf GXEnj46T1O0wiJfLK+RnzfvYNzITLWf2XK6ek1OtP1z6Y3JhADXwoLW/tSM+kKp7 Crih31t9ewiSMG5iebcSdviI59WrFtUHmS9Mdp5UnWVQB8smZII8c+VAOf/SmWZ1 cGKosFncJVNuXpF0fq5gWiy3m1VcJ1xoWsG1rXbrOzVFvpw+20twa1FgZm9Z6I3c Pxj2prH2Lz9u7tDZUr75dg3ucRPcUe2QP2bTwwBDDq4oaUZYKgXBLrz94AVZ/Y+j datcVFY7KwY2byGmxmO+0I+iWyj26CIg13jo20gqfRfjt92DFlfi5/Mm/e97rCa1 0V38s0kqN5o4rvU+QbUwHfvHIgr4kAFWZPjDmZd3YececQuoeC7FszND/43UD0tK MTd1Na3hFa5m6zO7oe4fPfGYX55tVhEzphiRkH4K0R0ZTxRsZGGqQoSFAHeAJDH6 0hPd3XjVHxSpHQNd8/8aFeOMJ8pBR+4MRUMcFBDn0XlDUYw0kUdvRkttKoNVCSGw H0BS00wj/fs/G4D/pCLEFEX7wF9qDM5O6xKQRoyXG3+i9oN+zdzCNMs6SV1J2Bci Jedz7Aw7+yAByiH/GePR =aa6D -----END PGP SIGNATURE-----

2 1

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Theodore Dubois 17 Jun '15

17 Jun '15

> While it seems Theodore didn't do his homework and didn't know about that source distribution, one of his point remains: > it's not a database, git, or something easily readable, just a blob Yes, I really hate that it’s a huge blob. I’m working on a little project to try and diff Crossover’s wine and wine 1.7.25, and identify all the hacks. The github repo is tbodt/crossover-wine, but I haven’t actually done any real work on it yet. Currently, it’s nothing but a fork of wine-mirror/wine. We’ll see when I get around to it. ~Theodore

1 0

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Theodore Dubois 17 Jun '15

17 Jun '15

I originally sent this email to Jeremy, but forgot to CC the mailing list. ~Theodore On Jun 16, 2015, at 1:48 PM, Theodore Dubois <tblodt(a)icloud.com> wrote: >> I'm obviously very sad that you perceive us as evil. Do you mind me >> asking where you got that feeling from? If there is an information >> source that is revealing all of our evil secrets, I'd like to know about >> it. <grin> > > I thought you were evil because I didn't realize that all your hacks are actually already public. (And those <evil grin>s.) I'm sorry. > >> All of our Wine code, including our hacks, is publicly released, here: >> https://www.codeweavers.com/products/faq/source/ > > I had seen that source page, but I didn't realize it contained all the hacks. I thought it was just the main Wine source code. > >> Um, nearly all of the work that we do on CrossOver is done by sending >> public emails to this mailing list. How is that not open? Or perhaps I >> should ask - what gave you the impression that we did not develop openly? > > I thought that because you were evil, you must have some non-public mailing list. I guess I was wrong. > > Well, now I don't feel CodeWeavers is evil anymore. You are doing some awesome work on Wine. Without it, Wine would not have gotten to the point where it could run Crysis. > > ~Theodore

1 0

Re: [1/2] winhttp/tests: Fix a test failure on win2k.
by Marvin 17 Jun '15

17 Jun '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=14399 Your paranoid android. === w8 (32 bit winhttp) === winhttp.c:864: Test failed: failed to send request 2148074273 winhttp.c:868: Test failed: failed to retrieve certificate context 12019 winhttp.c:873: Test failed: failed to retrieve key bitness 4317 winhttp.c:877: Test failed: failed to retrieve certificate info 12019 winhttp.c:890: Test failed: failed to receive response 12019 winhttp.c:895: Test failed: failed unexpectedly 12019 winhttp.c:896: Test failed: request failed unexpectedly 3735928559 winhttp.c:907: Test failed: WinHttpReadData failed: 12019. winhttp.c:911: Test failed: read_size = 0

1 0

IDirect3DRM*::CreateDeviceFrom* tests
by Aaryaman Vasishta 17 Jun '15

17 Jun '15

Testing if pixel format of the render target changes when the mode is changed: https://testbot.winehq.org/JobDetails.pl?Key=14395 <https://testbot.winehq.org/JobDetails.pl?Key=14356> All the three tests together: https://testbot.winehq.org/JobDetails.pl?Key=14403 Please review the code and let me know of any modifications that are required. Thank you! Jam

1 1

Re: [2/2] Add stub dll d3dcompiler_47 (try 2)
by Matteo Bruni 17 Jun '15

17 Jun '15

2015-06-17 8:01 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > Removed LPVOID > > Changelog: > Add stub dll d3dcompiler_47 > > > Best Regards > Alistair Leslie-Hughes Both patches look good to me. Thanks Alistair!

1 0

Re: [PATCH 2/8] wined3d: Avoid potential division by 0 when computing fog scale.
by Henri Verbeet 17 Jun '15

17 Jun '15

On 16 June 2015 at 22:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > get_fog_start_end(context, state, &start, &end); > - scale = 1.0f / (end - start); > + scale = end == start ? INFINITY : 1.0f / (end - start); Do we really need this? It almost feels nicer to just pass "end - start" to the shader and handle the division there, or perhaps even just pass "start".

3 3

[PATCH 1/2] secur32: Added support for a few more algorithms in schannel_get_cipher_algid.
by Hugh McMaster 17 Jun '15

17 Jun '15

On Tue, 16 Jun 2015 13:46:32 +0200, Jacek Caban wrote: >- case GNUTLS_CIPHER_AES_256_CBC: return CALG_AES; >+ case GNUTLS_CIPHER_AES_128_GCM: return CALG_AES_128; >+ case GNUTLS_CIPHER_AES_192_CBC: return CALG_AES_192; >+ case GNUTLS_CIPHER_AES_256_GCM: >+ case GNUTLS_CIPHER_AES_256_CBC: return CALG_AES_256; Those changes are causing fatal build errors in Wine: schannel_gnutls.c: In function ‘schannel_get_cipher_algid’: schannel_gnutls.c:272:10: error: ‘GNUTLS_CIPHER_AES_128_GCM’ undeclared (first use in this function) case GNUTLS_CIPHER_AES_128_GCM: return CALG_AES_128; ^ schannel_gnutls.c:272:10: note: each undeclared identifier is reported only once for each function it appears in schannel_gnutls.c:274:10: error: ‘GNUTLS_CIPHER_AES_256_GCM’ undeclared (first use in this function) case GNUTLS_CIPHER_AES_256_GCM: ^ make[1]: *** [schannel_gnutls.o] Error 1 make[1]: Leaving directory `/home/hugh/wine-test/dlls/secur32' make: *** [dlls/secur32] Error 2 -- Hugh McMaster

3 5

Re: [PATCH 3/8] wined3d: Cleanup and simplify texture sampling code generation.
by Henri Verbeet 17 Jun '15

17 Jun '15

On 16 June 2015 at 22:45, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > switch (resource_type) > { > case WINED3D_SHADER_RESOURCE_TEXTURE_1D: ... > + type_part = "1D"; > break; There's nothing necessarily wrong with this, but it also seems that aside from the "texrect" handling you could just use the same lookup table you're using for the coordinate mask size.

1 0

Re: [PATCH] riched20: Fix link notification conditions and add tests.
by Alexandre Julliard 17 Jun '15

17 Jun '15

Alex Henrie <alexhenrie24(a)gmail.com> writes: > @@ -4121,6 +4121,10 @@ LRESULT ME_HandleMessage(ME_TextEditor *editor, UINT msg, WPARAM wParam, > return 0; > case WM_SETCURSOR: > { > + POINT cursor_pos; > + if (wParam == (WPARAM)editor->hWnd && GetCursorPos(&cursor_pos) && > + ScreenToClient(editor->hWnd, &cursor_pos)) > + ME_LinkNotify(editor, msg, 0, MAKELPARAM(cursor_pos.x, cursor_pos.y)); Getting the current cursor position doesn't look right, it should be the message position. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [2/3] ntdll: Alter security cookie on WIN64 (try 2)
by Alexandre Julliard 17 Jun '15

17 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > This time ARM64-only > I had trouble with that patch for x86_64 when testing EmEditor... > Still it is the only way to get an app on arm64 to start... There shouldn't be any reason to make this platform-specific, or 64-bit specific for that matter. And a hardcoded cookie is not exactly secure... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] riched20/tests: Some more EM_SETSEL tests
by Marvin 17 Jun '15

17 Jun '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=14363 Your paranoid android. === w2008s64 (64 bit editor) === editor.c:5939: Test failed: wrong event mask (0x0) during WM_COMMAND

2 1

Re: [1/2] Add stub dll d3dcompiler_46
by Matteo Bruni 17 Jun '15

17 Jun '15

2015-06-16 11:14 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > Add stub dll d3dcompiler_46 > > > Best Regards > Alistair Leslie-Hughes These two patches look fine to me except for the LPJUNK + hungarian notation in DllMain(). BTW where did you find that version number for d3dcompiler_46? Windows 8 SDK? Just curious, I found two different version of d3dcompiler_46.dll bundled with various stuff which have different version numbers (even between them).

2 1

Re: [PATCH 1/4] msvcr120: Add ___lc_locale_name_func implementation
by Marvin 16 Jun '15

16 Jun '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=14355 Your paranoid android. === w2008s64 (32 bit msvcr120) === msvcr120.c:209: Test failed: 0 - lc_names[1] = L"en-US" msvcr120.c:206: Test failed: 2 - lc_names[1] = L"zh-CN" msvcr120.c:209: Test failed: 3 - lc_names[1] = L"nl-NL" msvcr120.c:209: Test failed: 4 - lc_names[1] = L"en-US" msvcr120.c:209: Test failed: 5 - lc_names[1] = L"fr-FR" msvcr120.c:209: Test failed: 6 - lc_names[1] = L"de-DE" msvcr120.c:209: Test failed: 7 - lc_names[1] = L"hu-HU" msvcr120.c:209: Test failed: 8 - lc_names[1] = L"is-IS" msvcr120.c:209: Test failed: 9 - lc_names[1] = L"ja-JP" msvcr120.c:209: Test failed: 10 - lc_names[1] = L"ko-KR" msvcr120.c:209: Test failed: 11 - lc_names[1] = L"es-MX" === w2008s64 (64 bit msvcr120) === msvcr120.c:209: Test failed: 0 - lc_names[1] = L"en-US" msvcr120.c:206: Test failed: 2 - lc_names[1] = L"zh-CN" msvcr120.c:209: Test failed: 3 - lc_names[1] = L"nl-NL" msvcr120.c:209: Test failed: 4 - lc_names[1] = L"en-US" msvcr120.c:209: Test failed: 5 - lc_names[1] = L"fr-FR" msvcr120.c:209: Test failed: 6 - lc_names[1] = L"de-DE" msvcr120.c:209: Test failed: 7 - lc_names[1] = L"hu-HU" msvcr120.c:209: Test failed: 8 - lc_names[1] = L"is-IS" msvcr120.c:209: Test failed: 9 - lc_names[1] = L"ja-JP" msvcr120.c:209: Test failed: 10 - lc_names[1] = L"ko-KR" msvcr120.c:209: Test failed: 11 - lc_names[1] = L"es-MX"

1 0

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Jeremy White 16 Jun '15

16 Jun '15

Hi all, On 06/15/2015 02:32 PM, Michael Müller wrote: > Hi Jeremy, > > I actually intended to send the following response to wine-devel, but > the other Wine Staging developers feared that this might continue the > flamewar. Nevertheless, I think the ideas should still reach you, just > treat them as my personal opinion. In case you are comfortable with the > content, feel free to forward or respond to it on wine-devel. I thought these were all interesting points, and wanted to respond publicly. > > I think it is too easy to blame Alexandre for all Wine problems. He is > involved in some of them, but there are also other ways to improve Wine > which are completely unrelated to him. I think even CodeWeavers could > make Wine more community-friendly simply by being more transparent. > > Here are two examples of what I mean: > > 1. CodeWeavers adds a lot of hacks to Crossover to get applications to > work, in case a proper fix would be too much work. From what I have > heard those hacks are only added after the problem has been analyzed and > documented in your bug tracker. I don't understand though why no one in > the Wine community access to this analysis (i.e. why are these bugs not > documented in the public bug tracker)? It seems to be a waste of energy > if the Wine community needs to debug the problem a second time. I think that breaks down into two issues. First, yes, we do have hacks in CrossOver, but I think 'a lot' is unfair. We really try to avoid those hacks, and we work hard to eliminate them. For example, I reviewed our tracker that lists our hacks. We have about 100 outstanding; in the last 6 months, we removed 4 with upstream fixes, and added 1 new one. Further, we have long felt that our diff with winehq was tragically large. But nicely, I can now compare it to wine-staging, and claim that it is relatively modest <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files for wine-staging [1]. Second, for bugs, yes, we do have our own bug tracker, and it is (mostly) private. That's appropriate for CrossOver only bugs, and we do have a lot of customers with whom we have confidentiality agreements, so it's necessary in that case. We do have an official company policy that any Wine related bug in our tracker is supposed to have a related WineHQ bug, and we are supposed to bias our troubleshooting and work in favor of WineHQ. That is true for all bugs, including ones that are hacks. In doing a spot check of that, it looks like we don't do that great a job of adhering to that policy; maybe 30% of the time (although we do have a number of staff members who are particularly good at mostly using WineHQ). I have to agree that this is arguably less than ideal, and I will exhort our staff to do better. But my gut sense is that the perception may be that we have this magical treasure trove of extra information, and the reality is fairly far from that. > > 2. CodeWeavers seems to act like a black box from my point of view. It > is not really clear what you guys are working on and therefore a lot of > Wine developers (who are not part of CW) try to avoid touching the same > areas of Wine. As far as I know CW is currently working on Office 2013 > for example, but there is not a single bug in the WineHQ bug tracker > about this. On the other hand I talked with some CW developers on the > IRC and I had the impression that they wouldn't mind help from the > community to fix certain issues. We all profit from having those bugs > fixed faster. Ouch. I'm not sure how to respond to that. I think we've been accused of being a bit opaque in the past, and I think I've promised to try to do better. Looks like I failed. We do tend to get a lot of NDAs and things that make us careful with information, but we also just have a lot of the strong silent types on staff. But the very last thing I want to do is suppress any work on Wine. My thinking, though, has long been the opposite of yours. That if we advertise an area of work, we risk a 'chilling' effect. There are far more bugs with 'Office' than we could ever handle by ourselves; I would never want someone to stay away from a bug that looked interesting or fun, just because we tend to do a lot of the work on Office. I always thought the perk of being a non CW Wine hacker is that you get to pick and choose the fun parts. I get to make the CW hackers do the yucky, nasty, stuff... <evil grin>. Further, we really do just about all of our work on wine-devel; you can tell what we're working on just by seeing the patches there. For the record, we are working on Office 2013, which is right now mired in a lot of work on dwrite, I believe. If you look at Henri and Nikolay's recent patches, you'll see the work on it. We have lovely purple blobs in Excel instead of readable text (although I'm told I can have those blobs in any color I like). Beyond that, our work is all over the map. I guess the action item here remains the same - for us to do a better job of communicating, so we no longer seem mysterious or opaque. I'll work on that. > > Alexandre needs to find a way how to improve the patch acceptance > process in a way he feels comfortable with, but before everyone starts > blaming him for all problems, there are also other areas which can be > improved. Don't get me wrong, I don't want to say that CW is root of all > evil (I think its very great that you guys keep Wine alive), I just > thought you might be interested in these ideas, especially because these > are things where you have influence on. Yes, thank you - this is very helpful. I think there is clearly a problem, a problem that has gotten worse lately, and it would be great if we can find a way to improve matters. Again, there is far more than enough work to do; to lose any energy to misunderstanding or inter personal friction is just stupid and inefficient. One issue you didn't raise that I want to elevate as a straw man, and then knock down, is the perception that an @codeweavers.com email address is some sort of guarantee of patch acceptance. Trust me, I am painfully aware that it doesn't help :-/. It is true that I tend to hire people that Alexandre trusts (which makes sense, if you think about it), but that's a different way of coloring the situation. And I can tell you that Alexandre is a man of deep integrity, and he is both personally committed to keeping his work on Wine separate from his work for CodeWeavers, and CodeWeavers is contractually bound to allow that. > > Not directly related to the previous mail, but I think its not > sufficient to hope that WineConf will automatically solve all problems. > The WineConf might be a good place to discuss individual ideas, but we > may want to start collecting them in advance. Agreed; hence my desire to make sure to get this down in the email archives as well, and my hope that we can articulate the concerns and possible improvements now as well. But there is something really powerful about meeting face to face that is very nice. It's particularly nice when you can go to the bar to curse Alexandre over beers later <grin>. Cheers, Jeremy [1] This was my methodology, which may be flawed: wine-staging git, removing outsized fonts-Missing_Fonts patch: [~/xfer/wine-staging/patches] grep -h '^diff' */00*.patch | sort | uniq | wc -l 509 [~/xfer/wine-staging/patches] cat */00*.patch | wc -l 107666 CrossOver stats: [~/w/crossover/wine] git diff wine-1.7.45 | grep -h '^diff' | wc -l 228 [~/w/crossover/wine] git diff wine-1.7.45 | wc -l 28388

1 0

Re: ntdll: Improve stub of NtQueryEaFile.
by Alexandre Julliard 16 Jun '15

16 Jun '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Based on a patch by Qian Hong. I don't remember seeing any such patch. Qian is around, so I expect he should be able to submit his own work himself. Then you can submit your part as your own separate patch. It's not a big deal for a small patch like this, but I don't want you to get into the habit of submitting patches containing bits and pieces of other people's work. I expect developers to stand behind their work, and take responsibility for getting their patches committed. Helping them is good, but taking over their work isn't. -- Alexandre Julliard julliard(a)winehq.org

15 26

Re: scrrun: Implement ITextStream Close
by Marvin 16 Jun '15

16 Jun '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=14331 Your paranoid android. === w2000pro (32 bit filesystem) === filesystem.c:1385: Test failed: got 0x800a005b === w2003std (32 bit filesystem) === filesystem.c:1385: Test failed: got 0x800a005b

1 0

Re: [1/2] ntdll: Set platform register x18 to TEB on ARM64 (resend)
by Alexandre Julliard 16 Jun '15

16 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -788,6 +788,17 @@ void signal_free_thread( TEB *teb ) > > > /********************************************************************** > + * set_x18 > + * > + * Win64/ARM applications expect the TEB pointer to be in the x18 platform register. > + */ > +extern void set_x18( TEB *teb ); > +__ASM_GLOBAL_FUNC( set_x18, > + "mov x18, x0\n\t" /* TEB -> platform register */ > + "ret" ) You don't really need a global function for this. -- Alexandre Julliard julliard(a)winehq.org

1 0

odbccp32: Implement SQLGetPrivateProfileString (try 5)
by Hugh McMaster 16 Jun '15

16 Jun '15

On Sun, 14 Jun 2015 14:58:36 +1000, Alistair Leslie-Hughes wrote: > >+ ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); >+ if(ret) >+ { >+ WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, cbRetBuffer, NULL, NULL); >+ RetBuffer[ret] = 0; >+ } If retval is null terminated, you do not need RetBuffer[ret] = 0;. The -1 in WideCharToMultiByte means the function calculates the length of the input string, including any null terminating character. If the input string is null terminated, the output string is also null terminated. So, if this is the case, you are actually null-terminating twice and, depending on the size of cbRetBuffer, the second null termination may be out of bounds. If retval isn't null terminated, you should use the return value of WideCharToMultiByte (the number of bytes written to RetBuffer) instead of 'ret'.

1 0

Re: scrrun: Implement ITextStream Close
by Nikolay Sivov 16 Jun '15

16 Jun '15

> struct textstream *This = impl_from_ITextStream(iface); > - FIXME("(%p): stub\n", This); > - return E_NOTIMPL; > + HRESULT hr = S_OK; > + > + TRACE("(%p)\n", This); > + > + if(!CloseHandle(This->file)) > + hr = S_FALSE; > + > + This->file = NULL; > + > + return hr; This could be right way to do it, but it would be interesting to see what happens to other methods behavior when called on closed stream, like Read() for example.

2 1

Re: odbccp32: Implement SQLGetPrivateProfileString (try 5)
by Nikolay Sivov 16 Jun '15

16 Jun '15

> + sect = heap_strdupAtoW(lpszSection); > + entry = heap_strdupAtoW(lpszEntry); > + string = heap_strdupAtoW(lpszDefault); > + file = heap_strdupAtoW(lpszFilename); > + retval = heap_alloc(cbRetBuffer*sizeof(WCHAR)); > + > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > + if(ret) > + { > + WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, cbRetBuffer, NULL, NULL); > + RetBuffer[ret] = 0; > + } > + > + heap_free(sect); > + heap_free(entry); > + heap_free(string); > + heap_free(file); > + > + heap_free(retval); Structurally it's fine, but you're using WCHAR count as CP_ACP char count, and it's wrong assumption in general.

1 0

Re: [1/3] winhttp: Improve parsing of cookie values.
by Marvin 16 Jun '15

16 Jun '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=14301 Your paranoid android. === w2000pro (32 bit winhttp) === winhttp.c:945: Test failed: failed to receive response 12152 winhttp.c:950: Test failed: failed unexpectedly 12019 winhttp.c:951: Test failed: request failed unexpectedly 3735928559

2 1

Re: [2/3] msvcirt: Add implementation of streambuf::sputc
by Piotr Caban 16 Jun '15

16 Jun '15

On 06/15/15 17:34, Iván Matellanes wrote: > + test_overflow_this = &sb2; > + ret = (int) call_func2(p_streambuf_sputc, &sb3, 'c'); You probably wanted to set the test_overflow_this to sb3 here. Thanks, Piotr

1 0

Re: [PATCH 1/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 2).
by Stefan Dösinger 15 Jun '15

15 Jun '15

Hi, > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ref = get_refcount((IUnknown *)clipper); You're not reading ref anywhere as far as I can see. Did you forget to re-check the refcount after creating the device? If the refcount is incremented by 2 or more: See if the clipper is assigned to the render target and / or depth stencil. This wouldn't really do anything, but it's Microsoft we're talking about here. > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM3 interface (hr = %x).\n", hr); Minor mistake: IDirect3DRM2 vs IDirect3DRM3. > + memcpy(&driver, &IID_IDirect3DRGBDevice, sizeof(GUID)); I think an assignment should do the job. > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, rc.right, rc.bottom, &device2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice2 interface (hr = %x).\n", hr); I'd say "Cannot create IDirect3DRMDevice2 (hr = ...)" here. You're not retrieving an interface here. > + /* Fetch immediate mode device in order to access render target */ > + hr = IDirect3DRMDevice2_GetDirect3DDevice2(device2, &d3ddevice2); > + todo_wine ok(hr == D3DRM_OK, "Cannot get IDirect3DDevice2 interface (hr = %x).\n", hr); > + if (FAILED(hr)) > + { > + IDirect3DRMDevice2_Release(device2); > + IDirect3DRM2_Release(d3drm2); > + IDirect3DRM_Release(d3drm1); > + IDirectDrawClipper_Release(clipper); > + return; > + } You can use the cleanup label here too if you initialize the interface pointers to NULL and add checks for NULL before calling release. > + /* Check properties of primary and depth surfaces */ > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x).\n", hr); > + if (FAILED(hr)) > + goto cleanup; Minor nitpick: A "primary" surface represents the screen content. The correct term in in this case is "render target". Note that a primary surface can be a render target in fullscreen mode. > + ok((desc.dwWidth == rc.right) && (desc.dwHeight == rc.bottom), "Expected surface dimentions = %d, %d, got %d, %d.\n", > + rc.right, rc.bottom, desc.dwWidth, desc.dwHeight); > + expected_caps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_3DDEVICE | DDSCAPS_SYSTEMMEMORY; > + todo_wine ok(desc.ddsCaps.dwCaps == expected_caps, "Expected %x for caps, got %x.\n", expected_caps, desc.ddsCaps.dwCaps); As discussed on IRC ignore DDSCAPS_SYSTEMMEMORY here. I think it happens because you use a RGB device, and I don't think it's something we should care about unless an application depends on this. Check dwRGBBitCount of the render target. It should match the bit depth of the screen mode. > + if (FAILED(hr = IDirectDraw_SetDisplayMode(ddraw, desc.dwWidth, desc.dwHeight, 8))) > + { > + win_skip("Cannot set display mode to 8bpp (hr = %x), skipping tests.\n", hr); > + IDirectDrawSurface7_Release(surface7); > + IDirectDrawSurface_Release(ds); > + IDirectDrawSurface_Release(surface); > + IUnknown_Release(unknown); > + IDirectDraw_Release(ddraw); > + goto cleanup; > + } There's no need to try to set the display mode to 8. Also testing if changing the mode works is outside the scope of this test. What's interesting is that the pixel format of the primary surface of a new device after changing the mode. Please also check the Z bit depth, and if the surface has stencil bits.

2 2

Re: [PATCH 2/5] wined3d: Implement SM4 discard in the GLSL shader backend.
by Matteo Bruni 15 Jun '15

15 Jun '15

2015-06-15 14:07 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > --- > dlls/wined3d/glsl_shader.c | 35 +++++++++++++++++++++-------------- > 1 file changed, 21 insertions(+), 14 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 5ba246e..eb98ffe 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -4704,22 +4704,29 @@ static void shader_glsl_texreg2rgb(const struct wined3d_shader_instruction *ins) > * If any of the first 3 components are < 0, discard this pixel */ > static void shader_glsl_texkill(const struct wined3d_shader_instruction *ins) > { > - struct glsl_dst_param dst_param; > + if (ins->ctx->reg_maps->shader_version.major >= 4) > + { > + struct glsl_src_param src_param; > > - /* The argument is a destination parameter, and no writemasks are allowed */ > - shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); > - if (ins->ctx->reg_maps->shader_version.major >= 2) > + shader_glsl_add_src_param(ins, &ins->src[0], WINED3DSP_WRITEMASK_0, &src_param); > + shader_addline(ins->ctx->buffer, "if (bool(floatBitsToUint(%s))) discard;\n", src_param.param_str); > + } > + else > { > - if (ins->ctx->reg_maps->shader_version.major >= 4) > - FIXME("SM4 discard not implemented.\n"); > - /* 2.0 shaders compare all 4 components in texkill */ > - shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyzw, vec4(0.0)))) discard;\n", dst_param.reg_name); > - } else { > - /* 1.X shaders only compare the first 3 components, probably due to the nature of the texkill > - * instruction as a tex* instruction, and phase, which kills all a / w components. Even if all > - * 4 components are defined, only the first 3 are used > - */ > - shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyz, vec3(0.0)))) discard;\n", dst_param.reg_name); > + struct glsl_dst_param dst_param; > + > + /* The argument is a destination parameter, and no writemasks are allowed */ > + shader_glsl_add_dst_param(ins, &ins->dst[0], &dst_param); > + > + /* 2.0 shaders compare all 4 components in texkill. */ > + if (ins->ctx->reg_maps->shader_version.major >= 2) > + shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyzw, vec4(0.0)))) discard;\n", dst_param.reg_name); > + /* 1.x shaders only compare the first 3 components, probably due to > + * the nature of the texkill instruction as a tex* instruction, and > + * phase, which kills all .w components. Even if all 4 components are > + * defined, only the first 3 are used. */ > + else > + shader_addline(ins->ctx->buffer, "if (any(lessThan(%s.xyz, vec3(0.0)))) discard;\n", dst_param.reg_name); > } > } > > -- > 2.1.4 FWIW, https://msdn.microsoft.com/en-us/library/windows/desktop/hh446968%28v=vs.85… mentions two variants of the discard instruction. Any clue how is that _z vs _nz part encoded?

2 1

DInput axis mapping explanation
by Michael Gardner 15 Jun '15

15 Jun '15

Please forgive me if this is the wrong list or a stupid question, but I already tried wine-users and the WineHQ forums and no one could answer. I'm trying to understand Wine's DirectInput axis mapping feature (registry key HKEY_CURRENT_USER\Software\Wine\DirectInput). The documentation at http://wiki.winehq.org/UsefulRegistryKeys gives some details but seems to assume you already know how the feature works. (You could also consider this an RFE for better DInput axis mapping docs, which I'd be happy to write if I can first understand the feature.) I understand that I can make a registry key with the same name as my joystick device and a value that's a comma-separated list of axes, which will act as some kind of mapping. But how does this mapping work? What is being mapped to what, exactly? The docs give an example mapping without explaining what it does, or how you'd arrive at that mapping given whatever result you're looking for. I've also read https://forum.winehq.org/viewtopic.php?t=14899, but it also doesn't explain how these mappings work in the abstract. Once again, my apologies if this is the wrong place, but if there's anyone who might have the knowledge I'm looking for then it would be the Wine devs.

2 1

Re: [PATCH] winscard: add stubs for SCardListReadersA/W (try 2)
by Matteo Bruni 15 Jun '15

15 Jun '15

2015-06-15 9:31 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>: > From: Austin English <austinenglish(a)gmail.com> > > Fixes http://bugs.winehq.org/show_bug.cgi?id=26978 > > replaced return code after suggestion by Bruno Jesus. > --- > dlls/winscard/winscard.c | 12 ++++++++++++ > dlls/winscard/winscard.spec | 4 ++-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c > index bcf8129..70b3914 100644 > --- a/dlls/winscard/winscard.c > +++ b/dlls/winscard/winscard.c > @@ -129,3 +129,15 @@ void WINAPI SCardReleaseStartedEvent(void) > { > FIXME("stub\n"); > } > + > +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, LPCSTR groups, LPSTR readers, LPDWORD buflen) Not sure it matters much here but I'd stick to avoiding LP* types, as by usual Wine style.

1 0

Re: riched: Added ITextDocument2 definition and corresponding tests
by Alexandre Julliard 15 Jun '15

15 Jun '15

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > From 5583828198dff5f5e19606ba11f1cf961f78f7c5 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Tue, 2 Jun 2015 01:32:52 +0300 > Subject: [PATCH] riched: Added ITextDocument2 definition and corresponding > tests It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M riched20.dll -p riched20_test.exe.so richole && touch richole.ok fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} fixme:richedit:IRichEditOleImpl_inner_fnQueryInterface 0x3334e0: unhandled interface {01c25500-4268-11d1-883a-3c8b00c10000} richole.c:150: Test failed: got 0x80004002 wine: Unhandled page fault on read access to 0x00000000 at address 0x7ed4b59e (thread 0009), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: Use random names when caching very long urls.
by Piotr Caban 15 Jun '15

15 Jun '15

Hi, this will not work for filenames a little shorter than MAX_PATH. Whole file path needs to fit into MAX_PATH characters (not only the file name). Thanks, Piotr

1 0

Re: [PATCH 2/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 2).
by Stefan Dösinger 15 Jun '15

15 Jun '15

> Am 11.06.2015 um 13:51 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + hr = IDirect3DDevice2_GetRenderTarget(d3ddevice2, &surface); > + ok(hr == DD_OK, "Cannot get surface to the render target (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; > + > + /* Check properties of primary and depth surfaces */ > + memset(&desc, 0, sizeof(desc)); > + desc.dwSize = sizeof(desc); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &desc); > + ok(hr == DD_OK, "Cannot get surface desc structure (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; Checking the surface desc isn't really relevant here. The interesting check is if the render target returned by GetRenderTarget is the surface you passed to CreateDeviceFromSurface. Please add a test that shows that an error is returned if the surface was created without 3DDEVICE. > > + hr = IDirectDrawSurface_GetAttachedSurface(surface, &caps, &ds); > + ok(hr == DD_OK, "Cannot get attached depth surface (hr = %x)\n", hr); > + if (FAILED(hr)) > + goto cleanup; What happens if you attach a depth surface yourself before calling CreateDeviceFromSurface? Does d3drm replace it? > + hr = IDirectDrawSurface_QueryInterface(surface, &IID_IDirectDrawSurface7, (void**)&surface7); > + ok(hr == DD_OK, "Cannot get IDirectDrawSurface7 interface (hr = %x)\n", hr); > + > + IDirectDrawSurface_Release(ds); > + IDirectDrawSurface_Release(surface); > + IDirectDrawSurface7_Release(surface7); The QueryInterface call here is redundant.

3 3

Re: [PATCH 2/3] configure: Check if -lunwind is needed for libunwind.
by Alexandre Julliard 15 Jun '15

15 Jun '15

Ken Thomases <ken(a)codeweavers.com> writes: > --- > configure.ac | 26 ++++++++++++++++++++++++++ > dlls/ntdll/Makefile.in | 2 +- > 2 files changed, 27 insertions(+), 1 deletion(-) I'm not sure what we gain by using libunwind on other platforms, but assuming it's useful it would have to be loaded dynamically. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/6] configure: Don't touch platform register x18 on ARM64
by Alexandre Julliard 15 Jun '15

15 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > diff --git a/configure.ac b/configure.ac > index 79110c1..b26ae3e 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -178,6 +178,9 @@ case $host in > CFLAGS="$CFLAGS -marm" > AC_SUBST(TARGETFLAGS,"-marm") > ;; > + aarch64*) > + CFLAGS="$CFLAGS -ffixed-x18" I don't see how this can work. It would have to be made the toolchain default to apply to all system libraries. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] kernel32/tests: Add a partial test for GetConsoleFontSize
by Marvin 15 Jun '15

15 Jun '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=14266 Your paranoid android. === w8 (32 bit console) === console.c:1511: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1511: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1511: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1755: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1755: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1755: Test failed: [18] Expected output count to be 3735928559, got 2359244

2 1

Re: [PATCH 1/2] kernel32/tests: Add a test for GetLargestConsoleWindowSize
by Marvin 15 Jun '15

15 Jun '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=14265 Your paranoid android. === w8 (32 bit console) === console.c:1489: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1489: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1489: Test failed: [18] Expected output count to be 3735928559, got 2359244 console.c:1733: Test failed: [13] Expected output count to be 0, got 2359244 console.c:1733: Test failed: [15] Expected output count to be 0, got 2359244 console.c:1733: Test failed: [18] Expected output count to be 3735928559, got 2359244

2 1

Re: [PATCH] winscard: add stubs for SCardListReadersA/W
by Bruno Jesus 15 Jun '15

15 Jun '15

On Sunday, June 14, 2015, Marcus Meissner <marcus(a)jet.franken.de> wrote: > From: Austin English <austinenglish(a)gmail.com <javascript:;>> > > Fixes http://bugs.winehq.org/show_bug.cgi?id=26978 > --- > dlls/winscard/winscard.c | 12 ++++++++++++ > dlls/winscard/winscard.spec | 4 ++-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/dlls/winscard/winscard.c b/dlls/winscard/winscard.c > index bcf8129..cf7d52d 100644 > --- a/dlls/winscard/winscard.c > +++ b/dlls/winscard/winscard.c > @@ -129,3 +129,15 @@ void WINAPI SCardReleaseStartedEvent(void) > { > FIXME("stub\n"); > } > + > +LONG WINAPI SCardListReadersA(SCARDCONTEXT context, LPCSTR groups, LPSTR > readers, LPDWORD buflen) > +{ > + FIXME("(%lx, %s, %p, %p) stub\n", context, debugstr_a(groups), > readers, buflen); > + return SCARD_F_INTERNAL_ERROR; > +} > + > +LONG WINAPI SCardListReadersW(SCARDCONTEXT context, LPCWSTR groups, > LPWSTR readers, LPDWORD buflen) > +{ > + FIXME("(%lx, %s, %p, %p) stub\n", context, debugstr_w(groups), > readers, buflen); > + return SCARD_F_INTERNAL_ERROR; > +} Hi, that is not a good return code for error, it's better to return SCARD_E_NO_READERS_AVAILABLE. Most applications I tested will understand this error more properly and display better diagnose message to user. Best Regards, Bruno

1 0

Re: [PATCH 2/3] configure: Check if -lunwind is needed for libunwind.
by Ken Thomases 15 Jun '15

15 Jun '15

On Jun 14, 2015, at 9:22 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > configure.ac | 26 ++++++++++++++++++++++++++ > dlls/ntdll/Makefile.in | 2 +- > 2 files changed, 27 insertions(+), 1 deletion(-) Forgot to mention: this is for <https://bugs.winehq.org/show_bug.cgi?id=38713>. -Ken

1 0

Re: [PATCH] advapi32: Implement GetWindowsAccountDomainSid.
by Marvin 14 Jun '15

14 Jun '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=14271 Your paranoid android. === w2000pro (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === wxppro (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === w2003std (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === w7u (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94 === w8 (32 bit security) === security.c:5882: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5888: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5889: Test failed: expected size 24, got 68 security.c:5894: Test failed: expected ERROR_INVALID_PARAMETER, got 1337 security.c:5900: Test failed: expected ERROR_INSUFFICIENT_BUFFER, got 1337 security.c:5901: Test failed: expected size 24, got 1 security.c:5906: Test failed: GetWindowsAccountDomainSid failed with error 1337 security.c:5907: Test failed: last error should not change security.c:5908: Test failed: expected size 24, got 68 security: unhandled exception c0000005 at 0043AC94

1 0

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Theodore Dubois 14 Jun '15

14 Jun '15

I'm curious, given this, how Crossover manages to make the application menu title the same as the Windows program that is running, despite the actual executable being wineloader. Does it work if the executable has no bundle id? ~Theodore > But, more importantly, the title that a program sets for the application menu is ignored by Cocoa. It uses the bundle name regardless. So, this change has no effect.

2 1

Re: hlsl compiler question
by Matteo Bruni 14 Jun '15

14 Jun '15

2015-06-14 10:42 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi Matteo, > > I was looking at this bug as if affects "Star Trek Online" as well. > > Do you know what/how much work it would be to get this fixed? > > http://bugs.winehq.org/show_bug.cgi?id=32932 > > Any help would be great. It still might be way out of my depth to fix. > > Best Regards > Alistair Leslie-Hughes Hi Alistair, fixing that specific bug (i.e. support for the ": register" syntax) is pretty trivial, I even have a patch for that in my queue. It's been postponed by other stuff for a long time but in principle I can send it in the next few days. The problem is that fixing it won't probably help for actually running Star Trek Online, nullDC or any other program currently blocked by that. The HLSL compiler is still missing a lot of stuff, only the parser is currently implemented and the code generation part is totally absent. Cheers, Matteo.

1 0

Re: gdiplus: Implement GdipCreateRegionRgnData.
by Vincent Povirk 14 Jun '15

14 Jun '15

Seems like there are some unnecessary changes (cases reordered, element type fixme changed, breaking from default case), but it looks good otherwise.

1 0

Re: riched: Added ITextDocument2 definition and corresponding tests
by Marvin 13 Jun '15

13 Jun '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=14249 Your paranoid android. === w2000pro (32 bit richole) === richole.c:178: Test failed: error: 126

1 0

Re: [PATCH] ntdll: link libunwind if present
by Ken Thomases 13 Jun '15

13 Jun '15

Hi, On Jun 13, 2015, at 5:17 AM, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On openSUSE 13.1/13.2 otherwise ntdll x86_64 build will fail with: > … This new link error is <https://bugs.winehq.org/show_bug.cgi?id=38713>. > (probably on x86 it all is inlined, but this is not the case for x86_64) The new code that introduced this issue is in x86_64-only code (signal_x86_64.c). Thanks for your attempt to fix the problem I created. I'm not sure why your configure check is in an if statement having to do with the support for CFI directives. Also, the symbol you're checking for (_U_dyn_register) seems suspicious. It's not mentioned in the link errors. Also, I'm not sure it's a reliable export from libunwind. As indicated in the bug report, libunwind does annoying symbol renaming that's not consistent among platforms. (It's definitely not present on OS X, although that's because Apple provides a somewhat customized interface.) Erich Hoover and I are working on a different approach on the bug. He attached a patch and I attached a counter-proposal patch. I'd appreciate if you could check that mine solves the problem for you. Thanks, Ken

1 0

Re: odbccp32: Implement SQLGetPrivateProfileString (try 4)
by Nikolay Sivov 13 Jun '15

13 Jun '15

On 13.06.2015 12:41, Alistair Leslie-Hughes wrote: > + ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); > + if(ret) > + { > + int i, len; > + > + len = ret < cbRetBuffer ? ret : cbRetBuffer; > + for (i=0; i < len; i++) > + RetBuffer[i] = retval[i]; > + RetBuffer[i] = 0; > + } You can't convert it like that, the idea is to do A->W conversion for inputs and W->A for output. Inputs are handled by heap_strdupAtoW(), so you need a single WideCharToMultiByte for retbuffer.

1 0

Re: [PATCH] oledb32: free memory on error exit (Coverity)
by Nikolay Sivov 13 Jun '15

13 Jun '15

On 13.06.2015 8:54, Marcus Meissner wrote: > 966609 Resource leak > --- > dlls/oledb32/datainit.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/oledb32/datainit.c b/dlls/oledb32/datainit.c > index 3c5293a..3a6c924 100644 > --- a/dlls/oledb32/datainit.c > +++ b/dlls/oledb32/datainit.c > @@ -520,6 +520,8 @@ static HRESULT get_dbpropset_from_proplist(struct dbprops *props, DBPROPSET **pr > if (FAILED(hr)) > { > ERR("failed to init property %s value as type %d\n", debugstr_w(pair->name), descr->type); > + CoTaskMemFree(*propset); > + *propset = NULL; > return hr; > } > > free_dbpropset() should be used for that, otherwise you'll still be leaking values.

1 0

Re: [PATCH 1/6] msvcp110: Add tr2_sys__File_size implementation and test.(try 4)
by Piotr Caban 12 Jun '15

12 Jun '15

On 06/11/15 17:43, YongHao Hu wrote: > +@ cdecl -ret64 -arch=win32 ?_File_size@sys@tr2@std@@YA_KPBD@Z(str) msvcp120.?tr2_sys__File_size > +@ cdecl -ret64 -arch=win64 ?_File_size@sys@tr2@std@@YA_KPEBD@Z(str) msvcp120.?tr2_sys__File_size This is not going to work. Thanks, Piotr

2 1

Re: [1/3] include: Add stuff related to WSAPoll() (try 2)
by Alexandre Julliard 12 Jun '15

12 Jun '15

Bruno Jesus <00cpxxx(a)gmail.com> writes: > try 2: > I found the solution to typedef the struct pollfd just like it's done > with fd_set. Unfortunately that doesn't work on mingw: In file included from ../../../wine/include/winsock2.h:50:0, from ../../../wine/include/ws2tcpip.h:22, from ../../../wine/dlls/jsproxy/main.c:34: ../../../wine/include/winsock2.h:287:19: error: redefinition of ‘struct pollfd’ ../../../wine/include/ws2def.h:27:18: note: in definition of macro ‘WS’ In file included from ../../../wine/dlls/jsproxy/main.c:20:0: ../../../wine/include/wine/port.h:284:8: note: originally defined here -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH 2/2] dwrite: Fix splitted range length, initial test for GetMetrics()
by Marvin 12 Jun '15

12 Jun '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=14198 Your paranoid android. === wvistau64 (32 bit layout) === layout.c:2355: Test failed: got 4 === w2008s64 (32 bit layout) === layout.c:2355: Test failed: got 4 === w7u (32 bit layout) === layout.c:2355: Test failed: got 4 === wvistau64 (64 bit layout) === layout.c:2355: Test failed: got 4 === w2008s64 (64 bit layout) === layout.c:2355: Test failed: got 4

1 0

Re: [PATCH 5/6] msvcp110: Add tr2_sys__Make_dir implementation and test.
by Piotr Caban 12 Jun '15

12 Jun '15

Hi, On 06/11/15 17:45, YongHao Hu wrote: > + { "N:\\abc", -1 }, N:\\abc looks like a valid path for me. I guess this test will fail if someone have N: drive. Thanks, Piotr

1 0

Re: [1/1] advapi32/tests: Add preliminary event tracing tests. (try 3)
by Marvin 12 Jun '15

12 Jun '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=14196 Your paranoid android. === w2000pro (32 bit eventlog) === eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wxppro (32 bit eventlog) === eventlog.c:686: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2003std (32 bit eventlog) === eventlog.c:686: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2008s64 (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7u (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w8 (32 bit eventlog) === eventlog.c:695: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:768: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:776: Test failed: Expected success eventlog.c:784: Test failed: Expected ERROR_ALREADY_EXISTS, got 87

1 0

Re: [PATCH 4/4] d3drm/tests: Add refcount tests for IDirect3DRMDevice*
by Stefan Dösinger 11 Jun '15

11 Jun '15

I think these tests are best integrated into CreateDeviceFromClipper. Similar tests are needed for the other creation methods, with some modifications. Check if the reference count of the surface passed to CreateDeviceFromSurface is incremented, and similarly for the device passed to CreateDeviceFromD3D. > Am 11.06.2015 um 13:51 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > The refcount tests for d3drm1 are the same for the device created from all three creation methods. > --- > dlls/d3drm/tests/d3drm.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 81 insertions(+) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index ac4c8fe..ecf1d4d 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -2367,6 +2367,86 @@ cleanup: > IDirectDraw_Release(ddraw1); > } > > +static void test_device_refcount(void) > +{ > + IDirect3DRM *d3drm1; > + IDirect3DRM2 *d3drm2; > + IDirect3DRM3 *d3drm3; > + IDirect3DRMDevice *device1; > + IDirect3DRMDevice2 *device2; > + IDirect3DRMDevice3 *device3; > + IDirectDrawClipper *clipper; > + HWND window; > + HRESULT hr; > + ULONG ref1, ref2, cref1, cref2; > + GUID driver; > + RECT rc; > + > + > + window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, 0, 0, 0, 0); > + GetClientRect(window, &rc); > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface (hr = %x)\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper (hr = %x)\n", hr); > + > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + memcpy(&driver, &IID_IDirect3DRGBDevice, sizeof(GUID)); > + hr = IDirect3DRM_CreateDeviceFromClipper(d3drm1, clipper, &driver, rc.right, rc.bottom, &device1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice interface (hr = %x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d , ref2 = %d\n", ref1, ref2); > + ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %d , cref2 = %d\n", cref1, cref2); > + if (device1) > + IDirect3DRMDevice_Release(device1); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref1 == ref2, "expected ref1 == ref2, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %d, cref2 = %d\n", cref1, cref2); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM2, (void **)&d3drm2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM2 interface (hr = %x).\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + hr = IDirect3DRM2_CreateDeviceFromClipper(d3drm2, clipper, &driver, rc.right, rc.bottom, &device2); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice2 interface (hr = %x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d , ref2 = %d\n", ref1, ref2); > + ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %d , cref2 = %d\n", cref1, cref2); > + if (device2) > + IDirect3DRMDevice2_Release(device2); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref1 == ref2, "expected ref1 == ref2, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %d, cref2 = %d\n", cref1, cref2); > + > + hr = IDirect3DRM_QueryInterface(d3drm1, &IID_IDirect3DRM3, (void **)&d3drm3); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM3 interface (hr = %x).\n", hr); > + ref1 = get_refcount((IUnknown *)d3drm1); > + cref1 = get_refcount((IUnknown *)clipper); > + hr = IDirect3DRM3_CreateDeviceFromClipper(d3drm3, clipper, &driver, rc.right, rc.bottom, &device3); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRMDevice3 interface (hr = %x)\n", hr); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref2 > ref1, "expected ref2 > ref1, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref2 > cref1, "expected cref2 > cref1, got cref1 = %d , cref2 = %d\n", cref1, cref2); > + if (device3) > + IDirect3DRMDevice3_Release(device3); > + ref2 = get_refcount((IUnknown *)d3drm1); > + cref2 = get_refcount((IUnknown *)clipper); > + ok(ref1 == ref2, "expected ref1 == ref2, got ref1 = %d, ref2 = %d\n", ref1, ref2); > + ok(cref1 == cref2, "expected cref1 == cref2, got cref1 = %d, cref2 = %d\n", cref1, cref2); > + > + IDirectDrawClipper_Release(clipper); > + IDirect3DRM2_Release(d3drm2); > + IDirect3DRM3_Release(d3drm3); > +} > + > START_TEST(d3drm) > { > test_MeshBuilder(); > @@ -2387,4 +2467,5 @@ START_TEST(d3drm) > test_create_device_from_clipper(); > test_create_device_from_surface(); > test_create_device_from_d3d(); > + test_device_refcount(); > } > -- > 1.9.3 (Apple Git-50) > > >

2 1

Re: [PATCH] ddraw: Make some functions hotpachable.
by Stefan Dösinger 11 Jun '15

11 Jun '15

This is fine with me. Note though that when I dealt with Fraps I noticed that it expects new interfaces to thunk to old interfaces, not the other way around like we do. We'll probably have to do something similar if we want these apps to work on ddraw. Also at least Fraps expects the functions to be at the same offset in the loaded library image. Setting a constant load address makes this work, but it's an overkill and Alexandre said no to it. > Am 11.06.2015 um 17:38 schrieb Marcus Meissner <marcus(a)jet.franken.de>: > > From: Michael Müller <michael(a)fds-team.de> > > --- > dlls/ddraw/surface.c | 55 ++++++++++++++++++++++++++++------------------------ > 1 file changed, 30 insertions(+), 25 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index f716cfc..77a3d44 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -1155,7 +1155,7 @@ static HRESULT WINAPI ddraw_surface1_Lock(IDirectDrawSurface *iface, RECT *rect, > * For more details, see IWineD3DSurface::UnlockRect > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface7(iface); > HRESULT hr; > @@ -1171,7 +1171,7 @@ static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pR > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -1180,7 +1180,7 @@ static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pR > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, pRect); > } > > -static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -1190,7 +1190,7 @@ static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -1200,7 +1200,7 @@ static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -1210,7 +1210,8 @@ static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *dat > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDrawSurface7 *src, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 *iface, > + IDirectDrawSurface7 *src, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface7(iface); > struct ddraw_surface *src_impl = unsafe_impl_from_IDirectDrawSurface7(src); > @@ -1332,7 +1333,8 @@ static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDra > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDrawSurface4 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Flip(IDirectDrawSurface4 *iface, > + IDirectDrawSurface4 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface4(dst); > @@ -1343,7 +1345,8 @@ static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDrawSurface3 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Flip(IDirectDrawSurface3 *iface, > + IDirectDrawSurface3 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface3(dst); > @@ -1354,7 +1357,8 @@ static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDrawSurface2 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Flip(IDirectDrawSurface2 *iface, > + IDirectDrawSurface2 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface2(dst); > @@ -1365,7 +1369,8 @@ static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface1_Flip(IDirectDrawSurface *iface, IDirectDrawSurface *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Flip(IDirectDrawSurface *iface, > + IDirectDrawSurface *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface(dst); > @@ -1514,7 +1519,7 @@ static HRESULT ddraw_surface_blt_clipped(struct ddraw_surface *dst_surface, cons > * See IWineD3DSurface::Blt for more details > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > IDirectDrawSurface7 *SrcSurface, RECT *SrcRect, DWORD Flags, DDBLTFX *DDBltFx) > { > struct ddraw_surface *dst_surface = impl_from_IDirectDrawSurface7(iface); > @@ -1640,7 +1645,7 @@ static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestR > } > } > > -static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface4(iface); > @@ -1653,7 +1658,7 @@ static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_r > src ? &src->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface3(iface); > @@ -1666,7 +1671,7 @@ static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface2(iface); > @@ -1679,7 +1684,7 @@ static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface(iface); > @@ -2640,7 +2645,7 @@ static HRESULT WINAPI ddraw_surface2_PageUnlock(IDirectDrawSurface2 *iface, DWOR > * DDERR_UNSUPPORTED > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > { > TRACE("iface %p, batch %p, count %u, flags %#x.\n", iface, Batch, Count, Flags); > > @@ -2648,7 +2653,7 @@ static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTB > return DDERR_UNSUPPORTED; > } > > -static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -2657,7 +2662,7 @@ static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -2666,7 +2671,7 @@ static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -2675,7 +2680,7 @@ static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -4093,7 +4098,7 @@ static HRESULT WINAPI ddraw_surface7_GetLOD(IDirectDrawSurface7 *iface, DWORD *M > * For more details, see IWineD3DSurface::BltFast > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > IDirectDrawSurface7 *Source, RECT *rsrc, DWORD trans) > { > struct ddraw_surface *This = impl_from_IDirectDrawSurface7(iface); > @@ -4165,7 +4170,7 @@ static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD d > } > } > > -static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface4(iface); > @@ -4178,7 +4183,7 @@ static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface3(iface); > @@ -4191,7 +4196,7 @@ static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface2(iface); > @@ -4204,7 +4209,7 @@ static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface(iface); > -- > 1.8.4.5 > > >

1 0

Re: [PATCH] ddraw: Make some functions hotpachable.
by Stefan Dösinger 11 Jun '15

11 Jun '15

This is fine with me. Note though that when I dealt with Fraps I noticed that it expects new interfaces to thunk to old interfaces, not the other way around like we do. We'll probably have to do something similar if we want these apps to work on ddraw. Also at least Fraps expects the functions to be at the same offset in the loaded library image. Setting a constant load address makes this work, but it's an overkill and Alexandre said no to it. > Am 11.06.2015 um 17:38 schrieb Marcus Meissner <marcus(a)jet.franken.de>: > > From: Michael Müller <michael(a)fds-team.de> > > --- > dlls/ddraw/surface.c | 55 ++++++++++++++++++++++++++++------------------------ > 1 file changed, 30 insertions(+), 25 deletions(-) > > diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c > index f716cfc..77a3d44 100644 > --- a/dlls/ddraw/surface.c > +++ b/dlls/ddraw/surface.c > @@ -1155,7 +1155,7 @@ static HRESULT WINAPI ddraw_surface1_Lock(IDirectDrawSurface *iface, RECT *rect, > * For more details, see IWineD3DSurface::UnlockRect > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface7(iface); > HRESULT hr; > @@ -1171,7 +1171,7 @@ static HRESULT WINAPI ddraw_surface7_Unlock(IDirectDrawSurface7 *iface, RECT *pR > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pRect) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -1180,7 +1180,7 @@ static HRESULT WINAPI ddraw_surface4_Unlock(IDirectDrawSurface4 *iface, RECT *pR > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, pRect); > } > > -static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -1190,7 +1190,7 @@ static HRESULT WINAPI ddraw_surface3_Unlock(IDirectDrawSurface3 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -1200,7 +1200,7 @@ static HRESULT WINAPI ddraw_surface2_Unlock(IDirectDrawSurface2 *iface, void *da > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *data) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -1210,7 +1210,8 @@ static HRESULT WINAPI ddraw_surface1_Unlock(IDirectDrawSurface *iface, void *dat > return ddraw_surface7_Unlock(&surface->IDirectDrawSurface7_iface, NULL); > } > > -static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDrawSurface7 *src, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 *iface, > + IDirectDrawSurface7 *src, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface7(iface); > struct ddraw_surface *src_impl = unsafe_impl_from_IDirectDrawSurface7(src); > @@ -1332,7 +1333,8 @@ static HRESULT WINAPI ddraw_surface7_Flip(IDirectDrawSurface7 *iface, IDirectDra > return hr; > } > > -static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDrawSurface4 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Flip(IDirectDrawSurface4 *iface, > + IDirectDrawSurface4 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface4(dst); > @@ -1343,7 +1345,8 @@ static HRESULT WINAPI ddraw_surface4_Flip(IDirectDrawSurface4 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDrawSurface3 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Flip(IDirectDrawSurface3 *iface, > + IDirectDrawSurface3 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface3(dst); > @@ -1354,7 +1357,8 @@ static HRESULT WINAPI ddraw_surface3_Flip(IDirectDrawSurface3 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDrawSurface2 *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Flip(IDirectDrawSurface2 *iface, > + IDirectDrawSurface2 *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface2(dst); > @@ -1365,7 +1369,8 @@ static HRESULT WINAPI ddraw_surface2_Flip(IDirectDrawSurface2 *iface, IDirectDra > dst_impl ? &dst_impl->IDirectDrawSurface7_iface : NULL, flags); > } > > -static HRESULT WINAPI ddraw_surface1_Flip(IDirectDrawSurface *iface, IDirectDrawSurface *dst, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Flip(IDirectDrawSurface *iface, > + IDirectDrawSurface *dst, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > struct ddraw_surface *dst_impl = unsafe_impl_from_IDirectDrawSurface(dst); > @@ -1514,7 +1519,7 @@ static HRESULT ddraw_surface_blt_clipped(struct ddraw_surface *dst_surface, cons > * See IWineD3DSurface::Blt for more details > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestRect, > IDirectDrawSurface7 *SrcSurface, RECT *SrcRect, DWORD Flags, DDBLTFX *DDBltFx) > { > struct ddraw_surface *dst_surface = impl_from_IDirectDrawSurface7(iface); > @@ -1640,7 +1645,7 @@ static HRESULT WINAPI ddraw_surface7_Blt(IDirectDrawSurface7 *iface, RECT *DestR > } > } > > -static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_rect, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface4(iface); > @@ -1653,7 +1658,7 @@ static HRESULT WINAPI ddraw_surface4_Blt(IDirectDrawSurface4 *iface, RECT *dst_r > src ? &src->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_rect, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface3(iface); > @@ -1666,7 +1671,7 @@ static HRESULT WINAPI ddraw_surface3_Blt(IDirectDrawSurface3 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_rect, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface2(iface); > @@ -1679,7 +1684,7 @@ static HRESULT WINAPI ddraw_surface2_Blt(IDirectDrawSurface2 *iface, RECT *dst_r > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags, fx); > } > > -static HRESULT WINAPI ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_Blt(IDirectDrawSurface *iface, RECT *dst_rect, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags, DDBLTFX *fx) > { > struct ddraw_surface *dst = impl_from_IDirectDrawSurface(iface); > @@ -2640,7 +2645,7 @@ static HRESULT WINAPI ddraw_surface2_PageUnlock(IDirectDrawSurface2 *iface, DWOR > * DDERR_UNSUPPORTED > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTBATCH *Batch, DWORD Count, DWORD Flags) > { > TRACE("iface %p, batch %p, count %u, flags %#x.\n", iface, Batch, Count, Flags); > > @@ -2648,7 +2653,7 @@ static HRESULT WINAPI ddraw_surface7_BltBatch(IDirectDrawSurface7 *iface, DDBLTB > return DDERR_UNSUPPORTED; > } > > -static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface4(iface); > > @@ -2657,7 +2662,7 @@ static HRESULT WINAPI ddraw_surface4_BltBatch(IDirectDrawSurface4 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface3(iface); > > @@ -2666,7 +2671,7 @@ static HRESULT WINAPI ddraw_surface3_BltBatch(IDirectDrawSurface3 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface2(iface); > > @@ -2675,7 +2680,7 @@ static HRESULT WINAPI ddraw_surface2_BltBatch(IDirectDrawSurface2 *iface, DDBLTB > return ddraw_surface7_BltBatch(&surface->IDirectDrawSurface7_iface, batch, count, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltBatch(IDirectDrawSurface *iface, DDBLTBATCH *batch, DWORD count, DWORD flags) > { > struct ddraw_surface *surface = impl_from_IDirectDrawSurface(iface); > > @@ -4093,7 +4098,7 @@ static HRESULT WINAPI ddraw_surface7_GetLOD(IDirectDrawSurface7 *iface, DWORD *M > * For more details, see IWineD3DSurface::BltFast > * > *****************************************************************************/ > -static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD dstx, DWORD dsty, > IDirectDrawSurface7 *Source, RECT *rsrc, DWORD trans) > { > struct ddraw_surface *This = impl_from_IDirectDrawSurface7(iface); > @@ -4165,7 +4170,7 @@ static HRESULT WINAPI ddraw_surface7_BltFast(IDirectDrawSurface7 *iface, DWORD d > } > } > > -static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface4 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface4(iface); > @@ -4178,7 +4183,7 @@ static HRESULT WINAPI ddraw_surface4_BltFast(IDirectDrawSurface4 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface3 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface3(iface); > @@ -4191,7 +4196,7 @@ static HRESULT WINAPI ddraw_surface3_BltFast(IDirectDrawSurface3 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface2 *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface2(iface); > @@ -4204,7 +4209,7 @@ static HRESULT WINAPI ddraw_surface2_BltFast(IDirectDrawSurface2 *iface, DWORD d > src_impl ? &src_impl->IDirectDrawSurface7_iface : NULL, src_rect, flags); > } > > -static HRESULT WINAPI ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > +static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface1_BltFast(IDirectDrawSurface *iface, DWORD dst_x, DWORD dst_y, > IDirectDrawSurface *src_surface, RECT *src_rect, DWORD flags) > { > struct ddraw_surface *dst_impl = impl_from_IDirectDrawSurface(iface); > -- > 1.8.4.5 > > >

1 0

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Ken Thomases 11 Jun '15

11 Jun '15

Hi, On Jun 10, 2015, at 9:48 AM, Vitor Marques <vitor251093(a)gmail.com> wrote: > In the actual code, the Mac Driver uses the Bundle Name on the Hide and Quit buttons, but not in the main menu item, which doesn't make sense since that's the most important place for the app name. It's a very simple change that surely will be very welcome to all Mac users. I've also attached the patch in case Gmail's line-wrapping cause any trouble. Although I have not tested, the changes are simple enough to be analyzed in sight. My system is a Mac OS X 10.10. Thanks for your interest in the Mac driver and your attempt to improve it. Unfortunately, it's clear you haven't tested, since this won't run. You've misspelled "length" as "lenght", which would cause an unrecognized selector exception at run time if it even compiles. But, more importantly, the title that a program sets for the application menu is ignored by Cocoa. It uses the bundle name regardless. So, this change has no effect. Was there an actual problem behavior that you observed that you were trying to fix? Or was this just determined by reading the code? -Ken

2 2

Re: [PATCH 1/4] msvcp110: Add tr2_sys__File_size implementation and test.(try 3)
by Piotr Caban 11 Jun '15

11 Jun '15

On 06/09/15 18:49, YongHao Hu wrote: > try 3: > Add errno and SetLastError test. The series looks good for me. The GetLastError value seems to be inconsistent (it's best visible in _Equivalent tests). I'm not sure why I've asked you about testing GetLastError, I was probably thinking about errno. Anyway I don't think it's useful to test it in future. Thanks, Piotr

2 5

Re: PATCH: ParseX509EncodedCertificateForListBoxEntry stub
by Henri Verbeet 11 Jun '15

11 Jun '15

I suppose I'll give Austin a hand because I like the occasional Valgrind runs. On 11 June 2015 at 11:24, Marcus Meissner <marcus(a)jet.franken.de> wrote: > +DWORD WINAPI ParseX509EncodedCertificateForListBoxEntry(LPBYTE cert, DWORD len, LPSTR szlistbox, LPDWORD listbox) Please avoid the pointer typedefs and Hungarian. I.e., "char *listbox", "DWORD *listbox_size", etc. > + FIXME("stub: %p %d %s %p\n", cert, len, debugstr_a(szlistbox), listbox); I'm not a particular fan of this tracing style, but I suppose it's the local wininet style. "len" is a DWORD, so unsigned, so %u. "szlistbox" is an output parameter, so tracing it as a string makes no sense. > -@ stub ParseX509EncodedCertificateForListBoxEntry > +@ stdcall ParseX509EncodedCertificateForListBoxEntry(ptr long str ptr) Similarly, "str" is wrong for output parameters. > +DWORD WINAPI ParseX509EncodedCertificateForListBoxEntry(LPBYTE,DWORD,LPSTR,LPDWORD); While not strictly wrong, I really think it's much more readable to include the parameter names in the prototypes. I suppose that's local wininet style too, but IMHO we should just fix it in that regard. Also, pointer typedefs again.

2 1

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Huw Davies 11 Jun '15

11 Jun '15

On Wed, Jun 10, 2015 at 11:48:35AM -0300, Vitor Marques wrote: > Although I have not tested, the changes are simple enough > to be analyzed in sight. Indeed they are, see below. You really do need to test your patches. And yes, gmail messed up the whitespace. > diff --git a/dlls/winemac.drv/cocoa_app.m b/dlls/winemac.drv/cocoa_app.m > index 82925c8..a9d98c6 100644 > --- a/dlls/winemac.drv/cocoa_app.m > +++ b/dlls/winemac.drv/cocoa_app.m > @@ -214,14 +214,14 @@ - (void) transformProcessToForeground > > mainMenu = [[[NSMenu alloc] init] autorelease]; > > - // Application menu > - submenu = [[[NSMenu alloc] initWithTitle:@"Wine"] autorelease]; > + // Application name > bundleName = [[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString*)kCFBundleNameKey]; > + if (!bundleName || ![bundleName lenght]) bundleName = @"Wine"; "lenght" is not what you want here. Huw.

2 2

Re: [PATCH 1/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper (try 2).
by Henri Verbeet 11 Jun '15

11 Jun '15

On 11 June 2015 at 13:51, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > + cleanup: > + IDirectDrawClipper_Release(clipper); I'm mostly leaving this for Stefan to actually review, but this seems like an indentation accident.

1 0

Re: dpnet: Correct adding components in Duplicate
by Marvin 11 Jun '15

11 Jun '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=14153 Your paranoid android. === w8 (32 bit address) === The test timed out

1 0

Re: PATCH: d3d8: mark one more function as hotpatchable
by Henri Verbeet 11 Jun '15

11 Jun '15

I think the original subject was slightly better because it's more specific, although the proper name of the function is d3d8_swapchain_Present() of course.

1 0

Re: odbccp32: Implement SQLGetPrivateProfileString ( try 2)
by Alexandre Julliard 11 Jun '15

11 Jun '15

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -101,6 +102,21 @@ static inline WCHAR *heap_strdupAtoW(const char *str) > return ret; > } > > +static char *WtoA(LPCWSTR wstr) > +{ > + int length; > + char *result; > + > + length = WideCharToMultiByte(CP_UTF8, 0, wstr, -1, NULL, 0, NULL, NULL); > + > + result = HeapAlloc(GetProcessHeap(), 0, length); > + > + if (result) > + WideCharToMultiByte(CP_UTF8, 0, wstr, -1, result, length, NULL, NULL); > + > + return result; UTF-8 makes no sense here, and you shouldn't need that function in the first place. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: PATCH: ParseX509EncodedCertificateForListBoxEntry stub
by Alexandre Julliard 11 Jun '15

11 Jun '15

Marcus Meissner <marcus(a)jet.franken.de> writes: > From db29dec04c5c02ab2a96010d42aec00aaeccbec2 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Wed, 25 Feb 2015 01:04:56 -0600 > Subject: wininet: add ParseX509EncodedCertificateForListBoxEntry stub (try 2) > > Try 2: Fix prototype/spec file, add to winineti.h > Fixes https://bugs.winehq.org/show_bug.cgi?id=29842 It's still wrong. If you want to help, review the patch, figure out what's wrong, email the original author (CC'ing wine-devel), and ask them to fix their patch and resubmit. And if you can't figure out what's wrong, then maybe you shouldn't be submitting other people's patches. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winemac.drv: Improved App name on windows and menus (Mac Driver)
by Nikolay Sivov 11 Jun '15

11 Jun '15

On 06/10/2015 05:48 PM, Vitor Marques wrote: > + // Application name > bundleName = [[NSBundle mainBundle] objectForInfoDictionaryKey:(NSString*)kCFBundleNameKey]; > + if (!bundleName || ![bundleName lenght]) bundleName = @"Wine"; I can't say I understand objc, but this looks like a typo.

1 0

Re: dpnet: Simplify the storing of component data
by Stefan Dösinger 11 Jun '15

11 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am OK with this patch in principle if you believe that it is an improvement. It reduces the code size, but on the other hand it means that you're having tiny allocations for DWORDs and GUIDs. Keep in mind that such allocations mean overhead in memory use, run time and memory fragmentation. I'd like to point out an alternative approach: You can give struct component a variable size, similar to how struct wined3d_private_data in include/wine/wined3d.h works. But overall I think this is a minor detail considering the overall state of the directplay libs and that there are more important issues to solve. I don't want to stand in your way by arguing about small things like this. I can't promise Alexandre agrees though. Either way, two style comments: The test is a good test to add, but should be in its own patch. Am 2015-06-10 um 06:41 schrieb Alistair Leslie-Hughes: > found = TRUE; > > - if(entry->type == DPNA_DATATYPE_STRING_ANSI) > - heap_free(entry->data.ansi); > - else if(entry->type == DPNA_DATATYPE_STRING) > - heap_free(entry->data.string); > - else if(entry->type == DPNA_DATATYPE_BINARY) > - heap_free(entry->data.binary); > + heap_free(entry->data); > > break; The added heap_free line is indented by 11 chars. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVeAC0AAoJEN0/YqbEcdMws9oP/RyusEIcZnV4GWTAmfaSKfFn 0iheACWwmeL3GlWeqmY51S8ImuKcoD0HoZ/vQm6jMhTTJFK3jENVJkMk/Mjx8Kk6 ZPcit6nPB184lDgzLXV0gHbMlPkFxdTPJi++1ZfKa9LskJ3zIrgF7LcJFidtCSeG 7yHdg6C0BiQH4oXjBzY+fVRzaQluKEihncaa2tYdErfMUCzUf+RAi99/tnete2Re EiejXowzg5HcxjBHMupsGEcFocUnXtUlPzJf0UIawbptxzPYXk3H0VYPohIrLVm6 f/chcdKlvAi5xdUlCuF4nLw9TQxyC5h3mf5p7l/JdDbgRE8knCO1w/HrzOHJJJRB TnkU5EdrnIc3Bx6Tw/kQGTKsM3SAuSapdjBsQRracNaQVzdqYKfsMPaiQeRVmdQO LJbyeECFw3l3opf/LFd/TUguDws2hChASaBAOf25vorhD6wH8fnaoNnEh1qMtBH5 x1jJjxB+B0Uwa4nYKProoOc0Qw0/zoaVlv3vCKiiEggz+BkXEuYb58ZDysSg4A1w JVO0S6GAfumFPWvHMtoIEPsFxiPl6xHiwXsKzrHc8K5EpUTZ2Jcv0lam53x39Tb1 cJmluv1SyxrdrTWT1nCtgg+ma8ezid8HEpOj+aIWVwYcKwR9uF09jvDEaAzwSuAr V6ogftbNHriUDl15YrO+ =zne3 -----END PGP SIGNATURE-----

2 1

Re: [1/1] advapi32/tests: Add preliminary event tracing tests. (v2 resend)
by Marvin 11 Jun '15

11 Jun '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=14142 Your paranoid android. === w2000pro (32 bit eventlog) === eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wxppro (32 bit eventlog) === eventlog.c:687: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2003std (32 bit eventlog) === eventlog.c:687: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2008s64 (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7u (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w8 (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:787: Test failed: Expected success eventlog.c:795: Test failed: Expected ERROR_ALREADY_EXISTS, got 87

1 0

Re: [PATCH 5/5] d3d9/tests: Test the default colors for fixed function vertex processing.
by Marvin 10 Jun '15

10 Jun '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=14137 Your paranoid android. === w8 (32 bit visual) === visual.c:7924: Test failed: Got unexpected color 0x00ffff00 for no color attribute test. visual.c:7924: Test failed: Got unexpected color 0x00ffff00 for no color attribute test. visual.c:7924: Test failed: Got unexpected color 0x00ffff00 for no color attribute test.

1 0

Re: [PATCH 4/5] d3d9/tests: Test the default diffuse color for vertex shaders.
by Marvin 10 Jun '15

10 Jun '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=14136 Your paranoid android. === w8 (32 bit visual) === visual.c:7924: Test failed: Got unexpected color 0x00ffff00 for no color attribute test. visual.c:7924: Test failed: Got unexpected color 0x00ffff00 for no color attribute test. visual.c:7924: Test failed: Got unexpected color 0x00ffff00 for no color attribute test.

1 0

Re: [PATCH 4/4] d3drm/tests: Add refcount tests for IDirect3DRMDevice*
by Marvin 10 Jun '15

10 Jun '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=14110 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:2037: Test failed: Expected 32 bpp, got 24d3drm.c:2054: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2058: Test failed: Expected 640x480, got 1024x768 d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. d3drm.c:2306: Test failed: Expected 10006040 for caps, got 2840. === wxppro (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. d3drm.c:2306: Test failed: Expected 10006040 for caps, got 2840. === w2003std (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. d3drm.c:2306: Test failed: Expected 10006040 for caps, got 2840.

2 1

Re: [PATCH 2/2] mshtml: Implement IHTMLXMLHttpRequest as a stub. (try 2)
by Alexandre Julliard 10 Jun '15

10 Jun '15

Zhenbo Li <litimetal(a)gmail.com> writes: > try 2: > add test_disp in dom.c for DIID_DispHTMLXMLHttpRequest It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so dom && touch dom.ok dom.c:6110: Test failed: unexpected guid {3051040a-98b5-11cf-bb82-00aa00bdce0b} make: *** [dom.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winebuild: Set a valid major and minor linker version.
by Nikolay Sivov 10 Jun '15

10 Jun '15

On 10.06.2015 10:08, Sebastian Lackner wrote: > From: Michael Müller <michael(a)fds-team.de> > > Some apps expect a nonzero linker version. > Just out of curiosity, could you name some of those applications?

2 1

Re: [PATCH 3/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromD3D.
by Marvin 10 Jun '15

10 Jun '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=14109 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:2037: Test failed: Expected 32 bpp, got 24d3drm.c:2054: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2058: Test failed: Expected 640x480, got 1024x768 d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. d3drm.c:2306: Test failed: Expected 10006040 for caps, got 2840. === wxppro (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. d3drm.c:2306: Test failed: Expected 10006040 for caps, got 2840. === w2003std (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. d3drm.c:2306: Test failed: Expected 10006040 for caps, got 2840.

1 0

Re: [PATCH 2/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface.
by Marvin 10 Jun '15

10 Jun '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=14108 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:2037: Test failed: Expected 32 bpp, got 24d3drm.c:2054: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2058: Test failed: Expected 640x480, got 1024x768 d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. === wxppro (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840. === w2003std (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. d3drm.c:2138: Test failed: Expected 10006040 for caps, got 2840.

1 0

Re: [PATCH 1/4] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromClipper.
by Marvin 10 Jun '15

10 Jun '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=14107 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:2037: Test failed: Expected 32 bpp, got 24d3drm.c:2054: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2058: Test failed: Expected 640x480, got 1024x768 === wxppro (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32. === w2003std (32 bit d3drm) === d3drm.c:2040: Test failed: Cannot set display mode to 8bpp (hr = 80004001). d3drm.c:2044: Test failed: Expected 16 bpp, got 32.

1 0

Re: [3/3] kernel32: Forward SetFileInformationByHandle FileDispositionInfo class to ntdll.
by Marvin 10 Jun '15

10 Jun '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=14103 Your paranoid android. === wvistau64 (32 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: [1/3] kernel32: Improve stub for SetFileInformationByHandle.
by Marvin 10 Jun '15

10 Jun '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=14101 Your paranoid android. === wvistau64 (32 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820 === w7u (32 bit file) === file.c:4204: Test failed: SetFileValidData failed 87 file.c:4207: Test failed: SetFileValidData failed 87 === wvistau64 (64 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820

2 1

Re: regedit: Need 3 bytes of room at end of buffer for \r\n\0 to avoid endless loop.
by Sebastian Lackner 10 Jun '15

10 Jun '15

On 21.05.2015 13:14, Jiaxing Wang wrote: > --- > programs/regedit/regproc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > The patch looks correct to me, and the issue can be easily reproduced by trying to import for example http://ix.io/j1Y. (md5sum: 6928e59d2c1a92666377a088a1523666) The only problem I see is that the code for A/W has diverged a lot over time. I'm not sure, but I assume Alexandre might expect to merge or at least synchronize it, before fixing specific parser bugs.

1 0

Re: include: Fix definition of FILE_DISPOSITION_INFO.
by Nikolay Sivov 10 Jun '15

10 Jun '15

On 09.06.2015 10:09, Sebastian Lackner wrote: > A member called DeleteFile cannot be accessed because its defined as > DeleteFile_must_be_suffixed_with_W_or_A_in_this_context. > > --- > include/winbase.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > This is how it's defined in SDK though, I don't think you can change that.

3 4

Re: rpcrt4: Restore original error code when ReadFile fails with ERROR_MORE_DATA.
by Alexandre Julliard 09 Jun '15

09 Jun '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Required when named pipe messagemode is implemented. Restoring last error is in general wrong. You'll need a better reason to justify this. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: gdiplus: Implement trivial case of GdipCreateRegionRgnData for empty and infinite regions
by Dmitry Timoshkov 09 Jun '15

09 Jun '15

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > First bits for https://bugs.winehq.org/show_bug.cgi?id=34843 What is the reason of reimplementing it when wine-staging already includes full implementation with tests? https://github.com/wine-compholio/wine-staging/blob/master/patches/gdiplus-… -- Dmitry.

6 14

Re: gdiplus: Implement trivial case of GdipCreateRegionRgnData for empty and infinite regions (try2)
by Vincent Povirk 09 Jun '15

09 Jun '15

Looks good to me, thanks. On Tue, Jun 9, 2015 at 1:37 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > try2: check for both possible magic values > > >

1 0

mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.
by Joerg-Cyril.Hoehle＠t-systems.com 09 Jun '15

09 Jun '15

Aki, if I understand your critical section well, you serialize all accesses to the individual player thread. This may be ok for commands that return immediately, e.g. STATUS, but the MCI knows commands that may take a long time, in particular PLAY, RECORD and even SEEK. Did you run a test like this: CreateTask { SetEvent started MCICommand(MCI_PLAY, "av_file_that_takes_3_minutes.avi", MCI_WAIT); } Wait(started); Repeat 10 times { MCICommand(MCI_STATUS,MCI_POSITION); printf MCICommand(MCI_STATUS,MCI_MODE); Printf Sleep(2s); } Wait(thread); I would expect all MCI commands "STATUS POSITION" etc. to work while another thread is busy playing a file synchronously (using MCI_WAIT). Furthermore +static LRESULT MCIQTZ_relayTaskMessage [...] + if (WaitForSingleObject(wma->task.done, INFINITE) == WAIT_OBJECT_0) Are you sure it's ok to block the user thread like this? Shouldn't the code use a loop that also pumps the MS-Windows message queue and dispatches messages? E.g. there may be a need to dispatch REFRESH and PAINT messages? Did you cross-check what MS-Windows does here? On a related note, IIRC some wine devices use a more reliable approach to waiting: WaitForMultiple(2 objects: [task.done, task.threadId], INFINITE); That way, should the player crash or exit somehow, the main (user) task doesn't hang. Regards, Jörg Höhle

2 4

Re: kernel32: Treat empty locale name as LANG_INVARIANT.
by Alexandre Julliard 09 Jun '15

09 Jun '15

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/kernel32/locale.c | 7 +++++++ > dlls/kernel32/tests/locale.c | 6 ++++-- > 2 files changed, 11 insertions(+), 2 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -T ../../.. -M kernel32.dll -p kernel32_test.exe.so locale && touch locale.ok locale.c:2421: Test failed: Expected lcid = 0x7F, got 0000047f, error -559038737 make: *** [locale.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [6/7] qmgr: Add support for Basic authentication.
by Jacek Caban 09 Jun '15

09 Jun '15

Hi Hans, On 06/08/15 14:32, Hans Leidekker wrote: > static HRESULT WINAPI http_negotiate_BeginningTransaction( > IHttpNegotiate *iface, LPCWSTR url, LPCWSTR headers, DWORD reserved, LPWSTR *add_headers) > { > DLBindStatusCallback *callback = impl_from_IHttpNegotiate(iface); > - FIXME("(%p)->(%s %s %u %p)\n", callback, debugstr_w(url), debugstr_w(headers), reserved, add_headers); > - return E_NOTIMPL; > + BackgroundCopyJobImpl *job = callback->file->owner; > + WCHAR *str, *auth_header; > + DWORD len; > + > + TRACE("(%p)->(%s %s %d %p)\n", callback, debugstr_w(url), debugstr_w(headers), reserved, add_headers); > + > + if ((auth_header = build_auth_header(&job->http_options.creds))) > + { > + if (!job->http_options.headers) > + { > + *add_headers = auth_header; > + return S_OK; > + } > + else > + { > + len = strlenW(auth_header) + strlenW(job->http_options.headers); > + if (!(str = CoTaskMemAlloc((len + 1) * sizeof(WCHAR)))) > + { > + CoTaskMemFree(auth_header); > + return E_OUTOFMEMORY; > + } > + strcpyW(str, auth_header); > + strcatW(str, job->http_options.headers); > + CoTaskMemFree(auth_header); > + *add_headers = str; > + return S_OK; > + } > + } > + else if (job->http_options.headers) > + { > + if (!(*add_headers = co_strdupW(job->http_options.headers))) return E_OUTOFMEMORY; > + return S_OK; > + } > + > + *add_headers = NULL; > + return S_OK; It doesn't sound like a good idea to manually handle that here. We should most likely use IAuthenticate (although it's not yet supported in urlmon). Jacek

2 6

Re: [wine-tools] patches: Add a "Staging" status.
by Austin English 09 Jun '15

09 Jun '15

On Fri, Jun 5, 2015 at 11:30 AM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > --- > patches/expire | 1 + > patches/patches.css | 1 + > patches/update | 2 ++ > 3 files changed, 4 insertions(+) > > diff --git a/patches/expire b/patches/expire > index f143ab1..3cf75e6 100755 > --- a/patches/expire > +++ b/patches/expire > @@ -37,6 +37,7 @@ my %status_expiry = > "split" => 7, > "depend" => 7, > "sequence" => 7, > + "staging" => 30, > "superseded" => 1, > "testcase" => 7, > "testfail" => 7, > diff --git a/patches/patches.css b/patches/patches.css > index 745ec75..5746057 100644 > --- a/patches/patches.css > +++ b/patches/patches.css > @@ -154,6 +154,7 @@ tr.odd { background-color: #f8e8e8; } > .sequence, .sequence :link, .sequence :visited { color: #e08000; } > .deferred, .deferred :link, .deferred :visited { color: #e08000; } > .testcase, .testcase :link, .testcase :visited { color: #e08000; } > +.staging, .staging :link, .staging :visited { color: #e08000; } > .other, .other :link, .other :visited { color: #e08000; } > .applyfail, .applyfail :link, .applyfail :visited { color: red; } > .buildfail, .buildfail :link, .buildfail :visited { color: red; } > diff --git a/patches/update b/patches/update > index 4ccc910..335af0b 100755 > --- a/patches/update > +++ b/patches/update > @@ -40,6 +40,7 @@ my %status_descr = > "depend" => "Dependency", > "superseded" => "Superseded", > "sequence" => "Bad sequence", > + "staging" => "Staging", > "testcase" => "Needs tests", > "testfail" => "Test failure", > ); > @@ -57,6 +58,7 @@ my @legend = > "<li>Someone else fixed the problem already.</li></ul>" ], > [ "testcase", "<ul><li>You need to write some test cases demonstrating that the patch is correct.</li></ul>" ], > [ "deferred", "<ul><li>The patch is deferred because of code freeze for an upcoming release. Either resend after the release, make the patch less intrusive, or make a convincing argument that it needs to be included in the release.</li></ul>" ], > + [ "staging", "<ul><li>The patch needs more work or wider testing. Please get it in over Wine Staging.</li></ul>" ], > [ "other", "<ul><li>The patch belongs to another WineHQ project (website, appdb, etc.) and will be applied by the respective maintainer.</li></ul>" ], > [ "applyfail", "<ul><li>The patch got mangled in transit.</li>" . > "<li>It's not relative to the latest git.</li>" . > -- > 2.4.2 I'm not sure we want to encourage wine-stating from Upstream (I'm not convinced either way), but in any case, the grammar seems wrong to me as a native speaker, how about: "The patch needs more work or wider testing. Please try to get into Wine-Staging." or something similar? -- -Austin

5 4

Re: odbccp32: Implement SQLGetPrivateProfileString
by Nikolay Sivov 09 Jun '15

09 Jun '15

On 09.06.2015 13:00, Alistair Leslie-Hughes wrote: > @@ -415,12 +416,56 @@ int WINAPI SQLGetPrivateProfileString(LPCSTR lpszSection, LPCSTR lpszEntry, > LPCSTR lpszDefault, LPCSTR RetBuffer, int cbRetBuffer, > LPCSTR lpszFilename) I turns out our definition is wrong, PSDK uses LPSTR/LPWSTR for output buffer. Fixing that (including header of course) will fix casts that you had to use to cast const away. Also I think we want SQLGetPrivateProfileStringW to be implemented first, and forward SQLGetPrivateProfileString to it, unless there's a reason not to do that, like differences in behavior that some tests reveal.

1 0

Re: [PATCH 1/2] mshtml: Implement IHTMLXMLHttpRequestFactory as a stub.
by Jacek Caban 09 Jun '15

09 Jun '15

Hi Zhenbo, On 06/08/15 17:04, Zhenbo Li wrote: > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -1965,8 +1965,23 @@ static HRESULT WINAPI HTMLWindow5_put_XMLHttpRequest(IHTMLWindow5 *iface, VARIAN > static HRESULT WINAPI HTMLWindow5_get_XMLHttpRequest(IHTMLWindow5 *iface, VARIANT *p) > { > HTMLWindow *This = impl_from_IHTMLWindow5(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + HTMLInnerWindow *window = This->inner_window; > + > + TRACE("(%p)->(%p)\n", This, p); > + > + if(!window->xml_factory) { > + HRESULT hres; > + > + hres = HTMLXMLHttpRequestFactory_Create(window, &window->xml_factory); > + if(FAILED(hres)) > + return hres; > + } This instance will be leaked. You need to release it when HTMLInnerWindow is freed. Cheers, Jacek

1 0

Re: [1/2] xaudio2_7: Implement IXaudio2 interface as stub (try 5)
by Jacek Caban 09 Jun '15

09 Jun '15

Hi Guillaume, On 06/09/15 10:46, Guillaume Charifi wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=26808 > > Thanks Jacek, I applied most of your tips (except those I was unable to understand how they was related to the code) It looks better now, but: > +static HRESULT WINAPI XAudio2CF_QueryInterface(IClassFactory *iface, REFIID riid, void **ppobj) > +{ > + return IClassFactory_QueryInterface(iface, riid, ppobj); > +} Why did you change it? This can't work, it will cause infinite recursion when called. Cheers, Jacek

1 0

Re: [PATCH] advapi32: test and fix ChangeServiceConfig2 when given a zero length or a null description (try 2) (was: succeed
by Marvin 09 Jun '15

09 Jun '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=14026 Your paranoid android. === w7u (32 bit service) === service.c:1421: Test failed: Active services mismatch 1 service.c:1422: Test failed: Inactive services mismatch 4294967295

2 1

Re: [PATCH 2/2] d3dx9_36: Implement triangle filter when create textures
by Matteo Bruni 09 Jun '15

09 Jun '15

2015-06-09 10:49 GMT+02:00 Sergey Isakov <isakov-sl(a)bk.ru>: > This algo just tested long ago. > May be it can be rewritten to float point math but it requires additional efforts. > > It does differ from MS algo because it is my algo not related to MS. > > Manually observe? I did this and sent a picture. Can't imagine what should be done with tests suit. The test I mentioned is not meant for the Wine test suite (even though it would be nice to have some kind of Wine test eventually). You would write a standalone application (or hack something in the d3dx9 tests, it might be easier) along the lines of what I described and run it against native d3dx9_36.dll, ideally on Windows. You'd save the filtered images and eyeball them to try to figure out what's the filtering algorithm used by MS. I have no idea whether it will be doable in practice or not but it seems worth a try.

2 1

Re: kernel32/tests: Some tests for invalid classes in SetFileInformationByHandle()
by Marvin 09 Jun '15

09 Jun '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=14013 Your paranoid android. === wvistau64 (32 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:446: Test failed: attributes of file "testfile.xxx" are 0x0820

2 1

Re: [PATCH 2/2] d3dx9_36: Implement triangle filter when create textures
by Nikolay Sivov 09 Jun '15

09 Jun '15

On 08.06.2015 10:02, Sergey Isakov wrote: > > On 08.06.2015, at 9:48, Nikolay Sivov wrote: > >> On 07.06.2015 23:13, Sergey Isakov wrote: >>> It is probably not triangle filter but works with similar result so I place it in appropriate places. >>> As well load surface and volume works with DXTn textures now. External conversion is a stub. >>> The best test will be graphical. See two sscreenshots: textures made by DxTex.exe (from DirectXSDK), one with point filter, second with triangle filter my version. >>> PS. About copyright. It is my mathematics. (c)Isakov S.L. >>> >> >>> +#ifdef DXTN_COMPESSION_SUPPORTED >>> + switch (format) >>> + { >>> + case D3DFMT_DXT1: >>> + if (!wined3d_dxtn_supported()) return NULL; >>> + return encode ? wined3d_dxt1_encode : wined3d_dxt1_decode; >> >> This diff is not against wine-git tree, there's no wined3d_dxtn_supported() funtion in wine. > > So why this is a stub. > Sure, this diff against wine-git tree recent version. > You mean that's why it's #ifdefed? I don't know if we need this part, that can't be even built, as it's not clear how DXTN_COMPRESSION_SUPPORTED is supposed to be defined and where; but I leave this to actual wined3d devs to respond. P.S. please CC wine-devel next time you reply.

4 4

Re: [3/3] advapi32/tests: Add preliminary event tracing tests.
by Nikolay Sivov 09 Jun '15

09 Jun '15

On 08.06.2015 6:56, Zebediah Figura wrote: > + /* test ERROR_DISK_FULL */ > + properties->MaximumFileSize = 1000000000000; /* 1 EB */ > + SetLastError(0xdeadbeef); > + ret = StartTraceA(&handle, sessionname, properties); > + todo_wine > + { > + ok(ret != ERROR_SUCCESS, "Expected failure\n"); > + ok(GetLastError() == ERROR_DISK_FULL, "Expected ERROR_DISK_FULL, got %d\n", GetLastError()); > + } > + properties->MaximumFileSize = 0; Patches look fine to me, but I have to ask - is it possible that this test will actually try to write that much?

2 2

Re: gdiplus: Implement trivial case of GdipCreateRegionRgnData for empty and infinite regions
by Vincent Povirk 09 Jun '15

09 Jun '15

+ if (region_header->magic != VERSION_MAGIC) + return InvalidParameter; We should probably accept 0xdbc01002 as well here.

2 1

Re: [1/4] msvcirt: Add implementation of streambuf::allocate (try 2, resend)
by Piotr Caban 08 Jun '15

08 Jun '15

On 06/08/15 15:56, Iván Matellanes wrote: > + ok(sb.ebuf - sb.base == 512 , "wrong reserve area size, expected 512 got %d\n", sb.ebuf - sb.base); > + ok(sb2.ebuf - sb2.base == 512 , "wrong reserve area size, expected 512 got %d\n", sb2.ebuf - sb2.base); This will produce warning on 64-bit build. You can e.g. display both pointers in error message. Sorry for not spotting it earlier, Piotr

1 0

Wineconf proposal: discuss 64-bit?
by Josh DuBois 08 Jun '15

08 Jun '15

I'm wondering whether it would be useful to discuss 64-bit support in Wine at wineconf this year. I'm interested in feedback on whether it's a useful topic. With games in particular, 64-bit seems to be becoming a more common requirement, especially with newer DirectX 11 games (which may start running in wine ... sometime). I guess the basics work on Intel Linux. Several issues remain, however: - OS X support: compiler toolchains are an issue, there are problems with thread-local storage. - ARM support: I think Andre H. believes that 64-bit will be hard to support on ARM. As far as I know there aren't yet a lot of real-world use-cases for that, but there are certainly a lot of ARM chips around nowdays and maybe Windows 10 will start appearing on ARM devices. - MSI: I think there are MSI limitations which prevent some 64-bit apps from installing (e.g., bug 29941) . I think this blocks 64-bit MS Office. - Mono / .NET ? - Other ... ? It might be that there's not a great deal to do at wineconf other than catalog the issues. If it's worth a short (not an hour - maybe if we have some 10-15 minute segments) discussion while everyone is in the same place, I'd be happy to try and catalog them.

2 2

Re: [5/7] qmgr: Implement IBackgroundCopyJob::Cancel.
by Jacek Caban 08 Jun '15

08 Jun '15

Hi Hans, On 06/08/15 14:32, Hans Leidekker wrote: > --- > dlls/qmgr/file.c | 1 + > dlls/qmgr/job.c | 33 +++++++++++++++++++++++++++++++-- > 2 files changed, 32 insertions(+), 2 deletions(-) I don't know qmgr, but shouldn't it result in IBinding::Abort() call on underlying binding object? Jacek

2 2

Wineconf talk proposal: Wine and Valgrind
by Austin English 08 Jun '15

08 Jun '15

Howdy all, If anyone is interested, I can give a presentation on Wine/Valgrind, i.e. current status, major outstanding issues on either side, issues found/fixed, etc. Please let me know if you'd be interested. -Austin

2 1

Re: [PATCH 1/2] d3dx9_36: Implemented D3DXSaveVolumeToFile including DDS files
by Nikolay Sivov 08 Jun '15

08 Jun '15

On 08.06.2015 10:01, Sergey Isakov wrote: > It is hard to distill what part of codes comes from where. My patches depends on previous patches and so they must be included too. > OK, all copylefts must be included if I will know how to do this. > If Christian Costa will say what to do I will do this. Sure, let's hear his opinion. > > On 08.06.2015, at 9:43, Nikolay Sivov wrote: > >> On 07.06.2015 23:02, Sergey Isakov wrote: >>> I decided to improve builtin d3dx9_36 library with support of more file >>> formats, texture formats, volume textures. >> >> It's not your work though, it looks to me like 3 or so patches from Christian Costa squashed together. Why didn't you mention it? >

3 3

Re: xaudio2_7: Implement IXaudio2 interface as stub (try 4)
by Jacek Caban 08 Jun '15

08 Jun '15

Hi Guillaume, On 06/08/15 10:06, Guillaume Charifi wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=26808 > > --- > dlls/xaudio2_7/Makefile.in | 2 > dlls/xaudio2_7/xaudio_dll.c | 300 > ++++++++++++++++++++++++++++++++++++- > dlls/xaudio2_7/xaudio_classes.idl | 28 +++ > 3 files changed, 319 insertions(+), 11 deletions(-) > > > xaudio_2.7.dll.IXAudio2_stub.patch > > > diff --git a/dlls/xaudio2_7/Makefile.in b/dlls/xaudio2_7/Makefile.in > index 853d1d6..6bdf362 100644 > --- a/dlls/xaudio2_7/Makefile.in > +++ b/dlls/xaudio2_7/Makefile.in > @@ -3,3 +3,5 @@ IMPORTS = advapi32 kernel32 ole32 user32 uuid > > C_SRCS = \ > xaudio_dll.c > + > +IDL_SRCS = xaudio_classes.idl Adding registration IDL deserves a separated patch. > diff --git a/dlls/xaudio2_7/xaudio_dll.c b/dlls/xaudio2_7/xaudio_dll.c > index c8b7904..07c4780 100644 > --- a/dlls/xaudio2_7/xaudio_dll.c > +++ b/dlls/xaudio2_7/xaudio_dll.c > @@ -30,12 +30,15 @@ > #include "wine/debug.h" > #include <propsys.h> > #include "initguid.h" > + > #include "xaudio2.h" > > WINE_DEFAULT_DEBUG_CHANNEL(xaudio2); > > static HINSTANCE instance; > > +static HRESULT XAudio2_create(IUnknown *pUnkOuter, LPVOID *ppObj); > + > BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > { > TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved); > @@ -52,35 +55,310 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > return TRUE; > } > > -HRESULT WINAPI DllCanUnloadNow(void) > +typedef struct { > + IClassFactory IClassFactory_iface; > + HRESULT (*pfnCreateInstance)(IUnknown *pUnkOuter, LPVOID *ppObj); Please avoid using LP* types. This should be void**, but using IUnknown** would be even better. > +} IClassFactoryImpl; > + > +static inline IClassFactoryImpl *impl_from_IClassFactory(IClassFactory *iface) > { > - return S_FALSE; > + return CONTAINING_RECORD(iface, IClassFactoryImpl, IClassFactory_iface); > +} > + > +static HRESULT WINAPI XAudio2CF_QueryInterface(IClassFactory *iface, REFIID riid, void **ppobj) > +{ > + if(IsEqualGUID(riid, &IID_IUnknown) > + || IsEqualGUID(riid, &IID_IClassFactory)) > + { > + IClassFactory_AddRef(iface); > + *ppobj = iface; > + return S_OK; > + } > + > + *ppobj = NULL; > + WARN("(%p)->(%s, %p): interface not found\n", iface, debugstr_guid(riid), ppobj); > + return E_NOINTERFACE; > +} > + > +static ULONG WINAPI XAudio2CF_AddRef(IClassFactory *iface) > +{ > + return 2; > +} > + > +static ULONG WINAPI XAudio2CF_Release(IClassFactory *iface) > +{ > + return 1; > } > > +static HRESULT WINAPI XAudio2CF_CreateInstance(IClassFactory *iface, IUnknown *pOuter, > + REFIID riid, void **ppobj) > +{ > + IClassFactoryImpl *This = impl_from_IClassFactory(iface); > + HRESULT hr; > + LPUNKNOWN punk; Same here, use IUnknown* instead. > + > + TRACE("(%p)->(%p,%s,%p)\n", This, pOuter, debugstr_guid(riid), ppobj); > + > + *ppobj = NULL; > + hr = This->pfnCreateInstance(pOuter, (LPVOID *) &punk); > + if (FAILED(hr)) > + return hr; > + > + hr = IUnknown_QueryInterface(punk, riid, ppobj); > + IUnknown_Release(punk); > + return hr; > +} > + > +static HRESULT WINAPI XAudio2CF_LockServer(IClassFactory *iface, BOOL dolock) > +{ > + IClassFactoryImpl *This = impl_from_IClassFactory(iface); > + FIXME("(%p)->(%d): stub!\n", This, dolock); > + return S_OK; > +} > + > +static const IClassFactoryVtbl XAudio2CF_Vtbl = > +{ > + XAudio2CF_QueryInterface, > + XAudio2CF_AddRef, > + XAudio2CF_Release, > + XAudio2CF_CreateInstance, > + XAudio2CF_LockServer > +}; > + > +static IClassFactoryImpl xaudio2_cf = { { &XAudio2CF_Vtbl }, XAudio2_create }; > + > HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID *ppv) > { > + IClassFactory *factory = NULL; > + > TRACE("(%s, %s, %p)\n", debugstr_guid(rclsid), debugstr_guid(riid), ppv); > > - if (ppv == NULL) { > - WARN("invalid parameter\n"); > - return E_INVALIDARG; > + if(IsEqualGUID(rclsid, &CLSID_XAudio2)) { > + factory = &xaudio2_cf.IClassFactory_iface; How about simply return IClassFactory_QueryInterface(...) here? > } > + if(!factory) return CLASS_E_CLASSNOTAVAILABLE; > > - *ppv = NULL; > + return IClassFactory_QueryInterface(factory, riid, ppv); > +} > > - WARN("(%s, %s, %p): no class found.\n", debugstr_guid(rclsid), > - debugstr_guid(riid), ppv); > - return CLASS_E_CLASSNOTAVAILABLE; > +HRESULT WINAPI DllCanUnloadNow(void) > +{ > + return S_FALSE; > } > > HRESULT WINAPI DllRegisterServer(void) > { > TRACE("\n"); > - return __wine_register_resources( instance ); > + return __wine_register_resources(instance); > } > > HRESULT WINAPI DllUnregisterServer(void) > { > TRACE("\n"); > - return __wine_unregister_resources( instance ); > + return __wine_unregister_resources(instance); > +} > + > +typedef struct { > + IXAudio2 IXAudio2Impl_iface; > + LONG ref; > +} IXAudio2Impl; > + > +static inline IXAudio2Impl *impl_from_IXAudio2(IXAudio2 *iface) > +{ > + return CONTAINING_RECORD(iface, IXAudio2Impl, IXAudio2Impl_iface); > } > + > +static const struct IXAudio2Vtbl XAudio2_Vtbl; This is not needed. Please move XAudio2_create below the vtbl. > +HRESULT XAudio2_create(IUnknown *pUnkOuter, LPVOID *ppObj) > +{ > + IXAudio2Impl* object; > + > + TRACE("(%p, %p)\n", pUnkOuter, ppObj); > + > + if(pUnkOuter) > + return CLASS_E_NOAGGREGATION; > + > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IXAudio2Impl)); > + if(!object) > + return E_OUTOFMEMORY; > + > + object->IXAudio2Impl_iface.lpVtbl = &XAudio2_Vtbl; > + object->ref = 1; > + > + *ppObj = object; You shouldn't assign object type here, even if the pointer is the same ans interface. Use &object->IXAudio2Impl_iface instead. > + > + return S_OK; > +} > + > +/*** IUnknown methods ***/ > +static HRESULT WINAPI IXAudio2Impl_QueryInterface(IXAudio2 *iface, REFIID riid, void **ppvObject) > +{ > + IXAudio2Impl *This = impl_from_IXAudio2(iface); > + > + TRACE("(%p)->(%s, %p)\n", This, debugstr_guid(riid), ppvObject); > + > + if(IsEqualGUID(riid, &IID_IUnknown) || > + IsEqualGUID(riid, &IID_IXAudio2)) > + { > + IXAudio2_AddRef(iface); > + *ppvObject = iface; > + return S_OK; > + } > + > + ERR("(%p)->(%s,%p), not found\n", This,debugstr_guid(riid), ppvObject); This should be FIXME instead (or WARN, it depends on how likely apps are to call it with an interface that shouldn't be implemented). Also, QI is expected to set ppvObject to NULL on error. Thanks, Jacek

1 0

Re: dlls/winsta: add initial winsta.h (try 2)
by Alexandre Julliard 08 Jun '15

08 Jun '15

Austin English <austinenglish(a)gmail.com> writes: > updated TS_ALL_PROCESSES_INFO to one from > https://msdn.microsoft.com/en-us/library/cc248681.aspx Looks like you forgot that part. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Fail properly for unsupported classes in GetFileInformationByHandleEx
by Marvin 08 Jun '15

08 Jun '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=13968 Your paranoid android. === wvistau64 (32 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:444: Test failed: attributes of file "testfile.xxx" are 0x0820

2 1

Re: [3/3] advapi32/tests: Add preliminary event tracing tests.
by Marvin 08 Jun '15

08 Jun '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=13996 Your paranoid android. === w2000pro (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wxppro (32 bit eventlog) === eventlog.c:687: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2003std (32 bit eventlog) === eventlog.c:687: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w2008s64 (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w7u (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === w8 (32 bit eventlog) === eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got 87 eventlog.c:779: Test failed: Expected ERROR_BAD_PATHNAME, got 87 eventlog.c:791: Test failed: Expected ERROR_DISK_FULL, got 87 eventlog.c:798: Test failed: Expected success eventlog.c:806: Test failed: Expected ERROR_ALREADY_EXISTS, got 87 === wvistau64 (64 bit eventlog) === eventlog.c:695: Test failed: Expected failure eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got -559038737 eventlog.c:755: Test failed: Expected ERROR_INVALID_PARAMETER, got 183 eventlog.c:798: Test failed: Expected success === w2008s64 (64 bit eventlog) === eventlog.c:695: Test failed: Expected failure eventlog.c:696: Test failed: Expected ERROR_BAD_LENGTH, got -559038737 eventlog.c:755: Test failed: Expected ERROR_INVALID_PARAMETER, got 183 eventlog.c:798: Test failed: Expected success

1 0

Re: inetcpl: implement default page button (resend)
by Alexandre Julliard 08 Jun '15

08 Jun '15

Jared Smudde <computerwhiz02(a)hotmail.com> writes: > @@ -35,6 +35,7 @@ > WINE_DEFAULT_DEBUG_CHANNEL(inetcpl); > > static const WCHAR about_blank[] = {'a','b','o','u','t',':','b','l','a','n','k',0}; > +static const WCHAR default_home[] = {'h','t','t','p',':','/','/','w','w','w','.','w','i','n','e','h','q','.','o','r','g',0}; This should come from the registry. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/4] msvcirt: Add implementation of streambuf::allocate
by Piotr Caban 08 Jun '15

08 Jun '15

On 06/07/15 20:54, Iván Matellanes wrote: > + return CALL_VTBL_FUNC(this, 40, int, (streambuf*), (this)); The code will be easier to read if you define call_streambuf_doallocate macro and use it here. It would be also nice to change order of allocate and doallocate functions. Cheers, Piotr

1 0

Re: [PATCH 2/2] d3dx9_36: Implement triangle filter when create textures
by Nikolay Sivov 08 Jun '15

08 Jun '15

On 07.06.2015 23:13, Sergey Isakov wrote: > It is probably not triangle filter but works with similar result so I place it in appropriate places. > As well load surface and volume works with DXTn textures now. External conversion is a stub. > The best test will be graphical. See two sscreenshots: textures made by DxTex.exe (from DirectXSDK), one with point filter, second with triangle filter my version. > PS. About copyright. It is my mathematics. (c)Isakov S.L. > > +#ifdef DXTN_COMPESSION_SUPPORTED > + switch (format) > + { > + case D3DFMT_DXT1: > + if (!wined3d_dxtn_supported()) return NULL; > + return encode ? wined3d_dxt1_encode : wined3d_dxt1_decode; This diff is not against wine-git tree, there's no wined3d_dxtn_supported() funtion in wine.

1 0

Re: [PATCH 1/2] d3dx9_36: Implemented D3DXSaveVolumeToFile including DDS files
by Nikolay Sivov 08 Jun '15

08 Jun '15

On 07.06.2015 23:02, Sergey Isakov wrote: > I decided to improve builtin d3dx9_36 library with support of more file > formats, texture formats, volume textures. It's not your work though, it looks to me like 3 or so patches from Christian Costa squashed together. Why didn't you mention it?

1 0

Re: [1/3] ws2_32: Fix uninitialized memory access in do_poll (Coverity).
by Nikolay Sivov 07 Jun '15

07 Jun '15

On 30.05.2015 18:20, Sebastian Lackner wrote: > --- > dlls/ws2_32/socket.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I guess it fixes a warning, but timeout == 0 means no timeout and you don't need a timestamp. select() is the only user of it, and it has this: --- if (ws_timeout) timeout = (ws_timeout->tv_sec * 1000) + (ws_timeout->tv_usec + 999) / 1000; ret = do_poll(pollfds, count, timeout); --- so probably 0 value should be handled differently within a loop, or need to have a separate case that call poll() once and return right away.

1 0

programs/regsvr32: Do not set wsCommandLine multiple times
by Hugh McMaster 07 Jun '15

07 Jun '15

Please disregard this patch. The functionality is still needed.

1 0

Re: include: Convert vfw.h to vfw.idl.
by Nikolay Sivov 07 Jun '15

07 Jun '15

Hi, I see it went to pending, so let me suggest something. We need this idl mostly for automated proxy/stub generation and registration, right? Maybe we could introduce an idl that contains interfaces only and not all regular header stuff that vfw.h is made of. I would probably work to duplicate interfaces locally at dll level, and leave header alone.

2 1

Wineconf: workshop(s)?
by Marcus Meissner 07 Jun '15

07 Jun '15

Hi, I am wondering if it makes sense to hold a workshop / hack session and how to. As we seem to be accustomed to working as single developers this is a bit hard, also "making good use of available time" is a factor. Do we have scenarios where some hours of short term working together would benefit us? - We had regression triaging some years ago which was working okish I think, but might not have been the best use of time. - We also had a "make all tests green on my laptop" shared activity, which was also a bit useful. - Bug triaging is not really a team activity, although if its necessary we could just force everyone present to do it for some hours. - other things? Ciao, Marcus

2 1

Re: inetcpl: implement default page button (try 2)
by Andrew Eikum 05 Jun '15

05 Jun '15

Wine doesn't use the L string prefix, because unfortunately some compilers don't support it. Your previous patch has been marked Pending: <http://source.winehq.org/patches/>. I'd wait for another commit release cycle on Monday to see if that changes. Andrew On Fri, Jun 05, 2015 at 12:59:17PM -0500, Jared Smudde wrote: > This patch implements the button default page to set back the default homepage is the user changes the homepage. > --- >

1 0

Re: odbccp32: Add a trace message to functions
by Nikolay Sivov 05 Jun '15

05 Jun '15

> @@ -281,7 +281,7 @@ BOOL WINAPI SQLGetAvailableDriversW(LPCWSTR lpszInfFile, LPWSTR lpszBuf, > WORD cbBufMax, WORD *pcbBufOut) > { > clear_errors(); > - FIXME("\n"); > + FIXME("%s %s %d %p\n", debugstr_w(lpszInfFile), debugstr_w(lpszBuf), cbBufMax, pcbBufOut); This is wrong, because lpszBuf is out parameter. > @@ -370,6 +374,9 @@ BOOL WINAPI SQLGetInstalledDrivers(LPSTR lpszBuf, WORD cbBufMax, > int size_wbuf = cbBufMax; > LPWSTR wbuf; > WORD size_used; > + > + TRACE("%s %d %p\n", debugstr_a(lpszBuf), cbBufMax, pcbBufOut); > + Same here. > @@ -397,7 +404,9 @@ int WINAPI SQLGetPrivateProfileStringW(LPCWSTR lpszSection, LPCWSTR lpszEntry, > LPCWSTR lpszFilename) > { > clear_errors(); > - FIXME("\n"); > + FIXME("%s %s %s %p %d %s\n", debugstr_w(lpszSection), debugstr_w(lpszEntry), > + debugstr_w(lpszDefault), RetBuffer, cbRetBuffer, > + debugstr_w(lpszFilename)); > SetLastError(ERROR_CALL_NOT_IMPLEMENTED); And here.

1 0

Wine 64 bit
by Kevin Davies 05 Jun '15

05 Jun '15

Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin

13 31

Re: [PATCH 2/5] d3d9/tests: Add more tests for point size. (v3)
by Marvin 04 Jun '15

04 Jun '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=13876 Your paranoid android. === w8 (32 bit visual) === visual.c:10525: Test failed: Got unexpected color 0x00ff0000 (case 5, 3, size 0). visual.c:10525: Test failed: Got unexpected color 0x00ff0000 (case 7, 3, size 0). visual.c:10525: Test failed: Got unexpected color 0x00ff0000 (case 9, 3, size 0).

1 0

CSMT status?
by Forest 04 Jun '15

04 Jun '15

Can anyone offer a status update on D3D command stream multithreading? I've been packaging Stefan Dösinger's CSMT work, with over 500 people using my last release, and several asking when I'll build a new one. I don't know what to tell them, because his github repo hasn't been updated in half a year, and he hasn't responded to the email I sent him last week. It's starting to look like this excellent work has been abandoned. Pherhaps I missed an announcement? Has it already been integrated into mainline wine? Is there some other plan for it?

4 3

Re: inetcpl.cpl: implement default page button
by Andrew Eikum 04 Jun '15

04 Jun '15

Hi Jared, On Wed, Jun 03, 2015 at 08:29:03AM -0500, Jared Smudde wrote: > @@ -186,6 +186,10 @@ static INT_PTR general_on_command(HWND hwnd, WPARAM wparam) > case MAKEWPARAM(IDC_HOME_BLANK, BN_CLICKED): > SetDlgItemTextW(hwnd, IDC_HOME_EDIT, about_blank); > break; > + > + case MAKEWPARAM(IDC_HOME_DEFAULT, BN_CLICKED): This file is indented with spaces. Please don't introduce tabs or use whitespace at the end of a line. Thanks! Andrew

1 0

programs/regsvr32 patches
by Hugh McMaster 04 Jun '15

04 Jun '15

Excuse me, I've looked through patches 111564-111568 and have only found one minor issue. In patch 111565 I forgot to include ctype.h for tolower(). Was there a problem with the input comparison handling, or something else? The changes to the input handling make conversion to unicode much easier and cleaner. I realise that patch 111565 looks complex, but it's just the indenting. -- Hugh McMaster

1 1

Re: [PATCH] riched20: Fix link notification conditions and add tests.
by Nikolay Sivov 04 Jun '15

04 Jun '15

On 04.06.2015 9:34, Alex Henrie wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=35949 > --- > dlls/riched20/editor.c | 13 +++- > dlls/riched20/tests/editor.c | 178 +++++++++++++++++++++++++++++++++++++++---- > 2 files changed, 172 insertions(+), 19 deletions(-) > Looks good to me.

1 0

Re: ntdll/tests: Properly mark test failures with todo_wine.
by Alexandre Julliard 04 Jun '15

04 Jun '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -353,14 +353,18 @@ static void test_NtQueryDirectoryFile_case(void) > mask.Length = mask.MaximumLength = lstrlenW(testmask) * sizeof(WCHAR); > pNtQueryDirectoryFile(dirh, NULL, NULL, NULL, &io, data, data_size, > FileBothDirectoryInformation, TRUE, &mask, FALSE); > + todo_wine > ok(U(io).Status == STATUS_SUCCESS, "failed to query directory; status %x\n", U(io).Status); > data_len = io.Information; > + todo_wine > ok(data_len >= sizeof(FILE_BOTH_DIRECTORY_INFORMATION), "not enough data in directory\n"); > > name = dir_info->FileName; > name_len = dir_info->FileNameLength / sizeof(WCHAR); > > + todo_wine > ok(name_len == testfile_len, "unexpected filename length %u\n", name_len); > + todo_wine I don't see any failure here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: TestBot job 13726 results: [PATCH 2/2] d3d9/test: implemented tests for UpdateTexture method
by Sergey Isakov 04 Jun '15

04 Jun '15

It may mean that Win8 contains a bug. Use Windows Update. On 01 июня 2015 г., at 3:05, Marvin <testbot(a)winehq.org> wrote: > VM Status Number of test failures > build completed > w2000pro completed 0 > wxppro completed 0 > w2003std completed 0 > wvistau64 completed 0 > w2008s64 completed 0 > w7u completed 0 > w8 completed 3 > wvistau64 completed 0 > w2008s64 completed 0 > > === build (build) === > No build failures found > > === w2000pro (32 bit visual) === > No test failures found > > === wxppro (32 bit visual) === > No test failures found > > === w2003std (32 bit visual) === > No test failures found > > === wvistau64 (32 bit visual) === > No test failures found > > === w2008s64 (32 bit visual) === > No test failures found > > === w7u (32 bit visual) === > No test failures found > > === w8 (32 bit visual) === > > d3d9: > visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 0, 8. > visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 1, 8. > visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 2, 8. > > === wvistau64 (64 bit visual) === > No test failures found > > === w2008s64 (64 bit visual) === > No test failures found<build.log><w2000pro.log><wxppro.log><w2003std.log><wvistau64.log><w2008s64.log><w7u.log><w8.log><wvistau64.log><w2008s64.log>

1 0

Re: wbemprox: Treat \r as whitespace.
by Marvin 04 Jun '15

04 Jun '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=13841 Your paranoid android. === wvistau64 (64 bit query) === The test timed out

2 1

Re: shlwapi: Fix error handling in IUnknown_GetClassID (Coverity)
by Marvin 03 Jun '15

03 Jun '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=13825 Your paranoid android. === w2000pro (32 bit ordinal) === ordinal.c:3225: Test failed: got wrong clsid {cccccccc-cccc-cccc-cccc-cccccccccccc} === wxppro (32 bit ordinal) === ordinal.c:3225: Test failed: got wrong clsid {cccccccc-cccc-cccc-cccc-cccccccccccc} === w2003std (32 bit ordinal) === ordinal.c:3225: Test failed: got wrong clsid {cccccccc-cccc-cccc-cccc-cccccccccccc}

1 0

Re: [PATCH 2/5] wined3d: Clamp per-vertex point size in vertex shaders.
by Henri Verbeet 03 Jun '15

03 Jun '15

On 2 June 2015 at 16:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -6711,7 +6721,8 @@ static void set_glsl_shader_program(const struct wined3d_context *context, const > WORD map = vshader->reg_maps.input_registers; > struct wined3d_string_buffer *tmp_name = string_buffer_get(&priv->string_buffers); > > - reorder_shader_id = generate_param_reorder_function(priv, vshader, pshader, gl_info); > + reorder_shader_id = generate_param_reorder_function(priv, vshader, pshader, > + state->gl_primitive_type == GL_POINTS && vshader->reg_maps.point_size, gl_info); This works because "state->gl_primitive_type == GL_POINTS" is mirrored in struct vs_compile_args, but it isn't necessarily very obvious or pretty.

2 2

Re: [PATCH 3/5] wined3d: Handle point sprites with PS 3.0.
by Henri Verbeet 03 Jun '15

03 Jun '15

On 2 June 2015 at 16:39, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + else if (args->pointsprite && shader_match_semantic(semantic_name, WINED3D_DECL_USAGE_TEXCOORD)) > + shader_addline(buffer, "ps_in[%u].xy = vec2(gl_PointCoord.x, gl_PointCoord.y);\n", input->register_idx); Why not "ps_in[%u].xy = gl_PointCoord.xy;\n"? Also, do the z and w components have a defined value?

2 1

Re: [1/2] msvcirt: Add initial implementation of streambuf (try 3)
by Piotr Caban 03 Jun '15

03 Jun '15

On 06/03/15 13:50, Iván Matellanes wrote: > +DEFINE_RTTI_DATA0(streambuf, 0, ".?AVstreambuf@@") You need to call init_streambuf_rtti function to initialize RTTI in 64-bit case. Cheers, Piotr

1 0

Re: [1/2] msvcirt: Add initial implementation of streambuf (try 2)
by Piotr Caban 03 Jun '15

03 Jun '15

On 06/02/15 18:20, Iván Matellanes wrote: > +/* ?seekoff@streambuf@@UAEJJW4seek_dir@ios@@H@Z */ > +/* ?seekoff@streambuf@@UEAAJJW4seek_dir@ios@@H@Z */ > +DEFINE_THISCALL_WRAPPER(streambuf_seekoff, 16) > +long __thiscall streambuf_seekoff(streambuf *this, long offset, int dir, int mode) > +{ > + FIXME("(%p %ld %d %d): stub\n", this, offset, dir, mode); > + return EOF; > +} You can't use long type here, please use LONG instead (it's used also in some other functions). Thanks, Piotr

1 0

Re: include: add initial winsta.h
by Austin English 03 Jun '15

03 Jun '15

On Tue, May 26, 2015 at 10:21 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin Patch has been pending for several days, is there something I can do to improve it? Nikolay asked in #winehackers where this came from, it's on MSDN: https://msdn.microsoft.com/en-us/library/cc248871.aspx and also in Process Hacker's source: http://processhacker.sourceforge.net/doc/winsta_8h_source.html -- -Austin

2 4

Re: [PATCH 5/5] d3d8/tests: Port the point size test to D3D8.
by Marvin 02 Jun '15

02 Jun '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=13782 Your paranoid android. === w8 (32 bit visual) === visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 0, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 1, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 2, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 3, 3, size 0). visual.c:6788: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 4, 7, size 0).

1 0

Re: [PATCH 4/5] d3d9/tests: Add more tests for point size.
by Marvin 02 Jun '15

02 Jun '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=13781 Your paranoid android. === w8 (32 bit visual) === visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 0, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 1, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 2, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 3, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x00000000 (case 4, 3, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x0000ff00 (case 5, 7, size 0). visual.c:10462: Test failed: Expected color 0x0000ffff, got 0x00000000 (case 6, 7, size 0).

1 0

Re: [2/2] msvcirt/tests: Add initial tests for streambuf (try 2)
by Marvin 02 Jun '15

02 Jun '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=13771 Your paranoid android. === wvistau64 (64 bit msvcirt) === No test summary line found === w2008s64 (64 bit msvcirt) === No test summary line found

1 0

Re: [PATCH 1/3] ntdll: Implemenent ObjectTypeInformation class support in NtQueryObject.
by Nikolay Sivov 02 Jun '15

02 Jun '15

On 01.06.2015 12:52, Qian Hong wrote: > Hi, > > This patch fixed QQ crashing on recent Wine. Thanks Sebastian for > improving my patch. > Tested with wine-staging for weeks. > > --- > dlls/ntdll/om.c | 64 > +++++++++++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/tests/om.c | 28 +++++++++++----------- > server/directory.c | 5 ---- > server/handle.c | 18 +++++++++++++++ > server/object.h | 5 ++++ > server/protocol.def | 9 ++++++++ > 6 files changed, 110 insertions(+), 19 deletions(-) > > + if (!(status = server_get_unix_name( handle, &unix_name ))) > + { > + static const WCHAR type_fileW[] = {'F','i','l','e','\0'}; > + int type_size = sizeof(type_fileW); > + > + if (len < sizeof(*p)) > + status = STATUS_INFO_LENGTH_MISMATCH; > + else if (len < sizeof(*p) + type_size) > + status = STATUS_BUFFER_OVERFLOW; > + else > + { > + p->TypeName.Buffer = (WCHAR *)(p + 1); > + p->TypeName.Length = type_size - sizeof(WCHAR); > + p->TypeName.MaximumLength = type_size; > + memcpy( p->TypeName.Buffer, type_fileW, type_size ); > + > + } > + if (used_len) *used_len = sizeof(*p) + type_size; > + RtlFreeAnsiString( &unix_name ); > + break; > + } Why do you need a separate server call/special case for files?

2 1

Re: [1/2] msvcirt: Add initial implementation of streambuf
by Piotr Caban 02 Jun '15

02 Jun '15

On 06/02/15 14:52, Iván Matellanes wrote: > + __ASM_VTABLE(streambuf, > + VTABLE_ADD_FUNC(streambuf_vector_dtor)); It would be nice to add all the functions to vtable. Otherwise the application may crash without nice error message.

1 0

Re: [1/2] msvcirt: Add initial implementation of streambuf
by Piotr Caban 02 Jun '15

02 Jun '15

On 06/02/15 14:52, Iván Matellanes wrote: > +/* ??0streambuf@@IAE@XZ */ > +/* ??0streambuf@@IEAA@XZ */ > +DEFINE_THISCALL_WRAPPER(streambuf_ctor, 4) > +streambuf* __thiscall streambuf_ctor(streambuf *this) > +{ > + TRACE("(%p)\n", this); > + this->vtable = &MSVCP_streambuf_vtable; > + this->allocated = 0; > + this->unbuffered = 0; > + this->unknown = -1; > + this->unknown2 = -1; > + streambuf_setb(this, NULL, NULL, 0); > + streambuf_setg(this, NULL, NULL, NULL); > + streambuf_setp(this, NULL, NULL); > + InitializeCriticalSection(&this->lock); > + return this; > +} Can't it be simplified to: streambuf* __thiscall streambuf_ctor(streambuf *this) { return streambuf_reserve_ctor(this, NULL, 0); } ?

2 1

Re: msvcirt/tests: Add initial tests for streambuf
by Piotr Caban 02 Jun '15

02 Jun '15

On 06/02/15 12:47, Iván Matellanes wrote: > +todo_wine{ > + /* constructors */ > + call_func1(p_streambuf_ctor, &sb); You'll need to add streambuf_ctor stub in wine before you can test it. Currently the tests will fail with exception. Please also set &sb memory to something so you can detect uninitialized values. Please also call streambuf_dtor. Cheers, Piotr

2 2

Re: [PATCH 2/3] riched20: Reduce code duplication in WM_SETTEXT/WM_CREATE handler
by Dmitry Timoshkov 02 Jun '15

02 Jun '15

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + if (lParam) > + text = unicode ? (void*)createW->lpszName : (void*)createA->lpszName; These casts should not be needed. -- Dmitry.

3 2

Re: gdi32: Return default palette entries from GetSystemPaletteEntries for non-palette-based devices. (try 2)
by Sebastian Lackner 02 Jun '15

02 Jun '15

On 01.06.2015 17:51, Anton Baskanov wrote: > + if (entries && start < 256) > + { > + UINT i; > + const RGBQUAD *default_entries; > + > + if (start + count > 256) count = 256 - start; > + > + default_entries = get_default_color_table( 8 ); > + for (i = 0; i < count; ++i) > + { > + if (i < 10 || i >= 246) > + { That condition is obviously wrong. Feel free to merge the changes and additional tests from my improved patchset which is included in Wine-Staging: https://github.com/wine-compholio/wine-staging/blob/master/patches/gdi32-De… > + entries[i].peRed = default_entries[start + i].rgbRed; > + entries[i].peGreen = default_entries[start + i].rgbGreen; > + entries[i].peBlue = default_entries[start + i].rgbBlue; > + } > + else > + { > + entries[i].peRed = 0; > + entries[i].peGreen = 0; > + entries[i].peBlue = 0; > + } > + entries[i].peFlags = 0; > + }

2 1

Re: [PATCH 2/2] d3d9/test: implemented tests for UpdateTexture method
by Matteo Bruni 01 Jun '15

01 Jun '15

2015-05-27 21:55 GMT+02:00 Sergey Isakov <isakov-sl(a)bk.ru>: > The test was initially written by Matteo Bruni > https://www.winehq.org/pipermail/wine-patches/2015-April/138974.html > but rejected as failed > https://www.winehq.org/pipermail/wine-devel/2015-April/107491.html For the records, my tests failed for Alexandre on Linux because of a bug in the Nouveau drivers which is fixed by Mesa commit f617029db3f8786d94c64f1a73c42b89b6d261fa. I'll resend the unmodified tests at some point.

1 0

Re: [PATCH 1/2] wined3d: fix wrong level calculation implemented in 1.7.42
by Matteo Bruni 01 Jun '15

01 Jun '15

2015-05-27 21:45 GMT+02:00 Sergey Isakov <isakov-sl(a)bk.ru>: > Bug 38048. > It is closed by wrong fix 5af656ea85e22a00304f1904e91ccfee52a6ccc5 > According to MSDN > https://msdn.microsoft.com/en-us/library/windows/desktop/bb205858(v=vs.85).… > “If the source texture has fewer levels than the destination, the method > will fail.” > The method must fail > 1. To prevent fail on undefined levels. > 2. To inform caller that the call is wrong. > The correct patch attached. > Test will follow next commit As I already mentioned, MSDN is wrong in this case, like in many other cases. UpdateTexture never returns failure when using hardware devices on Windows.

1 0

Re: [1/3] shell32/tests: Make tests run on win2k again.
by Marvin 01 Jun '15

01 Jun '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=13744 Your paranoid android. === w2003std (32 bit shlfolder) === shlfolder.c:4997: Test failed: MKDIR: Expected wndproc to be called shlfolder.c:4910: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 8) shlfolder.c:4997: Test failed: CREATE: Expected wndproc to be called shlfolder.c:4910: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 2) shlfolder.c:4997: Test failed: RMDIR: Expected wndproc to be called shlfolder.c:4910: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 10) shlfolder.c:4997: Test failed: MKDIR: Expected wndproc to be called shlfolder.c:4910: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 468) shlfolder.c:4997: Test failed: CREATE: Expected wndproc to be called shlfolder.c:4910: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 468) shlfolder.c:4997: Test failed: RMDIR: Expected wndproc to be called shlfolder.c:4910: Test failed: Didn't expect a WM_USER_NOTIFY message (event: 468)

1 0

Fix GetRawInputDeviceList() to return ERROR_INSUFFICIENT_BUFFER
by achurch＠achurch.org 01 Jun '15

01 Jun '15

(Note: I am not subscribed to the list; please CC me on any replies.) When GetRawInputDeviceList() is passed a buffer which is too small, the function should set the last error code to ERROR_INSUFFICIENT_BUFFER and return failure (see <http://msdn.microsoft.com/en-us/library/windows/desktop/ms645598(v=vs.85).a…>). However, the current Wine implementation does not set the last error code, meaning that callers expecting to see ERROR_INSUFFICIENT_BUFFER will behave incorrectly. I've confirmed that Windows itself (at least XP and 8) matches the documented behavior. See also: https://bugs.winehq.org/show_bug.cgi?id=37667 --Andrew Church http://achurch.org/ diff -urN wine-1.7.43-orig/dlls/user32/input.c wine-1.7.43/dlls/user32/input.c --- wine-1.7.43-orig/dlls/user32/input.c 2015-05-15 22:36:39 +0900 +++ wine-1.7.43/dlls/user32/input.c 2015-05-25 22:47:49 +0900 @@ -507,6 +507,7 @@ if (*device_count < 2) { *device_count = 2; + SetLastError(ERROR_INSUFFICIENT_BUFFER); return ~0U; } diff -urN wine-1.7.43-orig/dlls/user32/tests/Makefile.in wine-1.7.43/dlls/user32/tests/Makefile.in --- wine-1.7.43-orig/dlls/user32/tests/Makefile.in 2015-05-15 22:36:39 +0900 +++ wine-1.7.43/dlls/user32/tests/Makefile.in 2015-05-25 22:48:27 +0900 @@ -17,6 +17,7 @@ menu.c \ monitor.c \ msg.c \ + rawinput.c \ resource.c \ scroll.c \ static.c \ diff -urN wine-1.7.43-orig/dlls/user32/tests/rawinput.c wine-1.7.43/dlls/user32/tests/rawinput.c --- wine-1.7.43-orig/dlls/user32/tests/rawinput.c 1970-01-01 09:00:00 +0900 +++ wine-1.7.43/dlls/user32/tests/rawinput.c 2015-05-25 22:44:36 +0900 @@ -0,0 +1,43 @@ + /* Unit test suite for the rawinput functions + * + * Copyright 2015 Andrew Church + * + * 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 + */ + +#define WINVER 0x0501 + +#include "wine/test.h" +#include "windef.h" +#include "winbase.h" +#include "winuser.h" + +static void GRIDLShortArrayTest() +{ + RAWINPUTDEVICELIST devices[1]; + UINT device_count = 1; + int result, error; + + result = GetRawInputDeviceList(devices, &device_count, sizeof(*devices)); + ok(result == ~0U, "wrong result: %d\n", result); + ok(device_count >= 2, "wrong device_count: %d\n", device_count); + error = GetLastError(); + ok(error == ERROR_INSUFFICIENT_BUFFER, "wrong error code: %d\n", error); +} + +START_TEST(rawinput) +{ + GRIDLShortArrayTest(); +}

2 1

Re: [PATCH] mshtml: add NULL check to avoid crashing due to Gecko bug
by Jacek Caban 01 Jun '15

01 Jun '15

On 06/01/15 13:11, Indrek Altpere wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=34808 > > There seems to be a known bug in Gecko engine that causes iframe with display:none contents to return NULL nsstyle from nsIDOMWindow_GetComputedStyle > https://bugzilla.mozilla.org/show_bug.cgi?id=548397 > --- > dlls/mshtml/htmlcurstyle.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/mshtml/htmlcurstyle.c b/dlls/mshtml/htmlcurstyle.c > index 5f6cb35..f0b0d98 100644 > --- a/dlls/mshtml/htmlcurstyle.c > +++ b/dlls/mshtml/htmlcurstyle.c > @@ -1343,6 +1343,11 @@ HRESULT HTMLCurrentStyle_Create(HTMLElement *elem, IHTMLCurrentStyle **p) > return E_FAIL; > } > > + if(!nsstyle) { > + ERR("GetComputedStyle returned NULL nsstyle\n"); > + return E_FAIL; > + } We could try to work around the problem in Gecko, but it's obviously even better if it's fixed in Gecko. Anyway, if it fixes a bug I'm fine with the patch as is. Thanks, Jacek

1 0

Re: [PATCH] mshtml: add NULL check to get_frame_by_name
by Jacek Caban 01 Jun '15

01 Jun '15

On 05/29/15 15:51, Indrek Altpere wrote: > Fixes https://bugs.winehq.org/show_bug.cgi?id=34982 > --- > dlls/mshtml/htmlwindow.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index 618648e..c53ea16 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -406,6 +406,11 @@ HRESULT get_frame_by_name(HTMLOuterWindow *This, const WCHAR *name, BOOL deep, H > > nsIDOMWindow_Release(nswindow); > > + if(!window_iter) { > + WARN("nsIDOMWindow without HTMLOuterWindow: %p\n", nswindow); > + continue; > + } > + The real question is why there is no HTMLOuterWindow created for given window, but I'm fine with the patch. Thanks, Jacek

1 0

Re: [PATCH 1/3] ntdll: Implemenent ObjectTypeInformation class support in NtQueryObject.
by Nikolay Sivov 01 Jun '15

01 Jun '15

On 01.06.2015 12:52, Qian Hong wrote: > +/* Query object type name information */ > +@REQ(get_object_typename) > + obj_handle_t handle; /* handle to the object */ > +@REPLY > + data_size_t total; /* needed size for type name */ > + VARARG(typename,unicode_str); /* type name */ > +@END > + Also, do we really need to transfer a string? It seems to be that you can use an index and a static array at ntdll side.

1 0

Re: [PATCH] Do not run update-desktop-database on make install/uninstall
by Damjan Jovanovic 01 Jun '15

01 Jun '15

Not all of us install Wine through a package manager, and update-desktop-database is useful in that case. What that Makefile should probably be doing instead, is calling update-desktop-database only on the desktop directory where wine.desktop was just installed, where it will succeed without root privileges, ie.: -$(UPDATE_DESKTOP_DATABASE) $(DESTDIR)$(datadir)/applications Thank you Damjan On Sun, May 31, 2015 at 8:12 AM, Jerome Leclanche <jerome(a)leclan.ch> wrote: > This causes root invocations of "make install" in a chroot to error > It is the maintainer's or the package manager's job to run it, instead. > > Fixes bug #35191 > > J. Leclanche > > >

2 1

Re: [PATCH] wined3d: fix color in range comparison
by Nikolay Sivov 01 Jun '15

01 Jun '15

On 27.05.2015 20:12, Sergey Isakov wrote: > I think the patch must be accepted because original codes are more wrong. > > Tests will be created when WINED3D_CKEY_COLORSPACE will be implemented. Tests are needed to prove that your patch is correct. > > The game affected is in bug 38581. > > Meanwhile, the policy to reject any patches is not constructive. > If one developer propose not perfect codes then next developer can > correct them and obtain a result. > If you rejected the first developer then you will not have a result. That's not how it works. > > Best wishes! > > > On 27 мая 2015 г., at 10:39, Stefan Dösinger <stefandoesinger(a)gmail.com > <mailto:stefandoesinger@gmail.com>> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Am 2015-05-26 um 14:41 schrieb Sergey Isakov: >>> +#define RED_KEY(x) (x & 0xff0000) >>> +#define GREEN_KEY(x) (x & 0x00ff00) >>> +#define BLUE_KEY(x) (x & 0x0000ff) >>> + return ((RED_KEY(color) >= >>> RED_KEY(color_key->color_space_low_value)) && >>> + (RED_KEY(color) <= >>> RED_KEY(color_key->color_space_high_value)) && >>> + (GREEN_KEY(color) >= >>> GREEN_KEY(color_key->color_space_low_value)) && >>> + (GREEN_KEY(color) <= >>> GREEN_KEY(color_key->color_space_high_value)) && >>> + (BLUE_KEY(color) >= >>> BLUE_KEY(color_key->color_space_low_value)) && >>> + (BLUE_KEY(color) <= >>> BLUE_KEY(color_key->color_space_high_value))); >>> +#undef RED_KEY >>> +#undef GREEN_KEY >>> +#undef BLUE_KEY >> The basic idea is most likely right, but it needs tests. Do you have a >> game that needs this behavior? >> >> The way you're extracting individual colors from the key is wrong. The >> bitmasks depend on the texture format. >> >> The code you're modifying is unused on any modern GPU. On GPUs that >> support ARB_fragment_program or GLSL we do the color key comparison in >> the fragment shader nowadays. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBAgAGBQJVZXSWAAoJEN0/YqbEcdMwbEUP/RM4QUsbdSzhSLyIz5j00Epb >> AW1ZcNOg61yrfymjHdhJkqfdNmEiKQFsRshD+ZQAxVHqMsZLTxXtRFfBB14WtmNI >> Ng5jwwiAzDqlmpjftlZ4CmkR1w7DMxH6Nt4e9OQBlDKShSIoGngL6RremV+2Wq+f >> nNC6HfdmUiAIReVvI2aMm5B9C5L624SKLvoAZNI8QW+HJeZeESSGmT9bx4IRVQwl >> QX+aKojT43CJwq6UpZRu7ZkniotrmO9aDC+6S3S0od0ZJWSP5Q9upCNWNcN+iPG7 >> 9kCPwZMsEAxNUjvh/wQx8xE1+wiR7Ugjl/X6yTN8HFesFHChrqC2UeHUAkUKU++L >> WC4kwijfbktKSZnIiSvrTAzWvLOeCZMifFQqm8aqmlOqyvbNwyOJjh6yM/nqZi+c >> 2aEdEIMY5aaoswDIlyGRRN57zeWtqjZVmg7UzVxmZqfiocmUVxgdmdRv8BvFi0RF >> R4A6YTDP5EYb33SvH3qQE5kIrtDdtL8qtanmBsuHnhhwd1rdgeeq/9N0tqSjH1GQ >> s8vsXVmd3qU+mQMzyaxN9Cc9RGxGNgd+g1LkkoPqe+aVUw/JDzvAdMDGpy63zjhM >> QUlfS771f+Zt43wku/20XP1engXXti4m+KfnSOS3nCdKO1xRKOGHAMlUZzd8+jhU >> 2rWKuh42D3mSMDk1OhLR >> =IdO/ >> -----END PGP SIGNATURE----- > > > >

1 0

Re: [PATCH 2/2] d3d9/test: implemented tests for UpdateTexture method
by Marvin 01 Jun '15

01 Jun '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=13726 Your paranoid android. === w8 (32 bit visual) === visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 0, 8. visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 1, 8. visual.c:18560: Test failed: Unexpected result on update texture, hr 0, should fail, case 2, 8.

1 0

Re: [PATCH 2/5] riched20/tests: Small test for GetClientSite()
by Marvin 31 May '15

31 May '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=13718 Your paranoid android. === w2000pro (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === wxppro (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === w2003std (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0042D1B0 === wvistau64 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at A574D492 === w2008s64 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 00000000 === w7u (32 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 10000000 === w8 (32 bit richole) === richole.c:1526: Test failed: got wrong pointer === wvistau64 (64 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 0000000000426DF0 === w2008s64 (64 bit richole) === richole.c:1526: Test failed: got wrong pointer richole: unhandled exception c0000005 at 000007FEFEE619B8

1 0

Re: [PATCH 1/2] msvcp110: Add _File_size implementation and test.(try 2)
by YongHao Hu 29 May '15

29 May '15

Sry, Slackner found that I still used %llx /%llu as I misunderstood Piotr's comment and there are typos in the patch. I will fix all the issues later. :P On 2015年05月29日 21:16, YongHao Hu wrote: > try2: > Improve the patch according to Piotr's advices. > Add errno and SetLastError test. > --- > dlls/msvcp110/msvcp110.spec | 4 +- > dlls/msvcp120/msvcp120.spec | 4 +- > dlls/msvcp120/tests/msvcp120.c | 75 > +++++++++++++++++++++++++++++++++---- > dlls/msvcp120_app/msvcp120_app.spec | 4 +- > dlls/msvcp90/ios.c | 20 ++++++++++ > 5 files changed, 94 insertions(+), 13 deletions(-) > >

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 12)
by Stefan Dösinger 29 May '15

29 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This version of the patch looks good to me. Stefan Am 2015-05-29 um 12:06 schrieb Alistair Leslie-Hughes: > Hi, Add WARN on errors. > > I'll add more tests in another patch, which simplifies the > component list. > > Changelog: dpnet: Implement IDirectPlay8Address > GetComponentByIndex > > > Best Regards Alistair Leslie-Hughes > > > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaE3VAAoJEN0/YqbEcdMwqIAP/iHHkRWQmGrZnoKbvuXuYJ9i caO0PB0akO3CvyLDcC68CMtT7jQ7gthTGPiXTHe4sEjmSR3KLoqajV2TX+JluWYj s/uTxbmPjNvafeXmflSpaoy0BRq5H/D+99AkKqo/GFPlCNT0UJpR9sD7OsXXA1E9 Cq7VpKMGqgnWoLf4/pRge/rBfV2vV0FOLhHTzboEyUOTgGegOI8v345vMw/Ph7RM YPEdLYUBkIwZZuZaDtaZ9DV5HyFG1fH65cYftkQFmM7tH4Sn1NiQcNHEUmPeX3Bc hv5Q9QOshwtWgQKhWe98YyGayP16Ip0iKDpxRZ28LEcOcKfK9URX66lBNWZjL/Ci IixsgZw12okh8Wn+Q76LwIh1PakpQSHZ/iQW8qDYlyWIRboFC+VyQoemkXxvUfVS VwqAe/D1uWAf1o6BD6vHNarH7A5ymHvxmcxw/1PxTGSZg4RBqOmt4/4gCWIuPXzX 564O8wrDn1msVhwS6tqpP85Sg3ydDYiPDVZNVigJAU/kMCiPH2WbXPxUGB/Pc7hA 4QaOK6FDTxXlTqEO0FHm12DU2bYzBMogOd0N6usKzVQe2kdy9hB4/hUo8+vojamS AI0agXg+a6UjVhTpNZvoZAxC0rFF6nEJaL6MgDS64LtmT6wrrri6hEtmPJM6aC/O 2bdo052EPFKWbfytsTK+ =jq9B -----END PGP SIGNATURE-----

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 12)
by Marvin 29 May '15

29 May '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=13666 Your paranoid android. === w8 (32 bit address) === Failure running script in VM: timed out waiting for the child process

1 0

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 11)
by Stefan Dösinger 29 May '15

29 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There's one major problem I missed previously: Am 2015-05-29 um 10:22 schrieb Alistair Leslie-Hughes: > + case DPNA_DATATYPE_STRING: > + memcpy(pvBuffer, &entry->data.string, entry->size); > + break; This won't work. There's a & too much. Please consider adding tests for String and Binary types to catch this kind of thing. GetComponentByName once had the same problem I believe. Minor stuff: > + TRACE("(%p)->(%d %p %p %p %p %p)\n", This, dwComponentID, pwszName, pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); pdwNameLen, pvBuffer, pdwBufferSize, pdwDataType); A DWORD is unsigned, %u is better. > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + *pdwDataType = entry->type; > + return DPNERR_BUFFERTOOSMALL; > + } You forgot to add a WARN here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVaCrwAAoJEN0/YqbEcdMwypEP/RttOLSqc6fQQW4XeMkBgVaS aiKUyYSysq9MnRoqP32A6lKq9LHpW23liKsvpwoWegdarTc35ENYwG7pLSLJuOIy i/e7AlWGLDphN9qdYMU0oCQ8PXGU8Y3Mb7kozZcnYm9EuYoJEFIiAYHtx4nFeGMj rVx/mruLmYTdgyR378iE4cYqNeMwzK7YtGNRHMPz8FNTzdLyzUu1blYQ8cYEbzAk Mm4RaIixByzKiGO7qUPCX4OOgYoohBOgMRiVWTJfZLrhKY0vyj0x2Jt5GWCzWeht 7mszNRRpvW+v60axT2xwemXmQSobjgjnddF0bwxC/vHZisfXF8H52lLgupXv9KRo efOsvX3lTpJstEL1Wt61NL/MqF4vwRjbrWeKD45DxHEzPX8wzUg4yFodz/yxAAN1 /l4fuX8BEjr9tttV4uup4fdOlVhlX95ZujQFT5Ue1zF97SSLOC9id/8Uy8xlHYmY Ou0H9GG5rILqG5+r9m3OghjuQcwomL6T7BSLYJ+WncdTgtxRbarhMI/mq9m0MiB2 OHkUddm/zn9EFPboQsCjqRuPFa6fcbx+b/XUmyLeBjosO3j7Otws4TGUEkzjbvWF f3fOORfbxpknZH9GxVaEFWlyUerNSJ4C4hYp5J+pHS9N5u+L9KsN0fXYT9jqpvh2 Tmu94XyHSblAoeS1ORgq =M5Sz -----END PGP SIGNATURE-----

1 0

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