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

Re: dead link on directdraw wiki to directdrawrenderer

by James Eder

On Thu, Jun 16, 2011 at 11:16 PM, Jarek Czekalski <jarekczek(a)poczta.onet.pl> wrote: > There's a dead link on the page http://wiki.winehq.org/DirectDraw pointing > to http://wiki.winehq.org/DirectDrawRenderer as DirectDrawRenderer. Is there > any better place for such reports? > That's just the MoinMoin Wiki software at work. It automatically creates a Wiki link for CaptitalizedWords with no spaces between them. The original author probably did not intend for DirectDrawRenderer to actually point to a Wiki article. See http://wiki.winehq.org/WikiName for more on that. Anyway, if you're wondering, DirectDrawRenderer refers to a registry setting. See http://wiki.winehq.org/UsefulRegistryKeys -- Jim

June 17, 2011

Re: urlmon: Fix incorrect pointer arithmetic (too conversative) in map_url_to_zone. (RESEND^2)

by Gerald Pfeifer

A friendly soul pointed out to me that I had missed three(!) responses to my patch which went to wine-devel(a). Sorry about that, I'll see to set up some mail filters to prevent that from happening. For the record, somehow I got mislead re the semantics of sizeof, and that after some 25 years of programming C. :-( Sorry! Gerald On Wed, 15 Jun 2011, Gerald Pfeifer wrote: > Anything wrong with this patch? The original code surely looks wrong? > > The difference between two pointers (of the same type) is the number > of elements, not the number of bytes. Thus the code below was way > incorrect, luckily only too conversative. > > Gerald > > --- > dlls/urlmon/sec_mgr.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/urlmon/sec_mgr.c b/dlls/urlmon/sec_mgr.c > index 7b4bb35..75850ee 100644 > --- a/dlls/urlmon/sec_mgr.c > +++ b/dlls/urlmon/sec_mgr.c > @@ -529,7 +529,7 @@ static HRESULT map_url_to_zone(LPCWSTR url, DWORD *zone, LPWSTR *ret_url) > hres = CoInternetParseUrl(secur_url, PARSE_PATH_FROM_URL, 0, path, > sizeof(path)/sizeof(WCHAR), &size, 0); > > - if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)/sizeof(WCHAR)) { > + if(SUCCEEDED(hres) && (ptr = strchrW(path, '\\')) && ptr-path < sizeof(root)) { > UINT type; > > memcpy(root, path, (ptr-path)*sizeof(WCHAR)); >

June 17, 2011

dead link on directdraw wiki to directdrawrenderer

by Jarek Czekalski

There's a dead link on the page http://wiki.winehq.org/DirectDraw pointing to http://wiki.winehq.org/DirectDrawRenderer as DirectDrawRenderer. Is there any better place for such reports?

June 17, 2011

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

by Dylan Smith

On Thu, Jun 16, 2011 at 4:49 AM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > > Yeah it turned out to be a lot harder than I had expected to get all > the details correct. I have also added a check for non-zero stream > values that Dylan Smith wanted me to add. > Thanks. Looks good to me too now.

June 16, 2011

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

by Stefan Dösinger

On Thursday 16 June 2011 10:49:19 Michael Mc Donnell wrote: > I've added the test you outlined. It shows you're correct that > GetDeclaration only writes up to D3DDECL_END(). I've changed the > implementation so that it caches the number of elements and only > writes up to D3DDECL_END(). Looks good to me. > You're right it could potentially read undefined memory depending on > the compiler semantics. I think the safest thing is just to read up to > D3DDECL_END() in the passed in declaration, then it will never read > undefined memory (except if the programmer makes a mistake). Looks good, but please write a WARN message in every case where you return an error to the application. We believe that we handled the error condition correctly, so there's no need for a FIXME, but the broken app behavior may have been triggered by some other problem in Wine, so the message is more important than a simple TRACE.

June 16, 2011

Re: [2/2] imm32: Factor out the message checks from ImmIsUIMessageA/W and fix them

by André Hentschel

Am 16.06.2011 23:22, schrieb 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=11778 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply forgot to check if the testbot already did "Update Wine to latest git" -- Best Regards, André Hentschel

June 16, 2011

Re: [2/2] imm32: Factor out the message checks from ImmIsUIMessageA/W and fix them

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=11778 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 16, 2011

Re: app freezes during WM_KILLFOCUS

by Eric Frias

On 6/16/2011 10:49 AM, Ken Thomases wrote: > On Jun 16, 2011, at 9:09 AM, Eric Frias wrote: > >> I've been chasing a bug for a few days, and finally have a good idea of what is going on. When a program brings up a modal dialog box in response to a WM_KILLFOCUS message, the program will freeze. > Excellent analysis. Please file a bug report in bugzilla<http://bugs.winehq.org/> so that the issue can be properly tracked and not lost. I've just created a bug here: http://bugs.winehq.org/show_bug.cgi?id=27502 Eric

June 16, 2011

Re: app freezes during WM_KILLFOCUS

by Ken Thomases

On Jun 16, 2011, at 9:09 AM, Eric Frias wrote: > I've been chasing a bug for a few days, and finally have a good idea of what is going on. When a program brings up a modal dialog box in response to a WM_KILLFOCUS message, the program will freeze. Excellent analysis. Please file a bug report in bugzilla <http://bugs.winehq.org/> so that the issue can be properly tracked and not lost. Thanks, Ken

June 16, 2011

app freezes during WM_KILLFOCUS

by Eric Frias

I've been chasing a bug for a few days, and finally have a good idea of what is going on. When a program brings up a modal dialog box in response to a WM_KILLFOCUS message, the program will freeze. I've attached a simple test case, all boilerplate except for: case WM_KILLFOCUS: MessageBox(hWnd, _T("Killing Focus"), _T("Note"), MB_OK); in the main event loop. If you run the program and then give focus to another application, the messagebox will pop up and then the program will become unresponsive. What is happening is: - x11drv gets a FocusOut event and calls the event handler, which ends up SendMessage-ing a WM_KILLFOCUS to the program. - The programs's code creates a modal dialog like the MessageBox above, and enters the dialog's event loop, which winds up calling GetMessage which calls MsgWaitForMultipleObjectsEx to get more X11 events. - X11DRV_MsgWaitForMultipleObjectsEx executes this: if (data->current_event) mask = 0; /* don't process nested events */ where data->current_event is true since we're still handling the FocusOut event. Since we're not processing nested events, we'll never be able to process the usual events like keys or mouse events which could exit this nested event loop. This type of error occurs in a few places in our application, where a WM_KILLFOCUS message to an edit box triggers some input validation and displays an error on failure. This works correctly in the normal case, where the user tabs out or clicks on another control in the dialog box containing the edit control -- since everything stays in the same top-level window, there is no FocusOut event from X11 and the WM_KILLFOCUS is generated internally by wine in response to, say, a KeyEvent. I think these key or mouse events are just posted to the windows message queue, and the X11 event handler has already exited by the time the application gets around to processing the ensuing WM_KILLFOCUS. But in the case where focus is lost by clicking outside the dialog containing the edit control, the WM_KILLFOCUS is generated by the FocusOut handler which is still executing, and we lock up. I suspect this is related to bug 11595 "Notepad++ freezes if native application changes a file it has open (dogfood)". My guess is in that case, a FocusIn event triggers something like a WM_ACTIVATE, in which notepad++ notices a file is changed and displays a messagebox asking if you want to reload. Since wine is still processing the FocusIn event, the modal message loop's call to MsgWaitForMultipleObjectsEx will never process any useful events because it's a nested event. Our application's built-in text editor has this same problem. I don't understand the event handling code well enough to propose a solution. As a test, I allowed nested event processing and it solved the problem without introducing any obvious errors, but I'm sure that check was in there for a reason. It's probably better to keep the application code from being executed from inside the event handler, if that's possible. Eric

June 16, 2011

Re: [PATCH 1/6] server: Add server-side raw input functions definitions

by Vincas Miliūnas

On 06/16/2011 04:26 PM, Vitaliy Margolen wrote: > On 06/15/2011 10:37 PM, Vincas Miliūnas wrote: >> On 06/16/2011 01:00 AM, Vitaliy Margolen wrote: >>> I'm not sure I like your approach and that AJ would like it either. >>> >>> Raw input is an "override" of regular messages caused by mouse/keyboard >>> input. Wine server already receives these messages from x11drv (see >>> __wine_send_input& co). >>> >>> When applications requests raw input events you need to tell wine server if >>> it needs to send regular events, or ignore all events, and produce raw input >>> events instead. >>> >>> Vitaliy. >>> >> Yes, that's how the RIDEV_NOLEGACY device flag works. The application has an >> option to opt-in for it, but both means of providing input can take place in >> parallel. >> >> Well, the current patch is an non-invasive way to emulate raw input. It does >> not deal with the actual hardware devices, configuring the input subsystem, >> etc, like the windows version does. But the goal is to find the right answer :) >> > I think you misunderstood what I was trying to say. You do not need to > introduce another way of getting messages into wine server. It already > getting hardware messages via send_hardware_message server call. > Yes, I am aware of that and that was my first approach, when I started writing this. I already have the code to map hw_input_t to raw input structures. The problem was incorrect mouse cursor movement, therefore I copied dinput approach with using GetCursorPos. I've learned more, thus the next objective would be to move the input feed completely into the server. So, instead of going server->client->server->client, it would be just server->client. The goal was to publish something and get feedback. Thanks for the great advices! > As for the actual patches, you need to clean few things before they can go in: > 1. Each patch should compile and don't break Wine. > 2. No dead code should be added with each patch > 3. In tests, reset last error to known bogus value like 0xdeadbeef. Not 0. > 4. In C to split long text lines use this construct ("\n" instead of \): > printf("foo" > "bar"); > 5. Don't use wchar_t in Wine. It's not compatible with WCHAR. > > Vitaliy. >

June 16, 2011

Re: [PATCH 1/6] server: Add server-side raw input functions definitions

by Vitaliy Margolen

On 06/15/2011 10:37 PM, Vincas Miliūnas wrote: > On 06/16/2011 01:00 AM, Vitaliy Margolen wrote: >> I'm not sure I like your approach and that AJ would like it either. >> >> Raw input is an "override" of regular messages caused by mouse/keyboard >> input. Wine server already receives these messages from x11drv (see >> __wine_send_input& co). >> >> When applications requests raw input events you need to tell wine server if >> it needs to send regular events, or ignore all events, and produce raw input >> events instead. >> >> Vitaliy. >> > Yes, that's how the RIDEV_NOLEGACY device flag works. The application has an > option to opt-in for it, but both means of providing input can take place in > parallel. > > Well, the current patch is an non-invasive way to emulate raw input. It does > not deal with the actual hardware devices, configuring the input subsystem, > etc, like the windows version does. But the goal is to find the right answer :) > I think you misunderstood what I was trying to say. You do not need to introduce another way of getting messages into wine server. It already getting hardware messages via send_hardware_message server call. As for the actual patches, you need to clean few things before they can go in: 1. Each patch should compile and don't break Wine. 2. No dead code should be added with each patch 3. In tests, reset last error to known bogus value like 0xdeadbeef. Not 0. 4. In C to split long text lines use this construct ("\n" instead of \): printf("foo" "bar"); 5. Don't use wchar_t in Wine. It's not compatible with WCHAR. Vitaliy.

June 16, 2011

Re: [3/3] d3dx9/tests: Implemented tests for ID3DXLine_GetDevice.

by Matteo Bruni

2011/6/16 Charles Welton <charleswfb(a)gmail.com>: > > + IDirect3DDevice9_Release(return_device); > + ID3DXLine_Release(line); You could add a couple of ok() checks for the values returned by Release, to ensure nothing strange is happening. Btw, thanks for contributing. :)

June 16, 2011

Re: [1/3] d3dx9/line: Added device pointer to ID3DXLineImpl and initialize it.

by Matteo Bruni

2011/6/16 Charles Welton <charleswfb(a)gmail.com>: > > @@ -27,6 +27,8 @@ static const struct ID3DXLineVtbl ID3DXLine_Vtbl; > typedef struct ID3DXLineImpl { > ID3DXLine ID3DXLine_iface; > LONG ref; > + > + IDirect3DDevice9 * device; > } ID3DXLineImpl; You also have to Release() the device in ID3DXLineImpl_Release when ref reaches 0. Additional style nitpick, there should be no space between '*' and the field name.

June 16, 2011

Re: strmbase: Don't use list_count() to check that a list is not empty.

by Michael Stefaniuc

Please ignore this one. I was too excited about this easy task for coccinelle that I missed Joerg's second patch. bye michael On 06/16/2011 01:39 PM, Michael Stefaniuc wrote: > --- > Thanks to Joerg for the inspiration to this sort coccinelle script: > > @@ > expression E; > @@ > ( > - list_count(E) == 0 > + list_empty(E) > | > - list_count(E)> 0 > + !list_empty(E) > ) > > > > > dlls/strmbase/outputqueue.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/dlls/strmbase/outputqueue.c b/dlls/strmbase/outputqueue.c > index 4f4ecf8..c8c268f 100644 > --- a/dlls/strmbase/outputqueue.c > +++ b/dlls/strmbase/outputqueue.c > @@ -190,7 +190,7 @@ VOID WINAPI OutputQueue_SendAnyway(OutputQueue *pOutputQueue) > if (pOutputQueue->hThread) > { > EnterCriticalSection(&pOutputQueue->csQueue); > - if (list_count(pOutputQueue->SampleList)> 0) > + if (!list_empty(pOutputQueue->SampleList)) > { > pOutputQueue->bSendAnyway = TRUE; > SetEvent(pOutputQueue->hProcessQueue); > @@ -235,14 +235,14 @@ DWORD WINAPI OutputQueueImpl_ThreadProc(OutputQueue *pOutputQueue) > do > { > EnterCriticalSection(&pOutputQueue->csQueue); > - if (list_count(pOutputQueue->SampleList)> 0&& > + if (!list_empty(pOutputQueue->SampleList)&& > (!pOutputQueue->bBatchExact || > list_count(pOutputQueue->SampleList)>= pOutputQueue->lBatchSize || > pOutputQueue->bSendAnyway > ) > ) > { > - while (list_count(pOutputQueue->SampleList)> 0) > + while (!list_empty(pOutputQueue->SampleList)) > { > IMediaSample **ppSamples; > LONG nSamples; > @@ -278,7 +278,7 @@ DWORD WINAPI OutputQueueImpl_ThreadProc(OutputQueue *pOutputQueue) > HeapFree(GetProcessHeap(),0,ppSamples); > > /* Process Non-Samples */ > - if (list_count(pOutputQueue->SampleList)> 0) > + if (!list_empty(pOutputQueue->SampleList)) > { > LIST_FOR_EACH_SAFE(cursor, cursor2, pOutputQueue->SampleList) > { -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach Handelsregister: Amtsgericht Muenchen HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera

June 16, 2011

Re: [PATCH 2/2] wineboot: Split prefix updating into two parts.

by Alexandre Julliard

David Hedberg <dhedberg(a)codeweavers.com> writes: > On initial prefix creation, services.exe is started before the > environment is properly set up. This leads to calls to > ExpandEnvironmentStrings failing, in turn breaking at least one > installer. This splits the creation/update process into two parts, and > sets up the environment before starting services. That's ugly, we shouldn't have to worry about the order of service registrations and things like that. Most likely we need to setup a minimal environment before calling wineboot. -- Alexandre Julliard julliard(a)winehq.org

June 16, 2011

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

by Michael Mc Donnell

On Tue, Jun 14, 2011 at 1:43 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Tuesday 14 June 2011 12:57:35 Michael Mc Donnell wrote: >> I cache the vertex declaration (D3DVERTEXELEMENT9 array) and the size >> of the vertex declaration, so that they can be used by >> GetNumBytesPerVertex and GetDeclaration when an invalid declaration >> has been passed. > > In GetDeclaration: > >> + memcpy(declaration, This->cached_declaration, sizeof(This- >>cached_declaration)); > You should probably test if native really writes the full MAX_FVF_DECL_SIZE > declaration elements, or only up to the D3DDECL_END() marker in the real > declaration. A similar consideration applies to UpdateSemantics, but that is > harder to test. E.g.: > > + D3DVERTEXELEMENT9 declaration[MAX_FVF_DECL_SIZE]; > + D3DVERTEXELEMENT9 declaration0[] = > + { > ... > > memset(declaration, 0xaa, sizeof(declaration)); > memcpy(declaration, declaration0, sizeof(declaration0)); > UpdateSemantics(declaration) > memset(declaration, 0xbb, sizeof(declaration)); > GetDeclaration(declaration); > > Now look at the bytes in 'declaration' after the D3DDECL_END() marker up to > the end of the array. They could be 0xaa(UpdateSemantics reads everything, > GetDeclaration writes everything), 0xbb(UpdateSemantics is unknown, > GetDeclaration writes only the defined part), or something else(e.g. > UpdateSemantics and/or GetDeclaration clear set the extra bytes to 0). I've added the test you outlined. It shows you're correct that GetDeclaration only writes up to D3DDECL_END(). I've changed the implementation so that it caches the number of elements and only writes up to D3DDECL_END(). > In the way your implementation and tests are currently set up UpdateSemantics > will read undefined memory because your test declarations like declaration0 > don't have the full MAX_FVF_DECL_SIZE array size. Otoh I am not quite sure > about the semantics of passing an array on the stack like this. Maybe the > compiler allocates a new array with the full size and copies the content > around. You're right it could potentially read undefined memory depending on the compiler semantics. I think the safest thing is just to read up to D3DDECL_END() in the passed in declaration, then it will never read undefined memory (except if the programmer makes a mistake). I've changed the implementation to count the number of elements in the new declaration, cache the number, and then copy the contents of new declaration into the cached declaration. Counting the elements doesn't add any extra overhead as I also needed it to check for non-zero stream values. > Also I think this method has been pretty thoroughly tested and debated by now. > If we implement all the functions this way we'd probably be pretty bug-free > :-) Yeah it turned out to be a lot harder than I had expected to get all the details correct. I have also added a check for non-zero stream values that Dylan Smith wanted me to add. > Also, there's the obligatory style nitpick: >> + IDirect3DDevice9 *device; >> ... >> +static struct test_context* new_test_context(void) > For consistency this should probably be static struct test_context > *new_test_context(void). Check :-)

June 16, 2011

Re: [PATCH 1/6] server: Add server-side raw input functions definitions

by Vincas Miliūnas

On 06/16/2011 01:00 AM, Vitaliy Margolen wrote: > On 06/14/2011 02:45 AM, Vincas Miliūnas wrote: >> This is a partial raw input implementation for mouse and keyboard. >> >> I've read in the IRC chat, that products of tools/make_request should >> not > be included in a patch, so I left them out. >> My first attempts were by leeching input events from queue_mouse_message > and queue_keyboard_message functions, but I couldn't get mouse cursor > movement right. Instead, I copied the way dinput receives input - by > installing low level hooks and forwarding input to the server. This is just > to get "try 1" out of the door. Of course, it would be better if the input > feed would be server-side only. >> I hit a very weird bug, where in peek_message function, info.msg.lParam > was impossible to set with the proper lParam (it was correct in > reply->lparam) value, instead is was overwritten by some constant. That was > happening only for the messages sent by the patch using post_message. I > guess the tales of server-side dragons hold some truth... If anyone wants to > try to reproduce it, just recompile without the unused #include "user.h" in > raw_input.c and run user32 tests. >> This patch game-tested and works for Quake Live (in_mouse 2 for raw > input), World of Tanks and Risen. > > > I'm not sure I like your approach and that AJ would like it either. > > Raw input is an "override" of regular messages caused by mouse/keyboard > input. Wine server already receives these messages from x11drv (see > __wine_send_input & co). > > When applications requests raw input events you need to tell wine server if > it needs to send regular events, or ignore all events, and produce raw input > events instead. > > Vitaliy. > Yes, that's how the RIDEV_NOLEGACY device flag works. The application has an option to opt-in for it, but both means of providing input can take place in parallel. Well, the current patch is an non-invasive way to emulate raw input. It does not deal with the actual hardware devices, configuring the input subsystem, etc, like the windows version does. But the goal is to find the right answer :)

June 15, 2011

Re: [2/3] cmd/tests: Add support for todo_wine constructions (try 3)

by Frédéric Delanoy

On Thu, Jun 16, 2011 at 02:24, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Hello, > > I think Jacek was suggesting something among these lines, which does > look prettier imho (replace quoted text with following): > ... > + }else { > + if (!is_todo_wine) > + ok(!err, "unexpected char 0x%x position %d in line %d > (got '%.*s', wanted '%.*s')\n", > + *err, (int)(err-out_ptr), line, (int)(out_nl-out_ptr), > + out_ptr, (int)(exp_nl-exp_ptr), exp_ptr); > + else > + todo_wine > + ok(!err, "unexpected char 0x%x position %d in line %d > (got '%.*s', wanted '%.*s')\n", > + *err, (int)(err-out_ptr), line, > (int)(out_nl-out_ptr), out_ptr, > + (int)(exp_nl-exp_ptr-sizeof(todo_wine_cmd)), > exp_ptr+sizeof(todo_wine_cmd)); > + } > There is also another difference from your code: the code above also > counts the succeeded tests, whereas your code doesn't. Yes, except err is dereferenced in ok arguments so this doesn't work I discussed with jacek on irc: you could remove the ok(!err, ...) and use sthg like (err ? *err : 0) instead of the *err but you then get a problem for "tests succeeded in todo block" to report the correct char and position in the error message. Also, jacek didn't particularly care about the # of tests reported executed, as long as all tests are run and errors are reported correctly, so tbe ok(TRUE,...) was removed. Frédéric

June 15, 2011

Re: [2/3] cmd/tests: Add support for todo_wine constructions (try 3)

by Octavian Voicu

2011/6/15 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > + if(err == out_nl) { > + if (!is_todo_wine) > + ok(0, "unexpected end of line %d (got '%.*s', wanted '%.*s')\n", > + line, (int)(out_nl-out_ptr), out_ptr, (int)(exp_nl-exp_ptr), exp_ptr); > + else > + todo_wine > + ok(0, "unexpected end of line %d (got '%.*s', wanted '%.*s')\n", > + line, (int)(out_nl-out_ptr), out_ptr, > + (int)(exp_nl-exp_ptr-sizeof(todo_wine_cmd)), exp_ptr+sizeof(todo_wine_cmd)); > + }else if(err) { > + if (!is_todo_wine) > + ok(0, "unexpected char 0x%x position %d in line %d (got '%.*s', wanted '%.*s')\n", > + *err, (int)(err-out_ptr), line, (int)(out_nl-out_ptr), > + out_ptr, (int)(exp_nl-exp_ptr), exp_ptr); > + else > + todo_wine > + ok(0, "unexpected char 0x%x position %d in line %d (got '%.*s', wanted '%.*s')\n", > + *err, (int)(err-out_ptr), line, (int)(out_nl-out_ptr), out_ptr, > + (int)(exp_nl-exp_ptr-sizeof(todo_wine_cmd)), exp_ptr+sizeof(todo_wine_cmd)); > + }else { > + if(is_todo_wine) > + todo_wine ok(TRUE, "match at line %d\n", line); > + } > Hello, I think Jacek was suggesting something among these lines, which does look prettier imho (replace quoted text with following): + if(err == out_nl) { + if (!is_todo_wine) + ok(0, "unexpected end of line %d (got '%.*s', wanted '%.*s')\n", + line, (int)(out_nl-out_ptr), out_ptr, (int)(exp_nl-exp_ptr), exp_ptr); + else + todo_wine + ok(0, "unexpected end of line %d (got '%.*s', wanted '%.*s')\n", + line, (int)(out_nl-out_ptr), out_ptr, + (int)(exp_nl-exp_ptr-sizeof(todo_wine_cmd)), exp_ptr+sizeof(todo_wine_cmd)); + }else { + if (!is_todo_wine) + ok(!err, "unexpected char 0x%x position %d in line %d (got '%.*s', wanted '%.*s')\n", + *err, (int)(err-out_ptr), line, (int)(out_nl-out_ptr), + out_ptr, (int)(exp_nl-exp_ptr), exp_ptr); + else + todo_wine + ok(!err, "unexpected char 0x%x position %d in line %d (got '%.*s', wanted '%.*s')\n", + *err, (int)(err-out_ptr), line, (int)(out_nl-out_ptr), out_ptr, + (int)(exp_nl-exp_ptr-sizeof(todo_wine_cmd)), exp_ptr+sizeof(todo_wine_cmd)); + } There is also another difference from your code: the code above also counts the succeeded tests, whereas your code doesn't. Octavian

June 15, 2011

Re: [PATCH 1/6] server: Add server-side raw input functions definitions

by Vitaliy Margolen

On 06/14/2011 02:45 AM, Vincas Miliūnas wrote: > This is a partial raw input implementation for mouse and keyboard. > > I've read in the IRC chat, that products of tools/make_request should > not be included in a patch, so I left them out. > > My first attempts were by leeching input events from queue_mouse_message and queue_keyboard_message functions, but I couldn't get mouse cursor movement right. Instead, I copied the way dinput receives input - by installing low level hooks and forwarding input to the server. This is just to get "try 1" out of the door. Of course, it would be better if the input feed would be server-side only. > > I hit a very weird bug, where in peek_message function, info.msg.lParam was impossible to set with the proper lParam (it was correct in reply->lparam) value, instead is was overwritten by some constant. That was happening only for the messages sent by the patch using post_message. I guess the tales of server-side dragons hold some truth... If anyone wants to try to reproduce it, just recompile without the unused #include "user.h" in raw_input.c and run user32 tests. > > This patch game-tested and works for Quake Live (in_mouse 2 for raw input), World of Tanks and Risen. I'm not sure I like your approach and that AJ would like it either. Raw input is an "override" of regular messages caused by mouse/keyboard input. Wine server already receives these messages from x11drv (see __wine_send_input & co). When applications requests raw input events you need to tell wine server if it needs to send regular events, or ignore all events, and produce raw input events instead. Vitaliy.

June 15, 2011

Re: GSoC: dinput8 Action Mapping

by Vitaliy Margolen

On 06/14/2011 10:57 AM, Lucas Zawacki wrote: >> keybd_event( key, 0, 0, 0); >> Have you tried using more meaningful parameters then 0? > > Yes, I've tried issuing a scan code as the second parameter, it was no > use. I tried sending the keybd_event and then sending another one with > KEYEVENTF_KEYUP to "emulate" a key press and a release and still no > change. I've tried setting dummy values as the last parameter, but had > similar results. I don't know what it's for and msdn was not > helpful... On Windows dinput really does talk to the driver directly. That's why you don't see those injected events. At least you can test things with native dinput on Wine. And don't include tests in your patches. Just use them to validate that everything is working. Vitaliy.

June 15, 2011

Re: GSoC: dinput8 Action Mapping

by Vitaliy Margolen

On 06/14/2011 03:09 PM, Marcus Meissner wrote: > On Tue, Jun 14, 2011 at 02:07:32PM -0300, Lucas Zawacki wrote: >>> Also please implement unicode method and call it from ascii. (IDirectInput8AImpl_EnumDevicesBySemantics -> IDirectInput8WImpl_EnumDevicesBySemantics) >> Sorry if that's a stupid question, but what should I do with the >> string parameters? Is it ok to call a W function with the A >> parameters? > > No, it would need to converted back and forth. > > I think for the first committed patches having them seperate is fine, it could > be factored out later, as W<->A conversion for the callback handler will be tricky. Because callback doesn't have any string parameters it would be an easy thing to do. Vitaliy.

June 15, 2011

Re: [PATCH 4/5] d3d9/tests: Add some tests for IDirect3DDevice9::UpdateSurface().

by Alexandre Julliard

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/d3d9/tests/visual.c | 188 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 188 insertions(+), 0 deletions(-) I'm seeing occasional failures with this one: ../../../../wine/tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so ../../../../wine/dlls/d3d9/tests/visual.c && touch visual.ok visual.c:8909: Tests skipped: D3DFMT_G16R16 textures not supported as render targets. visual.c:7503: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:12255: Test failed: Update surface returned 0x8876086c for test 5, expected 0. make: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

June 15, 2011

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

by Vincent Povirk

Won't Wine pass the test only the first time it's run? 2011/6/15 Mariusz Pluciński <vshader(a)gmail.com>: > 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 15, 2011