July 2015 - Wine-Devel - list.winehq.org

Re: [1/2] ole32: Add a storage test using a custom ILockBytes.
by Marvin July 6, 2015

July 6, 2015

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=15093 Your paranoid android. === w7u (32 bit storage32) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [PATCH 3/8] winex11.drv: implement DoDragDrop on top of XDND
by Ken Thomases July 6, 2015

July 6, 2015

On Jul 4, 2015, at 8:36 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > Implements DoDragDrop on top of XDND. While some of DoDragDrop() and > supporting functions are copied from ole32, they were modified to be > non-blocking and event-driven. > > The clipboard is patched to allow searching its clipboard formats for > X11 atoms, export data in X11 format, and forward selection requests > for the XdndSelection selection to XDND. > > We support XDND version 3 to 5 (although we still need XdndProxy > support for version 4). XdndPosition messages are rate-limited to at > most 1 unreplied message and at least every 50 milliseconds apart, so > that we don't flood slow X11 clients like the spec warns. In set_XdndTypeList() and X11DRV_XDND_SelectionRequest(), you use FIXMEs for most unsupported format properties, but just a TRACE for dwAspect != DVASPECT_CONTENT. Is there a reason for that? > + * When we ask for feedback from the drop source, sometimes it will > + * do all the necessary work and sometimes it will not handle it > + * when that's the case, we must display the standard drag and drop > + * cursors. Copy-pasted typo. There should be a period after "handle it" and we should capitalize "when that's the case". (Or change to "When it doesn't handle it" to be clearer.) > + /* > + * All the return valued will stop the operation except the S_OK > + * return value. > + */ Copy-pasted typo: "return valued" should be "return values". > + /* > + * When keyboard messages are sent to windows on this thread, we > + * want to ignore notify the drop source that the state changed. > + * in the case of the Escape key, we also notify the drop source > + * we give it a special meaning. > + */ Copy-pasted typo: "ignore notify". I'm not sure if the fix is to just drop "ignore" or to expand the sentence to explain that we swallow key events except to notify the drop source about the Escape key. -Ken

1 0

Re: [PATCH 2/8] ole32/user32/winemac.drv/winex11.drv: try using native drag and drop if possible
by Ken Thomases July 6, 2015

July 6, 2015

Hi, > On Jul 4, 2015, at 8:36 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > If possible, try using the drag and drop implemented by the native > windowing system instead of the one implemented by our ole32. This > patch just provides the framework, the next patch actually implements > all drag and drop over XDND. Thanks for doing this redesign. For this patch, is it necessary to add the driver entry point to the user drivers (winemac, winex11)? Since the null driver already returns E_NOTIMPL, it would seem the user drivers don't need to provide an entry point that just does the same thing. Is there a reason there's no loaderdrv_DoDragDrop()? Is it not possible for DoDragDrop() to be called before the driver has been loaded? -Ken

1 0

Re: [PATCH 1/2] shell32/tests: Win XP splits the args if there are spaces in the path.
by Marvin July 6, 2015

July 6, 2015

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=15076 Your paranoid android. === w2000pro (32 bit shlexec) === shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 shlexec.c:2447: Test failed: ShellExecuteEx(mask="0x500", file="C:\Documents and Settings\winetest\Local Settings\Temp\wt1.tmp\test file.sde") failed: rc=33 err=1400 === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2115: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtD94A.tmp\wtD96A.tmp" Exec") succeeded: rc=42

2 1

Re: [2/10]hidclass.sys: add hidclass.sys
by Henri Verbeet July 6, 2015

July 6, 2015

I didn't really look at the rest of the series, but here are a few things that caught my eye. On 6 July 2015 at 17:46, Aric Stewart <aric(a)codeweavers.com> wrote: > +struct list minidriver_list = LIST_INIT(minidriver_list); You don't seem to access this outside of main.c anywhere in this series, and it seems somewhat unlikely that you'll ever have to. Shouldn't this just be static? > +static VOID WINAPI UnloadDriver(DRIVER_OBJECT *driver) "void" > + TRACE("Driver Unload\n"); > + LIST_FOR_EACH_ENTRY_SAFE(md, next, &minidriver_list, minidriver, entry) > + { > + if (md->minidriver.DriverObject == driver) > + { > + if (md->DriverUnload) > + md->DriverUnload(md->minidriver.DriverObject); > + list_remove(&md->entry); > + break; > + } > + } > +} Did you intend to use find_minidriver() here? > +minidriver* find_minidriver(DRIVER_OBJECT* driver) > +{ > + minidriver *md; > + LIST_FOR_EACH_ENTRY(md, &minidriver_list, minidriver, entry) > + { > + if (md->minidriver.DriverObject == driver) > + return md; > + } > + return NULL; > +} As the code currently is this isn't actually used until patch 10/10. You could potentially use it from UnloadDriver() as mentioned above, but it should still initially be static in that case. Your '*' placement is inconsistent. > +NTSTATUS WINAPI HidRegisterMinidriver(PHID_MINIDRIVER_REGISTRATION registration) "HID_MINIDRIVER_REGISTRATION *registration" > +BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpv) > +{ > + switch(fdwReason) > + { > + case DLL_PROCESS_ATTACH: > + DisableThreadLibraryCalls(hInstDLL); > + break; > + } > + return TRUE; > +} As long as you don't do anything special in here, you don't need an explicit DllMain(). (But if you did, "void *" instead of LPVOID, and parameter naming.) > +/* These are from hidport.h but are only used here anyway */ > +typedef struct _HID_MINIDRIVER_REGISTRATION { The brace placement is inconsistent with the rest of the code. > + ULONG Revision; > + PDRIVER_OBJECT DriverObject; > + PUNICODE_STRING RegistryPath; "UNICODE_STRING *RegistryPath;" > + ULONG DeviceExtensionSize; > + BOOLEAN DevicesArePolled; > + UCHAR Reserved[3]; > +} HID_MINIDRIVER_REGISTRATION, *PHID_MINIDRIVER_REGISTRATION; If this is really only used inside hidclass.sys, you shouldn't need the PHID_MINIDRIVER_REGISTRATION typedef. > +NTSTATUS WINAPI HidRegisterMinidriver(PHID_MINIDRIVER_REGISTRATION MinidriverRegistration); The whitespace is odd here. Also, "HID_MINIDRIVER_REGISTRATION *registration". > +typedef struct _minidriver > +{ > + struct list entry; > + > + HID_MINIDRIVER_REGISTRATION minidriver; > + > + PDRIVER_UNLOAD DriverUnload; > +} minidriver; I suppose it's somewhat up to personal style, but you don't need a typedef for this. Aside from saving you from typing "struct" a few times it only obfuscates the code. I suspect some of the imports and includes aren't actually used until later in the series, but I didn't explicitly check that.

1 0

Re: [PATCH 2/2] shell32/tests: Win 2k doesn't cope with spaces in the path.
by Marvin July 6, 2015

July 6, 2015

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=15077 Your paranoid android. === w8 (32 bit shlexec) === shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1545: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1577: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:139: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:139: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2115: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wtDF64.tmp\wtDFB4.tmp" Exec") succeeded: rc=42

1 0

Wine Gecko 2.40-beta1
by Jacek Caban July 6, 2015

July 6, 2015

Hi all, It's time for another Wine Gecko update. I uploaded new builds to SourceForge. The new version is updated to use upcoming Firefox 40 engine and brings a few Wine-specific fixes. It also adds support for building with MSVC, contributed by Austin. If you want to test it, just build Wine with the attached patch. Wine will download Gecko for you. All feedback is appreciated. Thanks, Jacek

1 0

Re: [PATCH 2/3]: msvcp110: Add tr2_sys__Rename implementation and test.(try 3)
by Piotr Caban July 6, 2015

July 6, 2015

On 07/05/15 20:49, YongHao Hu wrote: > + if(!strcmp(old_path, new_path) || MoveFileExA(old_path, new_path, MOVEFILE_COPY_ALLOWED)) The comparison of paths doesn't look right. Why have you added it? Cheers, Piotr

2 1

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte July 6, 2015

July 6, 2015

(Apologies if double posting; I wasn't sub'd the first time and it wasn't in the archives.) I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:Other > devices then mouse&keyboard produce undocumented blobs of bytes;to > interpret them, functions from the hid.dll are used. Currently > theyare unimplemented stubs in WINE as well as not the problem I am > solving.There is a recent article about this subject - Using the Raw > Input APIto Process Joystick Input > -http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Nathan Schulte (me; original post) wrote: > Also, could one create an adaptation from some joystick input libraries > (evdev/x11,rawhid) and make it conform to the API in the CodeProject > example, making modifications similar to Henri Verbeet's for mouse and > keyboard and have built-in support for this? > > (Henri Verbeet's rawinput contributions: > http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) > > I see that Wine already has support for joysticks in some other > fashion (the gamepad I'm working with shows up in the `wine control` > Game Controller testing interface), and I bet it's a good idea to > leverage that adaptation (those adaptations...) than to start adding > my own. > > Any direction here would be appreciated. I think I understand the > separation between the wineserver (mainly server/queue.c) and the > dlls (dlls/user32/*), but I see that there are other "dlls" that > don't use (or don't appear to use, given my probably incorrect > understanding) wineserver for their adaptation, and instead talk > directly with the Linux libs to do their work (I'm assuming). It looks like what I was was seeing was "Wine drivers," (winejoystick.drv, for winmm's joystick bits, and DirectInput's joystick bits). Should I follow that route, or should I plumb this through wineserver, like the rawinput keyboard and mouse? Why are those plumbed through wineserver? Are they shared resources, and if so, why doesn't that matter for winmm and DirectInput? I'm thinking this should be fairly easy to get working, by enumerating the rawhid devices and just piping the data through. I'm not sure how well the native hid.dll will work though; can anyone comment? Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

3 3

crossover programs missing from source code
by Theodore Dubois July 5, 2015

July 5, 2015

The following programs in Crossover are absent from the source code download: assocscan autorun ctfmon cxcplinfo cxdummy cxinstallfonts cxmanip cxmklnk cxnative cxwget ddhelp extract findfast icwconn1 imjpmig maildoff mdm mosearch netscape ntoskrnl pstores qttask reboot sendwndcmd winewrapper Can I get an explanation for each of these? ~Theodore

4 3

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

Re: [4/7] ntdll/tests: Add basic tests for threadpool wait objects.
by Marvin July 4, 2015

July 4, 2015

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=15039 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:734: Test failed: WaitForSingleObject returned 258

2 1

Re: ole32: Accept STG_E_UNIMPLEMENTEDFUNCTION when ILockBytes implementation doesn't support locking.
by Nikolay Sivov July 4, 2015

July 4, 2015

On 03.07.2015 10:27, Dmitry Timoshkov wrote: > Some custom implementations return it instead of STG_E_INVALIDFUNCTION. > --- > dlls/ole32/storage32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ole32/storage32.c b/dlls/ole32/storage32.c > index 220e17e..aa53758 100644 > --- a/dlls/ole32/storage32.c > +++ b/dlls/ole32/storage32.c > @@ -5015,7 +5015,7 @@ static HRESULT StorageImpl_GrabLocks(StorageImpl *This, DWORD openFlags) > hr = StorageImpl_LockRegionSync(This, offset, cb, LOCK_ONLYONCE); > > /* If the ILockBytes doesn't support locking that's ok. */ > - if (hr == STG_E_INVALIDFUNCTION) return S_OK; > + if (hr == STG_E_INVALIDFUNCTION || hr == STG_E_UNIMPLEMENTEDFUNCTION) return S_OK; > else if (FAILED(hr)) return hr; > > hr = S_OK; > It looks like StorageImpl_LockRegionSync should be fixed instead to filter some error codes. Could you add a test with external ILockBytes implementation that does that?

3 7

Re: [PATCH 5/6]: msvcp110: Add tr2_sys__Lstat implementation and test.(resend)
by Piotr Caban July 4, 2015

July 4, 2015

On 07/03/15 06:00, YongHaoHu wrote: > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PBDAAH(a)Z */ > +/* ?_Lstat(a)sys@tr2(a)std@@YA?AW4file_type(a)123@PEBDAEAH(a)Z */ > +file_type tr2_sys__Lstat(char const* path, int *err_code) > +{ > + DWORD attr; > + TRACE("(%s %p)\n", debugstr_a(path), err_code); > + if(!path) { > + *err_code = ERROR_INVALID_PARAMETER; > + return status_unknown; > + } > + > + attr = GetFileAttributesA(path); > + if(attr == INVALID_FILE_ATTRIBUTES) > + return stat_set_error(err_code); > + if(attr & FILE_ATTRIBUTE_REPARSE_POINT) > + FIXME("reparse point is not supported yet\n"); > + > + *err_code = ERROR_SUCCESS; > + return (attr & FILE_ATTRIBUTE_DIRECTORY)?directory_file:regular_file; > +} What's the reason for not calling tr2_sys__Stat function here? Thanks, Piotr

2 3

Adding RID_TYPEHID RawInput support to user32
by Nathan Schulte July 3, 2015

July 3, 2015

I'm working to extend Wine's RawInput implementation to support gamepads/controllers (and possibly joysticks, or any non-keyboard/mouse HID device). I found this on the wine-patches list: Vincas Miliūnas wrote: > A comment about going beyond mouse/keyboard for raw input:> Other devices then mouse&keyboard produce undocumented blobs of bytes;> to interpret them, functions from the hid.dll are used. Currently they> are unimplemented stubs in WINE as well as not the problem I am solving.> There is a recent article about this subject - Using the Raw Input API> to Process Joystick Input -> http://www.codeproject.com/KB/game/RawInputJoystick.aspx Does this imply then, that if one was to add support for "raw" rawinput (RIM_TYPEHID device type) it could be used in conjunction with a native hid.dll and software that required RIM_TYPEHID input (for e.g. game controllers in games) would start working? Also, could one create an adaptation from some joystick input libraries (evdev/x11) and make it conform to the API in the CodeProject example, making modifications similar to Henri Verbeet's and have built-in support for this? (Henri Verbeet's rawinput contributions: http://source.winehq.org/git/wine.git/?a=search&st=commit&s=rawinput) I see that Wine already has support for joysticks in some other fashion (the gamepad I'm working with shows up in the `wine control` Game Controller testing interface), and I bet it's a good idea to leverage that adaptation (those adaptations...) than to start adding my own. Any direction here would be appreciated. I think I understand the separation between the wineserver (mainly server/queue.c) and the dlls (dlls/user32/*), but I see that there are other "dlls" that don't use (or don't appear to use, given my probably incorrect understanding) wineserver for their adaptation, and instead talk directly with the Linux libs to do their work (I'm assuming). Any help is welcome, as it means my patches are more likely to make it upstream and benefit others. I'm wondering if there's an architecture diagram/doc somewhere to help me understand how the system works. Thanks, -- Nate

1 0

Re: [PATCH 1/2] d3drm: Add stubs for IDirect3DRMDevice methods.
by Stefan Dösinger July 3, 2015

July 3, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-07-01 um 01:03 schrieb Aaryaman Vasishta: > +static ULONG WINAPI d3drm_device1_AddRef(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + ULONG refcount = InterlockedIncrement(&device->ref); > + > + TRACE("%p increasing refcount to %u.\n", iface, refcount); > + > + return refcount; > +} > + > +static ULONG WINAPI d3drm_device1_Release(IDirect3DRMDevice *iface) > +{ > + struct d3drm_device *device = impl_from_IDirect3DRMDevice(iface); > + > + return IDirect3DRMDevice2_Release(&device->IDirect3DRMDevice2_iface); > +} Why are you forwarding Release to d3drmdevice2 but not Addref? I think we should look again at moving the IUnknown methods to Device3, so we don't thunk to the middle child and stay consistent with the other methods. Please send an extra patch before this one that migrates the code to device3. I remember we already looked at this. If this failed in some spectacular way please remind me :-) . Is there a logic behind which method forwards to device3 and which just returns E_NOTIMPL? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVk+jzAAoJEN0/YqbEcdMwL/MP/jmYjvhWcVOosMP2FyKVaezA c4SqCONBE+xPvhmC97IfPXZ8wJQUjH0tt5CjZN2JZTY0yw50bEM4JHDfC1pPjF3O IX4qKllp0UeAeNCNKu64a8rxYT2kLRwLp7zs+GO7YygwimKy9DAMxUCW5+IP4DiB bsO1wTcSWlCHQ8c4ikUou6aIY/npJ+UqVS8DNGl5m1cLw6oUdzZMvcurSooH2LUv 1oq4XC1DQe/wx3Ob826xY8w/2v6CM0JDAgAT1dGqxIWDS5DNzsKj9P8oKEso/C8c thpZdsIvgQLEkfmKgN6wRh9h03aAMVHbXoSmGVihaapSspF7299DYrDyoiQvYxEq k+SgAMqHAtAzfXkQto9n0f8FjiLEJzbFu9WMoKLJmjdk7hpH8CXPsoioA/o8xNDA 8dB9LxITlJuK5oEUczGhdrnN144Ml8AkZbs+DBcvTdHvaOaY7urL2sZ6/QuvGtAY IGGeUnPW2VBMGpg1YlSn9OmziBibrjKOVtXHVmbwYQhZhXOcfzgMT+QBBV2eQ/pQ 0tmDnUk93+ungNnc4slfLZo+uZ8/8kvPRMv8fYPcQjkcXOIRCobup4bqx3vrQVWT zOx05HKBDQihZAxZuHynFaNqA5E1QbhbPac0BsOSLk8r4zSKx58BgNLBYWz51oe6 NN959TJY84womG8/lfFc =jkwG -----END PGP SIGNATURE-----

2 1

Re: [2/2] shell32/tests: Destroy shell view windows.
by Nikolay Sivov July 3, 2015

July 3, 2015

On 02.07.2015 13:36, Thomas Faber wrote: > When calling IShellView::CreateViewWindow, the window itself takes > references to the shell view and related objects (e.g. for a drop > target). This means just calling IShellView::Release is not enough to > properly clean up, the window needs to be destroyed as well. > Could you please also add a test that shows window is still being alive after IShellView was released? It could be a separate patch.

2 1

Re: [PATCH 4/6]: msvcp110: Add tr2_sys__Stat implementation and test.(try 2)
by Piotr Caban July 3, 2015

July 3, 2015

On 07/03/15 05:59, YongHaoHu wrote: > +static file_type stat_set_error(int *err_code) > +{ > + file_type ret; > + > + switch(GetLastError()) { > + case ERROR_FILE_NOT_FOUND: > + case ERROR_BAD_NETPATH: > + case ERROR_INVALID_NAME: > + case ERROR_BAD_PATHNAME: > + case ERROR_PATH_NOT_FOUND: > + ret = file_not_found; > + *err_code = ERROR_SUCCESS; > + break; > + case ERROR_SUCCESS: > + ret = regular_file; > + *err_code = ERROR_SUCCESS; > + break; Why are you handling ERROR_SUCCESS here? stat_set_error function is only called in case of error. Are you planning to reuse this function somewhere else? If not it might be part of tr2_sys__Stat function. Thanks, Piotr

1 0

Re: [PATCH 2/6]: msvcp110: Add tr2_sys__Rename implementation and test. (try 2)
by Piotr Caban July 3, 2015

July 3, 2015

On 07/03/15 05:56, YongHaoHu wrote: > + if(MoveFileExA(old_path, new_path, MOVEFILE_REPLACE_EXISTING|MOVEFILE_COPY_ALLOWED)) According to my testing MOVEFILE_REPLACE_EXISTING flag should not be used here. Thanks, Piotr

1 0

Re: [PATCH 1/6]: msvcp110: Add tr2_sys__Copy_file implementation and test.(try 2)
by YongHaoHu July 3, 2015

July 3, 2015

Hi, all. Found a mistake of tr2_sys__Copy_file, please ignore this patch. Thank you. On 15/7/3 上午11:55, YongHaoHu wrote: > try2 : > Add is_todo in test. > Delete useless SetLastError. > > --- > dlls/msvcp110/msvcp110.spec | 4 +-- > dlls/msvcp120/msvcp120.spec | 4 +-- > dlls/msvcp120/tests/msvcp120.c | 59 > +++++++++++++++++++++++++++++++++++++ > dlls/msvcp120_app/msvcp120_app.spec | 4 +-- > dlls/msvcp90/ios.c | 10 +++++++ > 5 files changed, 75 insertions(+), 6 deletions(-) > >

1 0

Re: [6/12] ntdll/tests: Add tests for threadpool timer merging.
by Sebastian Lackner July 2, 2015

July 2, 2015

On 03.07.2015 01:59, Sebastian Lackner wrote: > --- > dlls/ntdll/tests/threadpool.c | 117 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 117 insertions(+) > The test failure on Windows 7 seems to be random, it worked fine on a second run (and also on several test runs before): https://newtestbot.winehq.org/JobDetails.pl?Key=14968 If it occurs too often in practice we can increase the timeouts, but for now I think it should be fine. BTW: Forgot to mention, the Sleeps() in this patch are necessary because there is no way to do any other kind of synchronization with the Windows internal timer queue thread.

1 0

Re: [6/12] ntdll/tests: Add tests for threadpool timer merging.
by Marvin July 2, 2015

July 2, 2015

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=14965 Your paranoid android. === w7u (32 bit threadpool) === threadpool.c:856: Test failed: WaitForSingleObject returned 258 threadpool.c:897: Test failed: expected that ticks are nonzero threadpool.c:899: Test failed: expected that timers are merged

1 0

Re: [PATCH 2/4] wined3d: Implement vertex blending in glsl_vertex_pipe.
by Stefan Dösinger July 2, 2015

July 2, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I like this patchset. I can't find anything wrong in it, but Matteo knows the fixed function pipeline replacement better than I do, so I'll wait for his comments. I tested it with various DirectX SDK samples (bend from dx7, SkinnedMesh and VertexBlend from dx8). It works very well, but I noticed a lighting oddity in SkinnedMesh. The lighting differs slightly between your code ("D3D non-indexed" option) and the test program's vertex shader or d3dx9's software vertex blending ("D3D indexed (VS)" / "Software Skinning"). This difference cannot be seen on Windows. I have attached screenshots. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVlPPNAAoJEN0/YqbEcdMwUcIP/jwJsie6/93Ui3RQTqjT8oOP q0ips3E83dHpi0ceL8xXujr0pyO1x7cVuUX+hZ7Tf08bZu86FpieKZkTYZxRKbKj V5+x/bVlWGM+ogB06E7tHx2oM8tBFlh10wwh9M/QnitjtzCM+E3WKfE01W5NsRRL csUMxE1mBHvnp08Me2CZyzgtVWwQuTWH6IMUtmqQPfOmmOgzIoofjjRowjhZovFi D9cufKD/D+CBsuv/Py5AMYWfjv7gTZqB09sotaIzYWuyI/e6GRRFT2wzX1yOIl+I fhOr3AsHeFLWOAYd41DjMuqmqvQ5e/UigYxkDtssOCHVig7VtaQ0RKTEv6mMfDF4 6Ljgyi7RdGrgle41cDo6DBXTr0WZw6Y2eTLs0G+WCNkJ8/OMR9hLAt/YBg1mPEPo QUNTsqwNQ1Poxuxmo5fWqD0MhLAao7Wgm6dZTiECNPNNBsC91XRYR9jXF29xaB3h 3ekVCTdtI1+wUQolGw1/HZ7whaHkWGrxOY4qqiZsgYRYz1yl52Bt4sJDJYUHknbd GZ4JRkVQXD86D5txRLf500e03QCmDTXxjqEKSsNBNCtcpER1mp+3Hs/SImp/adRr 3tNuEMJduA/5jm27Nt+K13DwsazQXCJMDv5dTYlggBI9c3dhFDmjXNNGSvrvkBkf xW9FbSiHRRDoLR3UMuoR =Ghq/ -----END PGP SIGNATURE-----

2 1

Re: [3/3] msvcirt: Implement ios constructors and assignment
by Marvin July 2, 2015

July 2, 2015

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

1 0

Re: [2/3] msvcirt/tests: Add initial tests for ios
by Marvin July 2, 2015

July 2, 2015

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

1 0