June 2011 - wine-devel

Re: wined3d: Use a separate mutex for wndproc_table access.
by Stefan Dösinger 19 Jun '11

19 Jun '11

I can't speak about the conceptual correctness of this patch, although my gut feeling says that you're right. You don't need wined3d_wndproc_mutex_(un)lock. Just use EnterCriticalSection / LeaveCriticalSection directly. wined3d_mutex_lock exists because it is exported from wined3d. On Friday 17 June 2011 21:49:38 Piotr Pawlow wrote: > If CreateDevice is called with hFocusWindow belonging to another thread, > then any code that does SendMessage (or equivalent) to the window while > holding the main wined3d mutex causes a deadlock, because wined3d_wndproc > tries to acquire the same mutex for wndproc_table access. Using a different > mutex for this purpose solves the problem. > --- > dlls/wined3d/wined3d_main.c | 44 > +++++++++++++++++++++++++++++++----------- > 1 files changed, 32 insertions(+), 12 deletions(-)

2 1

Re: CopyFileExW Support
by Jerome Leclanche 19 Jun '11

19 Jun '11

You are severely mixing tabs and spaces, you should fix your editor. You also have a lot of unrelated trailing whitespace changes; granted they all remove trailing whitespace, but since this isn't a small patch, it makes it harder to read. J. Leclanche On Sun, Jun 19, 2011 at 2:40 AM, Arthur Dene Ice <addtheice(a)gmail.com> wrote: > > > > >

1 0

Re: [PATCH 1/3] user32/tests: Added client-side raw input function tests (try 3)
by Marvin 19 Jun '11

19 Jun '11

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=11822 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

1 0

Wrong AppDB link
by wylda＠volny.cz 19 Jun '11

19 Jun '11

Hi, by mistake i linked a wrong bug to FAR Manager: http://appdb.winehq.org/objectManager.php?sClass=version&iId=15928 Could someone remove a link from FAR to bug 27406, please? Thanks, W.

2 1

Re: openal32: test whether alGetError() returns AL_NO_ERROR when called out of context, with fix.
by Chris Robinson 19 Jun '11

19 Jun '11

On Saturday, June 18, 2011 8:32:31 PM Dan Kegel wrote: > Matches native behavior. Makes at least one app happier; see bug 27532. Just to toss in my comments, the "native" behavior referred to is the behavior of Creative's DLLs, but Creative's DLLs aren't the only ones available for Windows. OpenAL Soft behaves the same way as a real DLL as it does a Linux DSO (ie, returns an error from alGetError() when no current context is set), and IIRC, there are Windows apps that prefer using it over Creative's sometimes- unstable drivers. There is at least one other OpenAL implementation available for Windows that some apps use, but I don't know how it behaves and it costs money. IMO, it is a bug in both Creative's DLLs and the affected app. Two bugs nullifying each other, essentially. Using OpenAL Soft's DLL in place of Creative's, in real Windows, would yield the same bug experienced in Wine.

1 0

Re: shdocvw: Add ITaskbarList2 Interface
by Alistair Leslie-Hughes 19 Jun '11

19 Jun '11

Hi André, On 19/06/2011 1:52 AM, André Hentschel wrote: > --- > dlls/shdocvw/taskbarlist.c | 74 ++++++++++++++++++++++++++++--------------- > include/shobjidl.idl | 15 +++++++++ > 2 files changed, 63 insertions(+), 26 deletions(-) Can you please provide a test case to show that this interface exists? Best Regards Alistair Leslie-Hughes

1 0

Re: [PATCH 2/2] d3dx9/line: Implemented tests for ID3DXLine's Begin and End methods.
by Marvin 18 Jun '11

18 Jun '11

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=11808 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

STATE_VDECL & friends
by Stefan Dösinger 17 Jun '11

17 Jun '11

Hi, This is a brain core dump before going to bed for the other d3d developers. I did some testing concerning the vertexdeclaration, vertex shader, stream sources and pixel shader states. Currently the first 3 are hard linked, and the pixel shader is also tied to the vertex shader. I was interested which states are invalid how often, and where separating the states makes sense. Basically about 40% of all draws only the pixel shader is invalid. In another 30%-50% the pixel shader and stream source are invalid, and in about 10% to 20% of all draws all 4 states are reapplied anyways. There are relatively few cases where the vertex declaration and vertex shader are changed alone. So what does this mean? We'll have to spit away the pixel shader and stream sources states. The good news is that the stream sources are easy to separate - when the streamsources are invalid only reapply them, if the vdecl or vshader are dirty reapply shader+decl+streamsrc. The bad news is that applying the stream sources is the most expensive part. The pixel shader is already somewhat separated. Changing the pixel shader will only reapply the vertex shader, but not stream sources or other vdecl-related states. Separating vertex and pixel shaders will be tricky and not fully possible on some drivers(needs GL_ARB_separate_shader_objects or ARB shaders) and all shaders(Shader Model 3.0 varying passing) In addition to this we'll have to make parsing of the vertex declaration cheaper. I'll think of something... I'll also write some quick and dirty patches to see how much performance we really get out of these changes. Stefan PS: I attached my debug patch and the output for a few games.

1 0

limits on the number of events, windows and threads?
by Joerg-Cyril.Hoehle＠t-systems.com 17 Jun '11

17 Jun '11

Hi, I vaguely remember reading about a quite low limit on the number of event objects that a thread can hold because each one is said to take up one bit in some 32 or 64 bit mask. That was then invoked as a reason to allocate e.g. event or window objects for as short a time span as possible. Is there such a low limit on the number of events (or other types of handles) than one thread can hold in native or in Wine? Thank you for your help, Jörg Höhle

2 1

Re: winealsa: Avoid deadlock in AudioClient_Stop.
by Andrew Eikum 17 Jun '11

17 Jun '11

Hi Jörg, Patch makes sense to me. I'll put together some patches for the other drivers, unless you beat me to it ;) Thanks, Andrew On 06/17/2011 10:13 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > my patch is not the final word about robust design. > > Consider what happens when > DeleteTimerQueueTimer(g_timer_q, This->timer, INVALID_HANDLE_VALUE) > cannot allocate its CompletionEvent. The function will return with an > (ignored) error and not stop the timers. Do you see a check in > wineoss or winecoreaudio? The later Audio_Release will destroy > critical sections and free memory while the timers are still running! > > A tiny allocation failure => big crash > > Deallocators should not fail when resources are scarce. > > A more robust design would see Audio_Start allocate the completion > event that DeleteTimerQ requires and not start if it can't be sure to stop. > Why require a completion event? Because there's > *no* other way of telling whether a callback might still be invoked. > Even sleeping for more than the timer period is no guarantee rather > than mere heuristics that works on a slightly loaded system. > > Back to my patch. It's funny to think that it would mostly work > without error checking: DeleteTimerQ(event) does something with > event NULL or not, Wait(NULL) would immediately return and > DeleteTimerQ always signals the event when successful. > > Regards, > Jörg Höhle > > > >

1 0

Re: [1/7] server: Implement RegisterHotKey/UnregisterHotKey.
by Alexandre Julliard 17 Jun '11

17 Jun '11

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -2632,6 +2632,29 @@ enum coords_relative > #define SET_USER_OBJECT_FLAGS 1 > > > +/* Register a hotkey */ > +@REQ(register_hotkey) > + user_handle_t window; /* handle to the window */ > + int id; /* hotkey identifier */ > + int flags; /* modifier keys */ > + int vkey; /* virtual key code */ > +@REPLY > + int replaced; /* did we replace an existing hotkey? */ > + int flags; /* flags of replaced hotkey */ > + int vkey; /* virtual key code of replaced hotkey */ > +@END The docs say that hotkeys are no longer replaced in recent Windows versions. It would be a good idea to have a test for that. -- Alexandre Julliard julliard(a)winehq.org

2 1

dead-lock free design
by Joerg-Cyril.Hoehle＠t-systems.com 17 Jun '11

17 Jun '11

Hi, there are two guidelines that I identified while trying to prevent dead-locks with critical sections and access to uninitialiased memory in Wine. My latest patch shows both applications. http://www.winehq.org/pipermail/wine-patches/2011-June/103247.html 1. In callbacks, detect when it should not run anymore and exit *early*. void CALLBACK mycallback (void* user) { struct mycbdata * mycb = user; EnterCriticalSection(mycb->lock); if(!mycb->started || mycb->shutdown) { LeaveCriticalSection; return; } /* else do actual work */ This is best done after EnterCS, because the critical section is the most likely place where the callback thread will have been preempted. Note that this doesn't prevent mycb from pointing to free'ed memory. You may only deallocate resources once you've made sure that the callback cannot be invoked any more. 2. Use two phases to end cleanly. Delegate part of the work to a later stage. Pause is not Stop. Stop is not Close. Close is not Shutdown. Shutdown is not DLL Unload. My current patch applies this idea partially. DeleteTimerQueueTimer() is called within a CS, whereas Wait() is called afterwards (which is safe because the mmdevapi object is not used any more). The original deadlock happened because DeleteTimerQueue and Wait were combined in one call, within the CS. Waiting for completion is *essential* with the DeleteTimerQueueTimer API because that's the only means to ensure that callbacks are done. Then only can you free the memory that mycb above points to. A variation is to partition the work among AudioClient_Stop and AudioClient_Release. In Stop() call DeleteTimerQueueTimer() but Wait for completion of the callbacks in Release(). Alternatively, in Stop() use ChangeTimerQueueTimer(DueTime=INFINITE) to prevent firing new callbacks and use DeleteTimerQueue in Release(). I didn't write my patch that way yet because it requires some attention in AudioClient_Start() when restarting the timer callbacks. Why does the rule work? Functions likes Play/Pause/Stop typically prevent concurrent access (either from the app or from internal callback threads) using critical sections. At Close/Release time, the typical assumption is that there's no more concurrency -- at least from the side of the application. Partitioning the work allows for plenty of new possibilities. E.g. one known bug in MS-Windows is that MCI/winmm's Stop() may take a lot of time, freezing the application. However, if Stop() simply sends a stop signal to the player thread, without waiting for the thread to actually stop, it can be plenty fast. Likewise, if mmdevapi's AudioClient_Stop() simply sets This->started to FALSE, the callback will still be ticking, but not disturb. Fast too if it calls DeleteTimerQueueTimer() but delegates the Wait to AudioClient_Release(). One drawback is that resources will be allocated for longer than with the naïve approach. Sometimes, the partitioning decision depends on what state you want to guarantee after Pause, Stop or Close. This is rarely documented. E.g. for MCI's audio player you want to make sure that an immediately following Open won't fail when Wine's winmm ALSA or OSS drivers only support opening one device at a time. Regards, Jörg Höhle

1 0

dead link on directdraw wiki to directdrawrenderer
by Jarek Czekalski 17 Jun '11

17 Jun '11

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?

2 1

Re: urlmon: Fix incorrect pointer arithmetic (too conversative) in map_url_to_zone. (RESEND^2)
by Gerald Pfeifer 17 Jun '11

17 Jun '11

A friendly soul pointed out to me that I had missed three(!) responses to my patch which went to wine-devel@. 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)); >

1 0

GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
by Michael Mc Donnell 17 Jun '11

17 Jun '11

Thanks for the comments Matteo! I have a few questions below. On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >> <stefandoesinger(a)gmx.at> wrote: >>> On Saturday 28 May 2011 19:55:55 you wrote: >>> >>>> It was implemented by setting the vertex declaration to null when the >>>> declaration is invalid. That seems to match what happens on Windows, >>>> because if a program has set an invalid declaration and then calls >>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>> Should Wine also fail with an access violation or should it be >>>> slightly more graceful and return E_FAIL instead (which my new patch >>>> does)? >>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>> be shown by default(unlike a FIXME), it is used when the app does something >>> fishy but you think you handled it correctly. >>> >>>> + if (FAILED(hr)) >>>> + new_vertex_declaration = NULL; >>>> + >>>> + /* Free old vertex declaration */ >>>> + if (This->vertex_declaration) >>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>> In this situation you can just release the old decl before calling >>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>> NULL in case of an error though >> >> Ok I've simplified the code. I've also inserted three WARNs. I've >> skipped a WARN when freeing the mesh because that works fine on >> Windows with an invalid declaration. >> >>>> + /* Set the position type to color instead of float3 (invalid >>> declaration) */ >>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>> + "got %#x expected D3D_OK\n", hr); >>> Is this really invalid? I don't know it on top of my head, but in general >>> types and usage are independent, especially with shaders. I don't see a check >>> in d3d9 or wined3d for this case. >> >> You're right it isn't invalid. It doesn't crash, it just doesn't draw >> anything. I've change that comment and re-ordered the tests. >> >>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>> devel one more time and then next week to wine-patches. Henri is on Vacation >>> this week, and he's usually more picky than I am. I also hope some of the >>> people who regularly contribute to d3dx9 will have a look and comment. >> >> Ok, I've attached the newest version. I'll let the patches sit here >> for a week, and start working on the other functions in the mean time. >> > > The patches are OK with me, just some nitpicking: That sounds great :-) > + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); > > We usually use something like HeapAlloc(GetProcessHeap(), 0, > sizeof(*testContext)); instead. Ok, I guess that's better in case the type of the variable changes at some point? > I think you can remove some obvious comments (like /* Create the test > mesh */). Also, check your whitespaces. Is it too much or too little whitespace? Could you give me an example? Thanks!

5 13

Re: [2/2] imm32: Factor out the message checks from ImmIsUIMessageA/W and fix them
by Marvin 16 Jun '11

16 Jun '11

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

2 1

app freezes during WM_KILLFOCUS
by Eric Frias 16 Jun '11

16 Jun '11

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

2 2

Re: [PATCH 1/6] server: Add server-side raw input functions definitions
by Vitaliy Margolen 16 Jun '11

16 Jun '11

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.

2 3

Re: [3/3] d3dx9/tests: Implemented tests for ID3DXLine_GetDevice.
by Matteo Bruni 16 Jun '11

16 Jun '11

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. :)

1 0

Re: [1/3] d3dx9/line: Added device pointer to ID3DXLineImpl and initialize it.
by Matteo Bruni 16 Jun '11

16 Jun '11

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.

1 0

Re: strmbase: Don't use list_count() to check that a list is not empty.
by Michael Stefaniuc 16 Jun '11

16 Jun '11

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

1 0

Re: [PATCH 2/2] wineboot: Split prefix updating into two parts.
by Alexandre Julliard 16 Jun '11

16 Jun '11

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

1 0

Re: [2/3] cmd/tests: Add support for todo_wine constructions (try 3)
by Octavian Voicu 16 Jun '11

16 Jun '11

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

2 1

Re: [PATCH 4/5] d3d9/tests: Add some tests for IDirect3DDevice9::UpdateSurface().
by Alexandre Julliard 15 Jun '11

15 Jun '11

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

1 0

Re: [PATCH 1/5] shell32: Add IKnownFolderManager::RegisterFolder implementation
by Vincent Povirk 15 Jun '11

15 Jun '11

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(-) > > > > > >

1 0

Re: [6/7] user32: Test that QS_HOTKEY is properly set and cleared.
by Marvin 15 Jun '11

15 Jun '11

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

1 0

Re: [2/7] server: Post WM_HOTKEY when a hotkey is pressed.
by Marvin 15 Jun '11

15 Jun '11

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

1 0

Re: [1/7] server: Implement RegisterHotKey/UnregisterHotKey.
by Marvin 15 Jun '11

15 Jun '11

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

1 0

Re: [PATCH 3/5] shell32: Add support of registry-registered folders to IKnownFolderManager::GetFolder
by Marvin 15 Jun '11

15 Jun '11

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

1 0

Re: [PATCH 2/5] shell32: Add IKnownFolderManager::UnregisterFolder implementation
by Marvin 15 Jun '11

15 Jun '11

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

1 0

Re: [PATCH 1/5] shell32: Add IKnownFolderManager::RegisterFolder implementation
by Marvin 15 Jun '11

15 Jun '11

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

1 0

Re: [PATCH 2/4] user32/tests: Added client-side raw input functions tests (try 2)
by Marvin 15 Jun '11

15 Jun '11

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=11753 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

1 0

Re: [PATCH] winspool.drv: Removed a superflous NULL check (Coverity)
by Marvin 15 Jun '11

15 Jun '11

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=11752 Your paranoid android. === WINEBUILD (build) === Can't determine base name

1 0

Add sub-message to a commit
by GOUJON Alexandre 15 Jun '11

15 Jun '11

Hi, I would like to add a 'sub'-message to a commit like this one http://source.winehq.org/git/wine.git/commitdiff/dbd878639424071e1d4c6cfc9b… I know that I can specify this text at the beginning of a patch I want to send to wine-patches (befor the '---'). But here, I'm interested in how to do that on the git server side. git commit -a or git commit -m let me specify a 'global' commit message. I googled some key words and RTFMs but didn't find anything relevant. Any hints on how to do that ? I can ask AJ directly but 1) it may be considered as rude and selfish 2) some people may be interested by the answer Thanks in advance

3 3

Re: [6/7] dxdiagn: Add additional adapter identifier properties for DxDiag_DisplayDevices subcontainers.
by Marvin 15 Jun '11

15 Jun '11

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

2 1

TaskDialog implementation
by Patrick Gauthier 15 Jun '11

15 Jun '11

Hello everyone, I'd like to port my re-implementation of task dialogs (http://www.korosoft.net/projects/tdemu/) to WINE, actually I have posted a small patch yesterday (merely rearranges some source around, preparatory work) which sadly did not seem to get accepted. I'm going to take my code and clean it to WINE's source code standards, however I do not see how I could split it in many patches as everything is dependant on everything else. As this is quite a big amount of work, I would like to have some guidance (what must I do to be sure it is accepted) so that I do not end up doing all that for nothing - starting by knowing why my patch from yesterday was not accepted (what did I do wrong). Thanks for your time and help.

7 8

re: dxdiag: Add code for XML information output
by Dan Kegel 15 Jun '11

15 Jun '11

Andrew Nguyan's commit, http://www.winehq.org/pipermail/wine-cvs/2011-June/078592.html used the construct static BOOL output_xml_information(struct dxdiag_information *dxdiag_info, const WCHAR *filename) { const struct information_block { const WCHAR *tag_name; struct information_field { const WCHAR *tag_name; const WCHAR *value; } fields[50]; } output_table[] = { {SystemInformation, { {Time, dxdiag_info->system_info.szTimeEnglish}, ... Isn't Wine was supposed to avoid non-static struct initializers? I think it'll get "warning: initializer element is not computable at load time" with --std=c89 --pedantic.

2 1

Re: [PATCH 3/5] ddraw: Add iface count for IDirectSurfaceImpl.
by Henri Verbeet 15 Jun '11

15 Jun '11

2011/6/14 <rbarkauskas(a)codeweavers.com>: > +static void ddraw_surface_add_iface(IDirectDrawSurfaceImpl *This) > +{ > + ULONG refCount = InterlockedIncrement(&This->numIfaces); Please use wined3d code style for new code. I.e., This -> surface, refCount -> refcount, numIface -> iface_count, space after control statements, etc.

1 0

Re: [PATCH 2/5] ddraw: Adjust reference counts of created surfaces in ddraw_set_surface_version.
by Henri Verbeet 15 Jun '11

15 Jun '11

2011/6/14 <rbarkauskas(a)codeweavers.com>: > + switch(version) > + { > + case 4: > + IDirectDrawSurface4_AddRef(&surface->IDirectDrawSurface4_iface); > + break; > + case 3: > + case 2: > + case 1: > + IDirectDrawSurface_AddRef(&surface->IDirectDrawSurface_iface); > + break; > + } > + IDirectDrawSurface7_Release(&surface->IDirectDrawSurface7_iface); Why do you need this here instead of in the relevant surface creation functions? (I suppose because of the mipmaps, but I think it may be better to do all this when the surface is created instead of afterwards.)

1 0

Re: [PATCH 5/5] ddraw: Separate IDirectDrawSurface2 reference count.
by Alexandre Julliard 15 Jun '11

15 Jun '11

rbarkauskas(a)codeweavers.com writes: > @@ -766,6 +766,8 @@ DestroyCallback(IDirectDrawSurface7 *surf, > > /* Destroy the surface */ > while(ref) ref = IDirectDrawSurface7_Release(surf); > + ref = Impl->ref2; > + while(ref) ref = IDirectDrawSurface2_Release(&Impl->IDirectDrawSurface2_iface); Ref counts should only be accessed through the interlocked functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

deadlock in mmdevapi AudioClient_Stop (winealsa.drv/mmdevdrv.c)
by Joerg-Cyril.Hoehle＠t-systems.com 15 Jun '11

15 Jun '11

Hi, please try and convince me that a deadlock cannot happen. http://source.winehq.org/source//dlls/winealsa.drv/mmdevdrv.c AudioClient_Start calls CreateTimerQueueTimer which creates a new thread periodically invoking the timer callback. The callback invokes alsa_push_buffer_data() which ceases the audio client object lock (This->lock). AudioClient_Stop performs EnterCriticalSection(&This->lock); then DeleteTimerQueueTimer(g_timer_q, This->timer, INVALID_HANDLE_VALUE); Now imagine Stop is invoked, EnterCriticalSection executed then the thread is preempted. Suppose the timer callback kicks in: alsa_push_buffer_data will block on This->lock. When the thread is resumed, DeleteTimerQueue will hang forever waiting for all timer callbacks to come to an end. My opinion is that critical sections are great to prevent concurrent execution while things are running, but they are hell to tear down properly. IMHO, LeaveCriticalSection + Re-EnterCriticalSection around DeleteTimerQueue is not a solution. I consider using Leave+EnterCS around anything that can wait/block an anti-pattern (there are a few places like that in Wine). I believe a "restart op" is needed in general (like a "restart transaction if it failed" in databases) as anything could have happened while waiting. Regards, Jörg Höhle

2 1

Re: [4/6] winex11.drv: Grab registered hotkeys in the X server.
by Ken Thomases 15 Jun '11

15 Jun '11

On Jun 14, 2011, at 12:40 AM, Vincent Povirk wrote: >> Is it necessary to test QS_HOTKEY in dlls/winex11.drv/event.c:filter_event, where QS_KEY is currently tested? If somebody calls MsgWaitForMultipleObjectsEx with QS_HOTKEY but not QS_KEY, shouldn't KeyPress events be accepted? >> > > I guess? Wouldn't we have to actually set QS_HOTKEY before that does any good? You mean your patch 5? Well, it's a bit of a chicken-and-egg situation. I don't think it matters much which order the two things are added. They'll both ultimately be necessary. In some sense, doing winex11.drv first makes sense, since it's the first "gate" for the event to make it into the system. (Admittedly, it's probably very unlikely that MsgWaitForMultipleObjectsEx will be called with QS_HOTKEY and not QS_KEY.) >> You may be able to use the non-left-right-sensitive vkeys (e.g. VK_MENU) here, and thus eliminate the alt_vkey parameter. And if you can't, then update_modifier_state doesn't do the right thing when alt_vkey is the one that's pressed in the keystate but it's no longer pressed in event->state. In that case, you send a key-up for vkey, when you should send it for alt_vkey. If both were down and now neither is, you'll need to send a key-up for both. Note, to send keyboard input for a right-hand modifier, you'll need to include KEYEVENTF_EXTENDEDKEY in the flags and different scan codes. > > There's no such combined vkey for the windows key. Even if there were, > releasing VK_MENU when VK_LMENU was pressed doesn't seem like a good > idea. I was thinking that maybe the send-input machinery would take a side-generic key and do the right thing. A little more research reveals that it doesn't. However, that still leaves you doing the wrong thing with your side-sensitive code. If event->state doesn't include MetaMask, then you send a key-up for VK_LMENU when it may have been VK_RMENU that was previously down. You need to send a key-up for whichever was previously down, and that might even be both. Note that the important thing is not that you have sent a key event for the wrong key, it's that you haven't properly transitioned to a state which matches event->state. That is, you sent the key-up but the overall key state will still have a menu key down. > Now you've got me worried about what happens when we press VK_LWIN and > it later turns out VK_RWIN was really pressed (and has been released). > :/ For when you send a key-down, it's not so important. In that case, you're properly transitioning from neither being down to at least one of them being down. If it later turns out that you synthesized a VK_LWIN-down when the user had actually pressed VK_RWIN, then that will get corrected on the next KeymapNotify. -Ken

1 0

Re: [PATCH 1/6] server: Add server-side raw input functions definitions
by Austin English 15 Jun '11

15 Jun '11

2011/6/14 Vincas Miliūnas <vincas.miliunas(a)gmail.com>: > 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. > > Feedback is very much appreciated. Thanks. > > --- > server/protocol.def | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 79 insertions(+), 0 deletions(-) Howdy Vincas, This patch breaks the compile: $ patch -p1 < ~/75274 $ ./tools/make_requests $ ./configure --disable-tests $ make make[1]: Entering directory `/home/austin/wine-git/server' gcc -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o debugger.o device.o directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o -L../libs/wine -lwine ../libs/port/libwine_port.a -Wl,--rpath,\$ORIGIN/../libs/wine request.o:(.rodata+0x494): undefined reference to `req_get_raw_input_device_list' request.o:(.rodata+0x498): undefined reference to `req_register_raw_input_device' request.o:(.rodata+0x49c): undefined reference to `req_unregister_raw_input_device' request.o:(.rodata+0x4a0): undefined reference to `req_is_raw_input_data' request.o:(.rodata+0x4a4): undefined reference to `req_get_raw_input_data' request.o:(.rodata+0x4a8): undefined reference to `req_get_registered_raw_input_devices' request.o:(.rodata+0x4ac): undefined reference to `req_add_raw_input_data' request.o:(.rodata+0x4b0): undefined reference to `req_get_raw_input_device_info' collect2: ld returned 1 exit status make[1]: *** [wineserver] Error 1 make[1]: Leaving directory `/home/austin/wine-git/server' make: *** [server] Error 2 which you implement in patch 5. Every patch needs to stand on its own, without breaking the tests/compile. For such a complicated changeset, it's probably best to send the tests in on their own first, with the failing tests wrapped in todo_wine(). See also http://wiki.winehq.org/SubmittingPatches BTW, thanks for working on this, I used your earlier patches to play a bit of Brink ;-). -- -Austin

1 0

Re: [PATCH 6/6] user32/tests: Add client-side raw input functions tests
by Marvin 14 Jun '11

14 Jun '11

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=11737 Your paranoid android. === W7PROX64 (64 bit input) === No test summary line found

1 0

wined3d performance patches
by Stefan Dösinger 14 Jun '11

14 Jun '11

Hi, This is intended mostly for the other d3d developers, but since we have quite a number of them now so individual CCs are a lot of work :-) I attached the patches I currently have in my tree to give an update on what I've been working on recently. The main aim of those patches is to reduce draw overhead a bit, thus improving game performance. The patches need some cleanup, but for that I first need a patch Matteo is working on. Feedback is welcome. I'm also interested in test results, e.g. if the changes break a game, or the performance impact. If those patches cause a 5% performance increase I am happy. Patches 1-3: Mostly unrelated. I haven't sent them yet because patch 3 breaks Unigine Heaven, and patches 1 and 2 make little sense without 3. Patch 4: This removes a hack for a driver bug workaround. I have to do more testing on my old machines to find out if the bug is really fixed in newer nvidia drivers. Patches 5, 6: They keep track of changes to the framebuffer setup so we don't have to run through the code that figures out which FBO to bind every draw. Patch 5 gets rid of the ordering assumption. Patch 6 applies the FBO only when needed. They aren't ready yet. In patch 6 the FBO may have to be reapplied when the pixelshader changes. To implement that I need some draw buffer tracking infrastructure Matteo is working on. Also clears can be integrated. fbo- clear.diff is a half-baked attempt to do this. I dropped it when I realized I was duplicating Matteos work. After that I have to double-check that I took care of all situations where the FBO may have to be updated. Furthermore, Matteo says that not calling context_apply_draw_buffers every time framebuffer() is run is a noticeable performance improvement too. Matteo, did you test this with just patch 0005, or both 0005 and 0006? Patch 0007: Sampler map optimization, it has a lengthy description in the patch file Patch 0008: A tiny fix, it results in a pretty small improvement on OSX. On Linux+Nvidia it is not noticeable. Patch 0009: At first I tried to skip the render target dirtification entirely via a flag in the d3ddevice, but it was pretty tricky and ugly. Just making it cheaper gets us ~2/3rd of the way too. (Draw overhead tester performance without this: 259 fps. Complete disabling of the dirtification calls via a hack: 275. With this patch: 269) 0010: An unrelated cleanup Patches 11, 12: Preparation for including clears in the fbo dirtification patches. See fbo-clear.diff. More work on performance is obviously required, for example *) Separate vertex declaration, vertex shader and pixel shader states *) Speed up sampler preloading. This will be easier once we have a tree-like state structure. *) Write more tests for other common operations, like clears, blits, shader changes, texture changes, vertex buffer changes, dynamic resource loading *) Test our shader's GPU-side execution performance *) See if we can do something about locking *) Isolate bottlenecks in the GPU drivers and get them fixed.

4 7

Re: [2/3] cmd/tests: Add support for todo_wine constructions (try 2)
by Jacek Caban 14 Jun '11

14 Jun '11

Hi Frédéric, On 6/13/11 10:19 PM, Frédéric Delanoy wrote: > + }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)); You may change tests to ok(!err, ....) here and make this else unconditional to avoid having ok(TRUE, ...) tests later. Jacek

2 6

Re: [PATCH 2/2] d3dx9: Return E_FAIL for unsupported ascii effects.
by Alexandre Julliard 14 Jun '11

14 Jun '11

Rico Schüller <kgbricola(a)web.de> writes: > --- > dlls/d3dx9_36/effect.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) It breaks the tests: ../../../tools/runtest -q -P wine -M d3dx9_36.dll -T ../../.. -p d3dx9_36_test.exe.so effect.c && touch effect.ok effect.c:52: Test failed: Got result 80004005, expected 0 (D3D_OK) wine: Unhandled page fault on execute access to 0x00000000 at address (nil) (thread 0023), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv: Only set MWM hints if they have not been modified
by Alexandre Julliard 14 Jun '11

14 Jun '11

Scott Talbert <talbert(a)techie.net> writes: > Hello, > > The below patch resolves an issue (BZ# 27473) where the window manager > removes window decorations and Wine restores them. The code in the > patch checks to see whether the window decorations have been modified > and if so, > it does not modify them further. That's a Unity bug. The window manager is not supposed to change the MWM hints, they are controlled by the client. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] wined3d: Add GL_ARB_draw_elements_base_vertex
by Henri Verbeet 14 Jun '11

14 Jun '11

On 13 June 2011 22:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +typedef void (WINE_GLAPI *PGLFNDRAWELEMENTSBASEVERTEX)(GLenum mode, GLsizei count, GLenum type, > + const GLvoid *indices, GLint basevertex); With the usual naming convention this would be called "PGLFNDRAWELEMENTSBASEVERTEXPROC".

1 0

Re: [4/6] winex11.drv: Grab registered hotkeys in the X server.
by Ken Thomases 14 Jun '11

14 Jun '11

On Jun 13, 2011, at 2:07 PM, Vincent Povirk wrote: > <0005-winex11.drv-Grab-registered-hotkeys-in-the-X-server.txt> Is it necessary to test QS_HOTKEY in dlls/winex11.drv/event.c:filter_event, where QS_KEY is currently tested? If somebody calls MsgWaitForMultipleObjectsEx with QS_HOTKEY but not QS_KEY, shouldn't KeyPress events be accepted? > +static void update_modifier_state(int modifier_mask, int actual_mask, > + BYTE *keystate, WORD vkey, WORD alt_vkey, WORD scan, DWORD event_time) > +{ > + int key_pressed = (actual_mask & modifier_mask) != 0; > + int vkey_pressed = (keystate[vkey] & 0x80) == 0x80 || > + (keystate[alt_vkey] & 0x80) == 0x80; > + DWORD flags; > + > + if (key_pressed != vkey_pressed) > + { > + if (key_pressed) > + flags = 0; > + else > + flags = KEYEVENTF_KEYUP; > + TRACE_(key)("Adjusting modifier state vkey=0x%x, state=%i\n", vkey, key_pressed); > + X11DRV_send_keyboard_input( NULL, vkey, scan, flags, event_time ); > + } > +} > + update_modifier_state(MetaMask, event->state, keystate, VK_LMENU, VK_RMENU, 0x38, event_time); > + update_modifier_state(ControlMask, event->state, keystate, VK_LCONTROL, VK_RCONTROL, 0x1D, event_time); > + update_modifier_state(ShiftMask, event->state, keystate, VK_LSHIFT, VK_RSHIFT, 0x2A, event_time); > + update_modifier_state(SuperMask, event->state, keystate, VK_LWIN, VK_RWIN, 0x15b, event_time); You may be able to use the non-left-right-sensitive vkeys (e.g. VK_MENU) here, and thus eliminate the alt_vkey parameter. And if you can't, then update_modifier_state doesn't do the right thing when alt_vkey is the one that's pressed in the keystate but it's no longer pressed in event->state. In that case, you send a key-up for vkey, when you should send it for alt_vkey. If both were down and now neither is, you'll need to send a key-up for both. Note, to send keyboard input for a right-hand modifier, you'll need to include KEYEVENTF_EXTENDEDKEY in the flags and different scan codes. -Ken

1 0

Re: [3/6] server: Implement RegisterHotKey/UnregisterHotKey.
by Octavian Voicu 13 Jun '11

13 Jun '11

Hello, Shouldn't you also increment SERVER_PROTOCOL_VERSION in include/wine/server_protocol.h? Octavian

2 2

Re: [6/6] user32: Test that QS_HOTKEY is properly set and cleared.
by Marvin 13 Jun '11

13 Jun '11

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=11709 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [3/6] server: Implement RegisterHotKey/UnregisterHotKey.
by Marvin 13 Jun '11

13 Jun '11

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=11708 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [2/6] user32: Add a test to find the queue containing hotkey messages.
by Marvin 13 Jun '11

13 Jun '11

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=11707 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [1/6] user32: Ignore painting messages in the hotkey test using a wndproc.
by Marvin 13 Jun '11

13 Jun '11

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=11706 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

re: cmd: add support for todo_wine constructions in testing infrastructure
by Dan Kegel 13 Jun '11

13 Jun '11

I agree @todo_space@ should go; it's never used, so it's dead code now. Tempting to say that removing it should be a separate patch, rather than combining that with adding a new feature. Since all the @keywords@ are poorly documented, I'm glad to see an unused one go. Your generic @todo_wine@ keyword seems useful. The current code is a bit ugly. If you're going to add a nice is_todo_wine_line() helper, it might make sense to do a cleanup patch that cleans up the @keyword@ recognition in general first. (Why the verbose array declaration instead of a "constant"? etc.) I see you're making every line of the .exp file count as a test. That seems ok. There's a fair bit of code duplication; I wonder if you could avoid that by refactoring things a bit. To avoid adding dead code, it might be nice to see a test that actually uses your new keyword. - Dan

2 4

Re: comctl32/tests: Added first TaskDialog test.
by Nikolay Sivov 13 Jun '11

13 Jun '11

On Sun, Jun 12, 2011 at 9:32 AM, Patrick Gauthier <webmaster(a)korosoft.net> wrote: > This patch relies on my previous patch that sets the ordinals right. > > Given that these functions would only be available on COMCTL32 v6.x, > Vista+, I added a win_skip if the APIs are not present. However unless > the test EXE has a manifest on Windows I think it might never find them. > Hey, Patrick. Look at tests/listview.c for example to see how I load version 6 with activation context API. It doesn't work for some reason for XP SP3 (a glitch I don't understand), but works fine for everything else. All you need is v6util.h. Without version 6 activation this test is useless to run in auto mode, it will never find TaskDialog entry points. Thanks for your interest.

3 5

Re: wineboot: Add a command line option to suppress the GUI window.
by Alexandre Julliard 13 Jun '11

13 Jun '11

Adam Martinson <amartinson(a)codeweavers.com> writes: > --- > programs/wineboot/wineboot.c | 15 +++++++++------ > 1 files changed, 9 insertions(+), 6 deletions(-) That's not going to do anything useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: Handle SC_SCREENSAVE in DefWindowProc. (try 2)
by Alexandre Julliard 13 Jun '11

13 Jun '11

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -1606,6 +1607,12 @@ LRESULT NC_HandleSysCommand( HWND hwnd, WPARAM wParam, LPARAM lParam ) > FreeLibrary( hmodule ); > } > } > + else > + { > + const char *argv[3] = { "xdg-screensaver", "activate", NULL }; > + spawnvp( _P_NOWAIT, argv[0], argv ); > + } This should be consolidated with the support in explorer, and probably moved to the graphics driver. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/4] shell32/tests: verify known folders available in system
by Alexandre Julliard 13 Jun '11

13 Jun '11

Mariusz Pluciński <vshader(a)gmail.com> writes: > + StringFromGUID2(folderid, sGuid, sizeof(sGuid)/sizeof(sGuid[0])); > + hr = IKnownFolderManager_GetFolder(mgr, folderid, &folder); > + ok(hr==S_OK, "cannot get folder (id: %s, hr: 0x%08x)\n", wine_dbgstr_w(sGuid), hr); > + > +#define CHECK_KNOWN_FOLDER(id, csidl) \ > + check_single_known_folder(__LINE__, mgr, folderid, &id, csidl, # id, # csidl); > + > + CHECK_KNOWN_FOLDER(FOLDERID_AddNewPrograms, NO_CSIDL) > + CHECK_KNOWN_FOLDER(FOLDERID_AdminTools, CSIDL_ADMINTOOLS) > + CHECK_KNOWN_FOLDER(FOLDERID_AppUpdates, NO_CSIDL) ... This should be a loop over an array. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/8] dxdiag: Introduce the file output infrastructure.
by Alexandre Julliard 13 Jun '11

13 Jun '11

Andrew Nguyen <anguyen(a)codeweavers.com> writes: > --- > programs/dxdiag/Makefile.in | 3 +- > programs/dxdiag/main.c | 39 +++++++++++++++++++++++++++--- > programs/dxdiag/output.c | 54 +++++++++++++++++++++++++++++++++++++++++++ > programs/dxdiag/output.h | 49 +++++++++++++++++++++++++++++++++++++++ > 4 files changed, 140 insertions(+), 5 deletions(-) Please don't add so many new files. A single header for the whole program would do, and a couple of source files should be enough considering the amount of code you have. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmd: add support for todo_wine constructions in testing infrastructure
by Jacek Caban 13 Jun '11

13 Jun '11

Hi Frédéric, On 06/12/11 23:01, Frédéric Delanoy wrote: > - > + is_todo_wine = is_todo_wine_line(exp_ptr, exp_nl); > + There is no need to add such logic directly to test_output, this can be returned from comare_line. Jacek

2 2

Re: d3dx9: Implement GetImageInfoFromResource(A/W) for bitmaps.
by Vincent Povirk 13 Jun '11

13 Jun '11

You should probably call D3DXGetImageInfoFromFileInMemory for the real work. On Sun, Jun 12, 2011 at 10:32 PM, Charles Welton <charleswfb(a)gmail.com> wrote: > The code works except it doesn't try to detect the bitmap format. > Kindly ask for review and how to properly implement this. Should > GetDIBits be used? > > -- > Charles Welton > > > >

2 1

Re: comctl32/tests: Added first TaskDialog test. (try 2)
by Marvin 12 Jun '11

12 Jun '11

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=11662 Your paranoid android. === WXPPROSP3 (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W2K3R2SESP2 (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W7PRO (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W7PROX64 (32 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded! === W7PROX64 (64 bit taskdlg) === taskdlg.c:43: Test failed: COMCTL32.DLL is not loaded!

1 0

About building test suite for Windows
by Patrick Gauthier 12 Jun '11

12 Jun '11

Hi, As I was writing my task dialog test I ran into a few problems trying to test on Windows... First, I tried building it using make crosstest but I keep getting this: $ gmake crosstest crosstest is not supported (mingw not installed?) gmake: *** [crosstest] Error 1 I am on FreeBSD 8.2-RELEASE (i386), I have the following mingw ports installed (using pkg_add) mingw32-bin-msvcrt-r3.18.a3.14 mingw32-binutils-2.21,1 mingw32-directx-20020518 mingw32-gcc-4.5.0_1,1 mingw32-pdcurses-3.4 mingw32-pthreads-2.8.0 I deleted config.status (there was no config.cache) and re-ran ./configure, it fails to detect mingw, so I gave up on that. I then tried building them on Windows directly instead (using Visual Studio 2008 with Windows SDK v7.0) as describred there: http://www.winehq.org/docs/winedev-guide/testing-windows However, trying to compile comctl32_tests using the WINE headers would complain about EXCEPTION_EXECUTE_HANDLER being undefined. On the other hand, compiling with the MSVC headers would complain about TVIS_FOCUSED not being present. According to this: http://support.microsoft.com/kb/166471 it has been deprecated and removed from MS headers a long time ago. Eventually I would like to just be able to make crosstest so that I can stay in one dev environments and not two, so if anybody could help me about why isn't mingw32 detected, I would like it. Thanks. - Patrick

5 5

Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
by BACRI Stephane 12 Jun '11

12 Jun '11

Hi all. Was there something incorrect in this patch I submitted in may, or in the way I submitted it? Perhaps should I have mentioned that it had been tested in several ways with hardware & software. Regards. Stéphane.

2 3

Re: [PATCH] wined3d: Dont just print a FIXME on error, handle it (Coverity)
by Henri Verbeet 11 Jun '11

11 Jun '11

On 11 June 2011 17:26, Marcus Meissner <marcus(a)jet.franken.de> wrote: > if (state <= HIGHEST_TRANSFORMSTATE) > + { > mat = &device->updateStateBlock->state.transforms[state]; > + } > else > + { > FIXME("Unhandled transform state %#x.\n", state); > + return WINED3D_OK; > + } > This works, so I'm not too bothered either way, but I think the following looks slightly nicer: if (state > HIGHEST_TRANSFORMSTATE) { WARN("Invalid transform state %#x.\n", state); return WINED3D_OK; } mat = &device->updateStateBlock->state.transforms[state]; multiply_matrix(&temp, mat, matrix);

1 0

Re: [PATCH 1/4] Check for null pointers before strcmp. (LLVM/Clang)
by Juan Lang 11 Jun '11

11 Jun '11

Hi Lauri, ok(pdst != NULL, "inet_ntoa failed %s\n", dst); - ok(!strcmp(pdst, addr0_Str),"Address %s != %s\n", pdst, addr0_Str); + ok(pdst && !strcmp(pdst, addr0_Str),"Address %s != %s\n", pdst, addr0_Str); This change doesn't accomplish anything. In the first place, the previous ok which you did not change already ensures pdst is not NULL. While it's true that this ok could fail, leading to a following crash in the tests, the fact that the tests pass indicates this isn't happening. Second, the ok output message also dereferences pdst by printing it, so in the case that it is NULL, you haven't fixed anything. Really, I suggest you just ignore this warning, it's not worth the extra baggage. --Juan

3 3

Re: [PATCH] wined3d: Dont just print a FIXME on error, handle it (Coverity)
by Stefan Dösinger 11 Jun '11

11 Jun '11

On Saturday 11 June 2011 11:17:58 Marcus Meissner wrote: > else > + { > FIXME("Unhandled transform state %#x.\n", state); > + return WINED3DERR_INVALIDCALL; > + } Please return WINED3D_OK, like wined3d_device_set_sampler_state and other setters. Native doesn't do this kind of consistency checking, so apps will get D3D_OK returned if they pass an out of range state(unless the setter segfaults).

1 0

Re: [PATCH] user32: initialize all of msg (Coverity)
by Marvin 11 Jun '11

11 Jun '11

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=11625 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [PATCH 4/4] Make sure to use a return value. (LLVM/Clang)
by Marvin 10 Jun '11

10 Jun '11

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=11621 Your paranoid android. === WNT4WSSP6 (32 bit sock) === sock.c:524: Test failed: oob_server (82): received less data than expected: 2024 of 2040 === WXPPROSP3 (32 bit sock) === sock.c:524: Test failed: oob_server (70c): received less data than expected: 2024 of 2040 === W2K3R2SESP2 (32 bit sock) === sock.c:524: Test failed: oob_server (b90): received less data than expected: 2024 of 2040 === WVISTAADM (32 bit sock) === sock.c:524: Test failed: oob_server (948): received less data than expected: 2024 of 2040 === W2K8SE (32 bit sock) === sock.c:524: Test failed: oob_server (bb0): received less data than expected: 2024 of 2040 === W7PRO (32 bit sock) === sock.c:524: Test failed: oob_server (2fc): received less data than expected: 2024 of 2040 === W7PROX64 (32 bit sock) === sock.c:524: Test failed: oob_server (440): received less data than expected: 2024 of 2040 === W7PROX64 (64 bit sock) === sock.c:524: Test failed: oob_server (3ec): received less data than expected: 2024 of 2040

1 0

testbot flakiness?
by Dan Kegel 10 Jun '11

10 Jun '11

https://testbot.winehq.org/JobDetails.pl?Key=11509 shows failures and crashes, but the nearly identical https://testbot.winehq.org/JobDetails.pl?Key=11510 does not. (The latter one just adds a call to GetProcessMemoryInfo() in the xyz() logging function.) And the failure shown by the first patch has a last error on creating the batch file of 8, ERROR_NOT_ENOUGH_MEMORY, which is suspicious. Not quite sure what's going on there.

2 2

Re: [1/2] d3dx9/test: Add UpdateSemantics test. (try 2)
by Dylan Smith 10 Jun '11

10 Jun '11

> +static void test_update_semantics(void) > +{ > ... > + int offset = 12; sizeof(D3DXVECTOR3) might be clearer.

2 1

Re: [2/2] d3dx9: Implement UpdateSemantics mesh method. (try 2)
by Dylan Smith 10 Jun '11

10 Jun '11

Your patches have dos line endings (i.e. "\r\n") which causes git apply to fail, although the patch command only gives a warning. @@ -208,6 +221,12 @@ static DWORD WINAPI > ID3DXMeshImpl_GetNumBytesPerVertex(ID3DXMesh *iface) > TRACE("iface (%p)\n", This); > + if (!This->vertex_declaration) > + { > + WARN("Can't get number of bytes per vertex of an invalid vertex > declaration.\n"); > + return E_FAIL; > + } GetNumBytesPerVertex returns a DWORD not an HRESULT, so I wouldn't expect E_FAIL to ever be returned? Unusual behaviour like this should be covered by a test. + /* An application can pass an invalid declaration to UpdateSemantics > and > + * still expect D3D_OK (see tests). If the declaration is invalid, > then > + * subsequent calls to GetDeclaration, GetNumBytesPerVertex, and > DrawSubset, > + * which use the declaration, will fail. > + */ D3DXCreateMesh fails when the declaration contains a non-zero Stream value. I would expect UpdateSemantics to be as strict as D3DXCreateMesh, otherwise a test could validate the different behaviour. You tested a declaration with larger fields, but not with the vertex size being smaller or greater. (E.g. Try removing the last field, or appending a field.) I did some testing and couldn't get GetDeclaration or GetNumBytesPerVertex to fail on windows. DrawSubset did seem to fail after UpdateSemantics is called with a declaration that causes CreateVertexDeclaration to fail. This suggests that the native implementation probably just stores the D3DVERTEXELEMENT9 array and calls CreateVertexDeclaration on DrawSubset. You can probably cache the created vertex declaration and release it on UpdateSemantics for performance.

2 1

Re: cmd: Ensure mkdir returns an error for pre-existing directories
by Marvin 10 Jun '11

10 Jun '11

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=11601 Your paranoid android. === WVISTAADM (32 bit) === batch: unhandled exception c0000005 at 77496FCF === W2K8SE (32 bit) === batch: unhandled exception c0000005 at 778A8915 === W7PRO (32 bit) === batch.c:70: Test failed: CreateFile failed batch: unhandled exception c0000005 at 772D3067 === W7PROX64 (32 bit) === batch.c:96: Test failed: CreateProcess failed: 1450 === W7PROX64 (64 bit) === Timeout

1 0

Re: [2/2] advapi32: Use an architecture neutral structure to marshall service status information.
by Alexandre Julliard 10 Jun '11

10 Jun '11

Hans Leidekker <hans(a)codeweavers.com> writes: > ENUM_SERVICE_STATUSW and ENUM_SERVICE_STATUS_PROCESSW embed pointers so we cannot > use these structures on Wow64, where the service manager runs as a 64-bit process and > the querying process can be 32-bit. You should still keep the proper structure layout, for instance by using LONG_PTRs instead. You definitely don't want to make two server calls for every request. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/5] msi: Pass the full custom action command to CreateProcess.
by Alexandre Julliard 10 Jun '11

10 Jun '11

Hans Leidekker <hans(a)codeweavers.com> writes: > @@ -772,10 +772,22 @@ static HANDLE execute_command( const WCHAR *exe, WCHAR *arg, const WCHAR *dir ) > { > STARTUPINFOW si; > PROCESS_INFORMATION info; > + int len; > + WCHAR *cmd; > BOOL ret; > > + len = strlenW( exe ); > + if (arg) len += strlenW( arg ) + 1; > + if (!(cmd = msi_alloc( (len + 1) * sizeof(WCHAR) ))) return INVALID_HANDLE_VALUE; > + strcpyW( cmd, exe ); > + if (arg) > + { > + strcatW( cmd, szSpace ); > + strcatW( cmd, arg ); > + } > memset( &si, 0, sizeof(STARTUPINFOW) ); > - ret = CreateProcessW( exe, arg, NULL, NULL, FALSE, 0, NULL, dir, &si, &info ); > + ret = CreateProcessW( NULL, cmd, NULL, NULL, FALSE, 0, NULL, dir, &si, &info ); You should still pass the exe name to CreateProcess in addition to the command line. You probably also want to quote it in the command line if it contains spaces. Also some callers pass a NULL exe. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/5] msi: Implement and test MsiSetFeatureAttributes.
by Marvin 10 Jun '11

10 Jun '11

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=11595 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Re: [4/5] msi: Implement and test MsiGetFeatureInfo.
by Marvin 10 Jun '11

10 Jun '11

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=11594 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5979: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

1 0

Re: [1/2] d3dx9/test: Add UpdateSemantics test. (try 2)
by Stefan Dösinger 09 Jun '11

09 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks ok to me Am 09.06.2011 um 17:50 schrieb Michael Mc Donnell: > Removed a superfluous test. > Added NULL check before releasing mesh. > Changed struct declaration style. > Changed the struct declaration style again. > --- > dlls/d3dx9_36/tests/mesh.c | 279 ++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 279 insertions(+), 0 deletions(-) > <0001-d3dx9-test-Add-UpdateSemantics-test.patch> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN8VlIAAoJEN0/YqbEcdMw9a0P/R7/63zSoVb7sig95T+WQDDX HkASb2vhp9dgs65zNCA6Vm6mCqPh62aNa3IKThtrVRQcPmmPFndgz8KmHXHzYZMj 6aQsiaa+vL4Yf4qcub+KwMej/S/A5txmVuXmOtreqJAGAKL6B/QA59KKw46JAlHT 15hggvXCHx0HaMBOP+bhcAlEOCI1QMZb1ygkzOILZ6ooy+0gOfOzSfl20Fk4Iy6X fPNhtE+goV6tYnP8I1hJEBg2TFPlN1YF25SxFJ/CIcHaJHYGAAL8LquMciVOdZ1C KsSrQzFFBw9fySvZC8rkaMAW5jIg27njRs4QB2CGEd5OkFc4I2KqZ4f1EwS/zdHp hAlvJmSRzB7Tq08ToW1a2ebX6dHyNfLinCKKpsmo5jk4V1FVN2DTWjsQs/mCIbCF EoUF0/NyIJHocOa71IV1Xj5uN7dvcZyqrJ3ZBVwDKU4o6G7uIDus0gbTVpliqty/ aBcvhwtHx6donMVt+KqPpM23tvomCr553fw93lCbB55vdZvjUUcWY5lL1HDp7qbI lkwz6aNjUhsA21u7uqANnThqm25pXLElnYR8O6LuU3AfsdkJAodK5JZ6/50aleI9 t3/Ke6ugHeywrpvXJVVzzJT3cOqsF0lQBvGegOYlSCdHm1MxtVDpdP1M2wKMce0z 2eXYa2k0EP7H0oMVERbP =WyeT -----END PGP SIGNATURE-----

1 0

Re: setupapi: Make sure machine name is non-empty before failing (try 2)
by Marvin 09 Jun '11

09 Jun '11

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=11589 Your paranoid android. === WNT4WSSP6 (32 bit devinst) === No test summary line found

1 0

Re: setupapi: Make sure machine name is non-empty before failing
by Dmitry Timoshkov 09 Jun '11

09 Jun '11

Juan Lang <juan.lang(a)gmail.com> wrote: > +static const WCHAR emptyW[] = { 0 }; ... > - if (MachineName != NULL) > + if (MachineName != NULL && strcmpW(MachineName, emptyW)) What's wrong with 'if (MachineName && *MachineName)' ? -- Dmitry.

2 1

re: TaskDialog implementation
by Dan Kegel 09 Jun '11

09 Jun '11

Patrick wrote: > I'd like to port my re-implementation of task dialogs > (http://www.korosoft.net/projects/tdemu/) to WINE Awesome! > I would like to have some guidance ... [Why was my patch from > yesterday not accepted?] An iota of guidance was provided at http://source.winehq.org/patches/ Scroll down to your patch, you can see it's in "Pending" state. Scroll down further, you'll see that "Pending" means "The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help." See also http://wiki.winehq.org/SubmittingPatches for a generic checklist. Your patch seemed to do three things: - moving old stub into new file - adding a TaskDialog function - adding ordinals Those three things could all be separate patches, and some of them could have tests. I'd suggest sending just one of the three first (probably not the one that moves code to a new file), and including a test with the first patch. - Dan

1 0

Re: [1/2] d3dx9/test: Add UpdateSemantics test.
by Stefan Dösinger 09 Jun '11

09 Jun '11

On Wednesday 08 June 2011 18:51:41 Michael Mc Donnell wrote: > unsigned int faces[] = {0, 1, 2}; > unsigned int num_faces = sizeof(faces) / 3; Does this do what you want? As far as I can see you want ARRAY_SIZE(faces) / 3. > + struct { > + D3DXVECTOR3 position0; > + D3DXVECTOR3 position1; > + D3DXVECTOR3 normal; > + DWORD color; > + } vertices[] = { > ... Another style nitpick: Bracket placing. > + /* Two null pointers. Setting only the mesh to null will result in an > + * exception on Windows. > + */ > + hr = mesh->lpVtbl->UpdateSemantics(NULL, NULL); I think setting the instance pointer to NULL when invoking a method doesn't need a test, it will give you odd results. What you show here is that native checks the only method parameter before it accesses the object instance. Remember, usually apps will invoke this via C++: mesh->UpdateSemantics(declaration); Similarly it isn't necessary to check iface or This against NULL in the implementations. Otherwise this looks OK

4 6

Re: [PATCH 2/2] urlmon: Added empty file binding test
by Marvin 09 Jun '11

09 Jun '11

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=11581 Your paranoid android. === WVISTAADM (32 bit protocol) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: [PATCH 1/4] shell32/tests: basic tests of IKnownFolderManager
by Vincent Povirk 09 Jun '11

09 Jun '11

+ OleInitialize(NULL); Any particular reason you're using this instead of CoInitialize? I don't think there's anything wrong with it, but CoInitialize is more common. + todo_wine + ok(cat==KF_CATEGORY_FIXED, "invalid folder category: %d\n", cat); You'd be using cat uninitialized when the function is not implemented in Wine. I suggest initializing it to 0 or something. Same with redirectionCapabilities later. + ok(lstrcmpW(sWinDir, folderPath)==0, "invalid path returned: %s\n", wine_dbgstr_w(folderPath)); It might be useful to print sWinDir as well. If there's some situation where it's the right path but not quite the same string, that'd be good to know. + /* try to set new path */ + hr = IKnownFolder_SetPath(folder, 0, sTempDir); + todo_wine + ok(hr == S_OK, "setting path failed: 0x%08x\n", hr); I'd suggest making up + registering your own known folder to test this feature, rather than using a standard one. I worry someone could end up with a broken Windows install if we fail to put it back somehow.

2 1

Re: [2/2] d3dx9: Implement UpdateSemantics mesh method.
by Marvin 08 Jun '11

08 Jun '11

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=11567 Your paranoid android. === WXPPROSP3 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W2K3R2SESP2 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === WVISTAADM (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W2K8SE (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W7PRO (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W7PROX64 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W7PROX64 (64 bit mesh) === Timeout

1 0

Simple Windows Diaglogue App
by Lewis McLean 08 Jun '11

08 Jun '11

Hi, I'm trying to compile a simple windows dialogue app over to run on *nix with winelib. I'm looking at it as proof of concept for porting a larger application over. I've been getting errors from gcc to do with vc++ casting, where it loses precision. LinuxPort.cpp: In function 'int WinMain(HINSTANCE__*, HINSTANCE__*, CHAR*, int)': LinuxPort.cpp:34: error: cast from 'CHAR*' to 'WORD' loses precision LinuxPort.cpp:39: error: cast from 'CHAR*' to 'WORD' loses precision winegcc: i486-linux-gnu-g++ failed Ive tried to use static_cast<> and also c-style casting using () but can't seem to get it working. Any ideas? Thanks, Lewis

2 1

Re: [1/2] d3dx9/test: Add UpdateSemantics test.
by Marvin 08 Jun '11

08 Jun '11

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=11566 Your paranoid android. === WXPPROSP3 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W2K3R2SESP2 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === WVISTAADM (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W2K8SE (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W7PRO (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W7PROX64 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W7PROX64 (64 bit mesh) === Timeout

1 0

re: Simple Windows Diaglogue App
by Dan Kegel 08 Jun '11

08 Jun '11

Lewis wrote: > I'm trying to compile a simple windows dialogue app over to run on *nix > with winelib. I'm looking at it as proof of concept for porting a larger > application over. First off, why winelib rather than plain wine? Are you planning on targeting non-x86 computers? > LinuxPort.cpp:34: error: cast from 'CHAR*' to 'WORD' loses precision It might help to see your source code. - Dan

1 0

mmdevapi event driven (aka. pull) mode
by Joerg-Cyril.Hoehle＠t-systems.com 08 Jun '11

08 Jun '11

Hi, >What behavior do you think Wine is going to do wrong Matthew van Eerde's web log has a sample silence playing application using EVENTCALLBACK mode. http://blogs.msdn.com/b/matthew_van_eerde/archive/2008/12/10/sample-playing… Running it in Wine shows that Wine violates the assumption/invariant/guarantee IMHO Event signaled => there's room in the buffer -- much like winmm's MOM_DONE signals that a buffer is free. I don't know when the first event is signaled nor at what rate they are signaled. (Perhaps one is signaled every time one of the mixer's 10ms chunks is processed?). The app immediately complains and exits. Wine's mmdevapi current unconditional and periodic SetEvent does not match the above program's expectations (nor would it match exclusive mode behaviour: event => complete buffer free for writing). A periodic 10ms event may be fine when playing goes smooth, but that's not the case right at the beginning, esp. when filling the buffer before calling Start. I should turn that into a distinct bug report. Regards, Jörg Höhle

1 0

Re: [4/4] d3dx9/tests: Add tests for D3DXLoadMeshFromXInMemory.
by Marvin 08 Jun '11

08 Jun '11

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

2 1

Re: [PATCH 5/5] wined3d: Rename IWineD3DDeviceImpl_LoadLogo() to device_load_logo().
by Stefan Dösinger 07 Jun '11

07 Jun '11

On Tuesday 07 June 2011 19:44:49 Henri Verbeet wrote: > if (wined3d_settings.logo) > - IWineD3DDeviceImpl_LoadLogo(device, wined3d_settings.logo); > + device_load_logo(device, wined3d_settings.logo); Does the logo stuff still work? I thought about removing it, I don't think it has any use. The original intentions were for debugging(Is wined3d used on Windows?) and for making nice and fancy screenshots, but I don't think anyone uses it.

2 1

Re: [6/7] server: Implement RegisterHotKey/UnregisterHotKey.
by Marvin 07 Jun '11

07 Jun '11

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=11551 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [5/7] user32: Do not check the last error on succeeding hotkey calls.
by Marvin 07 Jun '11

07 Jun '11

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=11550 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [4/7] user32: Test registering the same hotkey hwnd/id pair twice.
by Marvin 07 Jun '11

07 Jun '11

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=11549 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [3/7] user32: Add test showing hotkeys change the async key state.
by Marvin 07 Jun '11

07 Jun '11

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=11548 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [2/7] user32: Ignore paint messages in hotkey tests.
by Marvin 07 Jun '11

07 Jun '11

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=11547 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: [1/7] user32: Add test for flags on keyboard messages.
by Marvin 07 Jun '11

07 Jun '11

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=11546 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Various locale tests for wine
by Akihiro Sagawa 07 Jun '11

07 Jun '11

Hi, I have a problem about testing wine where specific to locales (or ANSI code pages). Because test bots don't seem to test wine in non-English locales. I'd like to get wine's test results in various locale environments from test.winehq.org. Firstly, as a wine intended to handle locale properly, all tests should succeed in any locales. We could discover locale-depended failure in other locales. Secondly, if I add a locale specific test, it easy to prove the issue to others. In my opinion, adding Russian, Japanese and Chinese would be better. They are tested by existing XP bots. So how about adding non-English wine environments to the testbot farm? -- Best Regards, Akihiro Sagawa

2 1

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 June 2011