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

Re: wined3d: Use a separate mutex for wndproc_table access.
by Stefan Dösinger June 19, 2011

June 19, 2011

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

June 19, 2011

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

June 19, 2011

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

June 19, 2011

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

June 19, 2011

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

June 19, 2011

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

June 18, 2011

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

June 17, 2011

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

June 17, 2011

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

June 17, 2011

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

June 17, 2011

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > @@ -2632,6 +2632,29 @@ enum coords_relative > #define SET_USER_OBJECT_FLAGS 1 > > > +/* Register a hotkey */ > +(a)REQ(register_hotkey) > + user_handle_t window; /* handle to the window */ > + int id; /* hotkey identifier */ > + int flags; /* modifier keys */ > + int vkey; /* virtual key code */ > +(a)REPLY > + int replaced; /* did we replace an existing hotkey? */ > + int flags; /* flags of replaced hotkey */ > + int vkey; /* virtual key code of replaced hotkey */ > +(a)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 June 17, 2011

June 17, 2011

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

June 17, 2011

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

June 17, 2011

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

1 0

GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
by Michael Mc Donnell June 16, 2011

June 16, 2011

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

June 16, 2011

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

June 16, 2011

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

June 16, 2011

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

June 16, 2011

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

June 16, 2011

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

June 16, 2011

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

June 16, 2011

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

June 15, 2011

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

June 15, 2011

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

June 15, 2011

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