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

Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 5 resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11882 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

June 21, 2011

Need help at collecting ActionMapping data

by Lucas Zawacki

Hello everyone. As you may know I'm working on the dinput8 action mapping support and at the moment I've pretty much finished the mouse and keyboard and just need to get my patches in. For the next part, however, I'm going to need to analyze lot's of data generated by different joysticks to figure out how the mapping works. Some things are already clear for me, but I have only some simple USB joysticks here and thus would like your help to collect more useful data. If any of you has any sort of joystick (simple gamepads, driving wheels and whatnot) and would like to help, I've set up a little app that uses the DI8 action mapping API to construct a mapping for every connected joystick and outputs it to the terminal. You just need to run it, redirect the output to a file and email it back to me. Telling me which version of windows you're running would be nice. If you want to help but can't use windows, wine with native dinput8.dll is fine too. The program can be found here: https://github.com/downloads/lfzawacki/dinput-samples/devices_test.exe The code is here: https://github.com/lfzawacki/dinput-samples/blob/master/devices_test.cpp Thanks in advance Cheers

June 21, 2011

Re: [2/3] wined3d: Fix context_apply_draw_buffers() with backbuffer ORM.

by Henri Verbeet

On 21 June 2011 23:49, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Here I modified surface_get_gl_buffer() to fix backbuffer ORM, an > alternative approach would be to modify > context_apply_[blit|clear|draw]_state() in a similar fashion instead. > Yeah, I think I'd prefer the alternative. We handle onscreen and offscreen surfaces separately for the FBO cases as well, and conceptually I'd prefer ORM checks to be in the context code if anywhere.

June 21, 2011

bug policy for "app X needs msvcp90.dll" type bugs

by Dan Kegel

(From the "keeping AF happy" and "metabugs are evil" departments.) Anyone watching wine-bugs already knows this, but just in case: As AF suggested in http://bugs.winehq.org/show_bug.cgi?id=24745#c11 bugs about apps needing msvcr90 or the like should identify the particular function in the bug subject line, if possible. There are still some bugs that simply say "app X needs native msvcr90". When the particular function that bothered them is fixed, and the app is verified to get further, that bug's subject line should be updated to identify the function that was fixed, and the bug should be marked as fixed. If the game still doesn't run because of some other function, a new bug should be filed.

June 21, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Tuesday 21 June 2011 12:32:28 Michael Mc Donnell wrote: > Note that two of the helper functions and a struct in the test were > also included in my UpdateSemantics patch. I'll remove them once my > UpdateSemantics patch is in the official tree. Your patches aren't applied yet and http://source.winehq.org/patches/ lists them as "New". I recommend to ask Alexandre why he didn't push them. I guess he is waiting for confirmation from a d3dx9 developer, but I think Dylan already gave his OK, and so did I, but I am strictly speaking not involved in d3dx9.

June 21, 2011

Re: [PATCH 2/2] jscript: Correctly throw an exception if instanceof expression is not used on function

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11874 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

June 21, 2011

Re: [PATCH 1/5] shell32: Add IKnownFolderManager::RegisterFolder implementation

by Alexandre Julliard

Mariusz Pluciński <vshader(a)gmail.com> writes: > Would you explain me, what is wrong with this patches series? I've > submitted it last week and for some reason it's status is > untouched. (the "failed" status seems to be temporal testbot's problem > rather than my patch's, so this is not the reason). I have no idea how > to fix them. They should really run through testbot. Please resend them. -- Alexandre Julliard julliard(a)winehq.org

June 21, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Dylan Smith

On Tue, Jun 21, 2011 at 6:32 AM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > Here is my test and implementation of ConvertAdjacencyToPointReps. > + hr = iface->lpVtbl->LockIndexBuffer(iface, D3DLOCK_READONLY, (void**)&indices); > + if (FAILED(hr)) goto cleanup; > + memcpy(new_indices, indices, This->numvertices * sizeof(*indices)); I think you want the number of faces * 3 rather than the number of vertices. And the size of an index is not constant, it is 32-bit if This->options has the D3DXMESH_32BIT bit set and 16-bit if the bit isn't set. > +static void test_convert_adjacency_to_point_reps(void) > +{ ... > + /* All mesh data */ > + struct vertex_pnc *vertices[] = {vertices0, vertices1, vertices2, vertices3, vertices4, vertices5, vertices6}; > + ID3DXMesh *meshes[ARRAY_SIZE(vertices)]; > + DWORD *indices[] = {indices0, indices1, indices2, indices3, indices4, indices5, indices6}; > + DWORD num_vertices[] = {num_vertices0, num_vertices1, num_vertices2, num_vertices3, num_vertices4, num_vertices5, num_vertices6}; > + DWORD num_faces[] = {num_faces0, num_faces1, num_faces2, num_faces3, num_faces4, num_faces5, num_faces6}; > + DWORD *adjacencies[] = {adjacency0, adjacency1, adjacency2, adjacency3, adjacency4, adjacency5, adjacency6}; > + DWORD *point_reps[] = {point_rep0, point_rep1, point_rep2, point_rep3, point_rep4, point_rep5, point_rep6}; > + DWORD *exp_point_reps[] = {exp_point_rep0, exp_point_rep1, exp_point_rep2, exp_point_rep3, exp_point_rep4, exp_point_rep5, exp_point_rep6}; I think it would make sense to put all these arrays of the same length into a structure (e.g. struct test_case) array. This would make it clear what needs to be updated to add another test case, and less error prone than making sure each relevant individual array is updated. Also, several of these and similar array seem like they can be made constant. > +static void test_convert_adjacency_to_point_reps(void) > +{ ... > + for (i = 0; i < ARRAY_SIZE(meshes); i++) > + { ... > + hr = meshes[i]->lpVtbl->ConvertAdjacencyToPointReps(meshes[i], adjacencies[i], point_reps[i]); > + todo_wine ok(hr == D3D_OK, "ConvertAdjacencyToPointReps failed. " > + "Got %x expected D3D_OK\n", hr); The value i should probably be printed in this error message. Otherwise, if you see a failure on test.winehq.org that you can't reproduce, it will be hard to figure out what might have caused the failure. That's it for now.

June 21, 2011

Re: [PATCH 1/5] shell32: Add IKnownFolderManager::RegisterFolder implementation

by Mariusz Pluciński

Hello Would you explain me, what is wrong with this patches series? I've submitted it last week and for some reason it's status is untouched. (the "failed" status seems to be temporal testbot's problem rather than my patch's, so this is not the reason). I have no idea how to fix them. Best regards Mariusz Pluciński W dniu 15.06.2011 18:05, Mariusz Pluciński pisze: > To not break currently working applications/tests, I decided to > implement known folders using following schema: > 1. implement infrastructure of known folders without breaking > currently working CSIDL-based way. New code is used only for folders > registered using RegisterFolder(). For all others, the older code > using CSIDL_Data array is used. > 2. move all folders from CSIDL_Data array to registry and remove old > way of accessing them. > --- > dlls/shell32/shellpath.c | 70 > ++++++++++++++++++++++++++++++++++++++- > dlls/shell32/tests/shellpath.c | 1 - > 2 files changed, 68 insertions(+), 3 deletions(-) > >

June 21, 2011

Re: Regression today?

by Maarten Lankhorst

Hey Susan, On 06/21/2011 01:03 PM, Susan Cragin wrote: > >Susan Cragin wrote: > >> I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. > >> wine-1.3.22-255-g4c0c0d3 > >> Should I do a regression test and file a bug, or is it obvious from this? > >> Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 kernel? > >The 3.0 kernel works for me now (3.0-rc4) as good as any of the previous > >stable releases. Before -rc4 I get a kernel oops after the radeon GPU > >lockup + soft reset I get with SC2. Now I'm left with the GPU lockup but > >previous kernels show the same problem. > > Hmmm... > I have the 3.0-1.2. I haven't really tested naturally speaking lately, but in git reflog you can always find back your previous HEAD and test with it once to see if wine has regressed. I'm running rc4 with some usb patches to fix suspend here. :-) I also use nouveau.git from time to time for testing, but it's still not entirely stable for me. ~Maarten

June 21, 2011

Re: Regression today?

by Susan Cragin

June 21, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

Here is my test and implementation of ConvertAdjacencyToPointReps. Note that two of the helper functions and a struct in the test were also included in my UpdateSemantics patch. I'll remove them once my UpdateSemantics patch is in the official tree. Any comments? Thanks, Michael Mc Donnell

June 21, 2011

Re: Regression today?

by Michael Stefaniuc

Susan Cragin wrote: > I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. > wine-1.3.22-255-g4c0c0d3 > Should I do a regression test and file a bug, or is it obvious from this? > Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 kernel? The 3.0 kernel works for me now (3.0-rc4) as good as any of the previous stable releases. Before -rc4 I get a kernel oops after the radeon GPU lockup + soft reset I get with SC2. Now I'm left with the GPU lockup but previous kernels show the same problem. bye michael

June 21, 2011

Re: [PATCH 1/4] dlls/ntdll: Add handle count to NtQuerySystemInformation

by Vitaliy Margolen

On 06/20/2011 09:36 PM, Austin Lund wrote: > On 20 June 2011 23:52, Vitaliy Margolen<wine-devel(a)kievinfo.com> wrote: > >>> + SERVER_START_REQ( create_snapshot ) >> >> You not checking if this call succeeded or not. > > I've tried to include all the checks in the new patch. > >> >>> + while (sizeof(ULONG) + >>> sizeof(SYSTEM_HANDLE_ENTRY)*shi->Count>= len) >> >> You don't need a loop to calculate new size. > > I've done this a different way in the new patch which avoids the reallocs. > >> You leaking old shi here. Also why do you need to zero allocated memory if >> you assigning all of it valid values? > > Not all of the values are assigned. Only the handle pid is accessible > with the current wineserver protocol. The remainder of the fields are > best set to zero as this is a sane value for these fields to trigger > exceptions and figure out how/when these values are being accessed > (e.g. null pointers or null handles). Later patches, which I have > already sent, try to fill in more of these fields. Makes sense. The patch looks good to me. Vitaliy.

June 21, 2011

Re: [PATCH 3/6] dinput: SetActionMap setting the device buffer.

by Vitaliy Margolen

On 06/20/2011 04:06 PM, Lucas Fialho Zawacki wrote: > @@ -1391,9 +1391,24 @@ HRESULT WINAPI IDirectInputDevice8AImpl_SetActionMap(LPDIRECTINPUTDEVICE8A iface > LPCSTR lpszUserName, > DWORD dwFlags) > { ... > + hr = IDirectInputDevice8_SetActionMap(&This->IDirectInputDevice8W_iface, > +&diafW, NULL, dwFlags); You need to call IDirectInputDevice8WImpl_SetActionMap directly here. Also please don't wrap lines at 80 characters, you can put all that into one line. And please be consistent with spacing around parentheses - either put spaces on both sides, or don't put at all. > + memset(&dp,0,sizeof(dp)); Please don't needlessly zero structures. You setting most values of it anyway. And please don't forget spaces after comas. Otherwise looks really good! Vitaliy.

June 20, 2011

Re: Disablin xinput2 for now?

by Vitaliy Margolen

On 06/20/2011 02:31 PM, Austin English wrote: > On Mon, Jun 20, 2011 at 09:36, Alexandre Julliard<julliard(a)winehq.org> wrote: >> Vitaliy Margolen<wine-devel(a)kievinfo.com> writes: >> >>> On 06/20/2011 02:55 AM, Marcus Meissner wrote: >>>> As this might be a X.org issue, should we packagers turn off >>>> xinput2 support for the time being? >>> >>> If that will fix all dinput regressions - absolutely. Or add a >>> registry option to disable xinput2. >> >> It will of course fix some regressions, and introduce new ones for >> things that have been fixed by the changes. Don't tell me that dinput >> was working perfectly before. And there is a registry option (GrabPointer). > > I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) > (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26…) > Using Duke Nukem Forever, which has the mouse jumping bug > (http://bugs.winehq.org/show_bug.cgi?id=27156) > > plain wine: I can move normally, with occasional mouse jumps. > wine + GrabPointer=N: mouse spins around uncontrollably, a la bug > http://bugs.winehq.org/show_bug.cgi?id=22282 > wine configured with --without-xinput2: mouse movement isn't fluid at > all. Instead, the only way the cursor will move is jumps in a random > direction (like bug 27156, except there is no normal behavior in > between the jumps). > Can you check how well it works with wine-1.3.19 - before all xinput2 related changes went in? Vitaliy.

June 20, 2011

Re: Disablin xinput2 for now?

by Vitaliy Margolen

On 06/20/2011 08:36 AM, Alexandre Julliard wrote: > Vitaliy Margolen<wine-devel(a)kievinfo.com> writes: > >> On 06/20/2011 02:55 AM, Marcus Meissner wrote: >>> As this might be a X.org issue, should we packagers turn off >>> xinput2 support for the time being? >> >> If that will fix all dinput regressions - absolutely. Or add a >> registry option to disable xinput2. > > It will of course fix some regressions, and introduce new ones for > things that have been fixed by the changes. Don't tell me that dinput > was working perfectly before. And there is a registry option (GrabPointer). > Dinput never perfectly worked before and doesn't work perfectly now. Even native has serious issues in Wine. I've lost track of all the changes you did to mouse/keyboard events, ll hooks, pointer position changes, etc. But it seems to me something broke that was working before. At least did not affect programs as much as it does now. I've seen number of programs/games that were highly sensitive to timing and order of various events. Unfortunately it was impossible to exactly replicate and/or make a test for it. And with dynamic nature of the problem it's a royal PITA to debug. In either case, it seems that what used to more-less work before doesn't work at all. Or has major problems (non-xinput2 code-path). And the new xinput2 code-path while resolving large number of issues, introduced number of other problems. So just disabling xinput2 support in any a binary build won't really help much. Vitaliy.

June 20, 2011

Re: [PATCH 1/4] dlls/ntdll: Add handle count to NtQuerySystemInformation

by Austin Lund

On 20 June 2011 23:52, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> + SERVER_START_REQ( create_snapshot ) > > You not checking if this call succeeded or not. I've tried to include all the checks in the new patch. > >> + while (sizeof(ULONG) + >> sizeof(SYSTEM_HANDLE_ENTRY)*shi->Count >= len) > > You don't need a loop to calculate new size. I've done this a different way in the new patch which avoids the reallocs. > You leaking old shi here. Also why do you need to zero allocated memory if > you assigning all of it valid values? Not all of the values are assigned. Only the handle pid is accessible with the current wineserver protocol. The remainder of the fields are best set to zero as this is a sane value for these fields to trigger exceptions and figure out how/when these values are being accessed (e.g. null pointers or null handles). Later patches, which I have already sent, try to fill in more of these fields.

June 20, 2011

Re: Regression today?

by Austin English

On Mon, Jun 20, 2011 at 21:00, Susan Cragin <susancragin(a)earthlink.net> wrote: > I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. > wine-1.3.22-255-g4c0c0d3 > Should I do a regression test and file a bug, or is it obvious from this? > Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 kernel? > > susan(a)ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$ wine natspeak > err:service:service_send_start_message service L"DragonSvc" failed to start > fixme:iphlpapi:NotifyAddrChange (Handle 0xc2e91c, overlapped 0xc2e900): stub > wine: configuration in '/home/susan/.wine' has been updated. > fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! > fixme:wbemprox:wbem_locator_ConnectServer 0x134288, L"ROOT\\CIMV2", (null), (null), (null), 0x00000000, (null), (nil), 0xfcea54) > fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS > fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 > fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0x10cea5c) > fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS > fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 > fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0xfcea5c) > fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS > fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 > fixme:wbemprox:wbem_locator_ConnectServer 0x136020, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0x10cea5c) > fixme:wbemprox:wbem_locator_ConnectServer 0x136020, L"ROOT\\WMI", (null), (null), (null), 0x00000000, (null), (nil), 0xfcea54) > fixme:reg:RegSetKeySecurity :(0x60,4,0xd9ba9c): stub > fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS > fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 > fixme:wbemprox:wbem_locator_ConnectServer 0x136020, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0x10cea5c) > susan(a)ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$ A regression test would be most helpful, though it's hard to say without knowing what the problem you're seeing is.. -- -Austin

June 20, 2011

Regression today?

by Susan Cragin

I think a regression was introduced today. I got the following trying to run NatSpeak 11.0 with today's git. wine-1.3.22-255-g4c0c0d3 Should I do a regression test and file a bug, or is it obvious from this? Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 kernel? susan(a)ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$ wine natspeak err:service:service_send_start_message service L"DragonSvc" failed to start fixme:iphlpapi:NotifyAddrChange (Handle 0xc2e91c, overlapped 0xc2e900): stub wine: configuration in '/home/susan/.wine' has been updated. fixme:ole:CoInitializeSecurity ((nil),-1,(nil),(nil),0,3,(nil),0,(nil)) - stub! fixme:wbemprox:wbem_locator_ConnectServer 0x134288, L"ROOT\\CIMV2", (null), (null), (null), 0x00000000, (null), (nil), 0xfcea54) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0x10cea5c) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x135fd0, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0xfcea5c) fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x136020, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0x10cea5c) fixme:wbemprox:wbem_locator_ConnectServer 0x136020, L"ROOT\\WMI", (null), (null), (null), 0x00000000, (null), (nil), 0xfcea54) fixme:reg:RegSetKeySecurity :(0x60,4,0xd9ba9c): stub fixme:mountmgr:harddisk_ioctl returning zero-filled buffer for IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:wbemprox:wbem_locator_ConnectServer 0x136020, L"ROOT\\CIMv2", (null), (null), (null), 0x00000000, (null), (nil), 0x10cea5c) susan(a)ubuntu:~/.wine/drive_c/Program Files/Nuance/NaturallySpeaking11/Program$

June 20, 2011

Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 5)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11852 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

June 20, 2011

Re: Disablin xinput2 for now?

by Austin English

On Mon, Jun 20, 2011 at 09:36, Alexandre Julliard <julliard(a)winehq.org> wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> On 06/20/2011 02:55 AM, Marcus Meissner wrote: >>> As this might be a X.org issue, should we packagers turn off >>> xinput2 support for the time being? >> >> If that will fix all dinput regressions - absolutely. Or add a >> registry option to disable xinput2. > > It will of course fix some regressions, and introduce new ones for > things that have been fixed by the changes. Don't tell me that dinput > was working perfectly before. And there is a registry option (GrabPointer). I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26…) Using Duke Nukem Forever, which has the mouse jumping bug (http://bugs.winehq.org/show_bug.cgi?id=27156) plain wine: I can move normally, with occasional mouse jumps. wine + GrabPointer=N: mouse spins around uncontrollably, a la bug http://bugs.winehq.org/show_bug.cgi?id=22282 wine configured with --without-xinput2: mouse movement isn't fluid at all. Instead, the only way the cursor will move is jumps in a random direction (like bug 27156, except there is no normal behavior in between the jumps). -- -Austin

June 20, 2011

Re: shdocvw: Add ITaskbarList2 Interface (try 2)

by Michael Stefaniuc

Hello André, On 06/20/2011 10:01 PM, André Hentschel wrote: > I should mention that i never added a interface before, neither one > that extends an existing one. I want to stub out ITaskbarList3, so i > thought i should first start with ITaskbarList2 and see what i'm doing > right or wrong. this is a waste of time. Go straight for ITaskbarList3 as that inherits from ITaskbarList2. You would would just duplicate most of the work as you have to change again all the functions to take a ITaskbarList3 instead of a ITaskbarList2. > This time i kept the implementation of QueryInterface > as much as possible. bye michael

June 20, 2011

Re: [PATCH 2/3] server: Added server-side raw input function implementations (try 4)

by Vincas Miliūnas

On 06/20/2011 05:24 PM, Vitaliy Margolen wrote: > On 06/20/2011 02:55 AM, Vincas Miliūnas wrote: >> (see the message in the first part of the patch) >> +struct raw_input >> +{ >> + struct list entry; >> + unsigned short usage_page; >> + unsigned short usage; >> + BOOL processed; >> + BOOL retrieved; >> + RAWINPUT raw; >> + >> + /* common fields */ >> + unsigned int type; >> + unsigned int message; >> + unsigned int flags; >> + unsigned int extra_info; >> + >> + /* mouse fields */ >> + unsigned int point_x; >> + unsigned int point_y; >> + unsigned int mouse_data; >> + unsigned int cursor_x; >> + unsigned int cursor_y; >> + >> + /* keyboard fields */ >> + unsigned int vk_code; >> + unsigned int scan_code; >> +}; > Mouse and keyboard fields should be a union to save space. > >> +#define NUM_RAW_DEVICES (sizeof( raw_devices ) / sizeof( struct raw_device )) > Please use "sizeof(array)/sizeof(array[0])" construct instead. > >> + UINT i, size_in_bytes; > In server please use standard C types ("unsigned int" in this case). > >> + /* Currently fake handles are provided, however they are only used for the GetRawInputDeviceInfo function, >> + thus it should not create any undesirable side effects */ >> + result[i].hDevice = (HANDLE)raw_devices[i].handle; > This doesn't sound right. What this handle can be used for? > >> + if (!(raw = malloc( sizeof( *raw ) ))) > In server please use mem_alloc() instead. > >> +/* Unregister a raw input device */ >> +DECL_HANDLER(unregister_raw_input_device) > I don't see handing of case where device is not found. Should you return > error instead? > >> + LIST_FOR_EACH( registration_entry, &current->process->raw_registered ) >> + { >> + struct raw_registration *registration = LIST_ENTRY( registration_entry, struct raw_registration, entry ); > You can use this instead: > LIST_FOR_EACH_ENTRY( registration, &current->process->raw_registered, > struct raw_registration, entry ) > > >> + /* Prevent unprocessed raw input entries from being queued indefinitely */ >> + while (current->process->raw_inputs_len >= MAX_RAW_INPUT_QUEUE_LENGTH) >> + { >> + struct raw_input *head = LIST_ENTRY( list_head( &current->process->raw_inputs ), struct raw_input, entry ); >> + list_remove( &head->entry ); >> + current->process->raw_inputs_len -= 1; >> + free( head ); >> + } > Looks like you need a circular buffer (an array of fixed size with head and > tail pointers) instead of a list here. > > Vitaliy. > I've updated the patch and replied - http://www.winehq.org/pipermail/wine-patches/2011-June/103346.html

June 20, 2011

Re: shdocvw: Add ITaskbarList2 Interface

by André Hentschel

Am 20.06.2011 17:50, schrieb Henri Verbeet: > 2011/6/18 André Hentschel <nerv(a)dawncrow.de>: >> -static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList *iface, REFIID riid, void **object) >> +static HRESULT STDMETHODCALLTYPE taskbar_list_QueryInterface(ITaskbarList2 *iface, REFIID riid, LPVOID *ppv) >> { >> - TRACE("iface %p, riid %s, object %p\n", iface, debugstr_guid(riid), object); >> + struct taskbar_list *This = impl_from_ITaskbarList2(iface); >> + >> + *ppv = NULL; >> + >> + if(IsEqualGUID(&IID_IUnknown, riid)) { >> + TRACE("(%p)->(IID_IUnknown %p)\n", This, ppv); >> + *ppv = &This->ITaskbarList2_iface; >> + }else if(IsEqualGUID(&IID_ITaskbarList, riid)) { >> + TRACE("(%p)->(IID_ITaskbarList %p)\n", This, ppv); >> + *ppv = &This->ITaskbarList2_iface; >> + }else if(IsEqualGUID(&IID_ITaskbarList2, riid)) { >> + TRACE("(%p)->(IID_ITaskbarList2 %p)\n", This, ppv); >> + *ppv = &This->ITaskbarList2_iface; >> + } >> >> - if (IsEqualGUID(riid, &IID_ITaskbarList) >> - || IsEqualGUID(riid, &IID_IUnknown)) >> - { >> - IUnknown_AddRef(iface); >> - *object = iface; >> + if(*ppv) { >> + IUnknown_AddRef((IUnknown*)*ppv); >> return S_OK; >> } >> >> - WARN("%s not implemented, returning E_NOINTERFACE\n", debugstr_guid(riid)); >> - >> - *object = NULL; >> + WARN("(%p)->(%s %p) interface not supported\n", This, debugstr_guid(riid), ppv); >> return E_NOINTERFACE; >> } >> > I'm not sure that's really an improvement. > > I thought i use the way the webbrowser queryinterface in the same dll is implemented. Of course i can change less here. -- Best Regards, André Hentschel

June 20, 2011